AltME groups: search

I should try if extension could speed up such a conversions.

make a new native as an extension, link it as a command :-)

Command is the best solution for me... I just wonder if there is 
not a better way how to write it in C, like using pointers or something 
like that

But for me today starts a new era... I'm really starting to use R3 
since now.

Checking the CC would be a good start.

Checking the CC would be a good start.

perhaps he wants a change ... ?

but Carl usually optimises into different phases of work.

design
build
fix


we sort of know why Carl has been a bit silent lately (he's been 
working on 2.7.8) now I think he is in a design phase in his mind.

Brian Posted a list in the R2 Releases group.


I also hope he included 2 fixes which I got Cyphre to address in 
view which crash or mock-up the quality in AGG.

it's amazing to see that in 2011 it can take so much energy out of 
someone just to tweet a "I'm away for 6 month please don't let a 
message after the bip"

sorry I got the last sentence wrong ... But my point is rebol is 
already full of super great stuffs (desktop, console, web plugins, 
 etc...) that just need to be upto dated once every 6 month. Some 
of them maybe needs a redefinition.

for example I would prefere a webplugin rebol/view  for only firefox 
but available on all OS... Maybe basing rebol VM on non hardware 
related  langagues would allow to speed up things ...

The full sequence for line terminator recoding is:
write %foo.r to-binary enline deline to-string read %foo.r

- READ/string is a shortcut for "deline to-string read"

- WRITE auto-converts string! to binary, so is a shortcut for "write 
to-binary" in this case.

So it can be just:
write %foo.r enline read/string %foo.r

Thanks - that is a gem - should be docced :-)

Is there a home for R3 one-liners and idioms?


reline: func [file] [write file to-binary enline deline to-string 
read file]

Now that I have internet again (it's been out for possibly a week) 
I'll check with Carl about this, but I remember code from 2007-2008 
that depended on this change, even from before SELECT was extended 
to objects and maps. It's used to make blocks that look like spec 
blocks for objects or maps act like objects or maps. SELECT does 
EQUAL? comparison, and SELECT/case does STRICT-EQUAL? comparison. 
So you can make it work by using SELECT/case. Note: Words now support 
case-sensitivity in blocks too, letting them be searched with FIND/case 
and SELECT/case.

>> select [a 1 :a 2] quote :a
== 1
>> select/case [a 1 :a 2] quote :a
== 2

I'll add this info to the ticket in a comment and dismiss it. It's 
actually more powerful than R2 :)

The trick is that objects and maps are case-preserving rather than 
case-sensitive, so their fields get the same case as the first instance 
of the word. Plus, case-insensitivity is a little broken for a lot 
of languages right now (Unicode case is a complex problem).

Characters are case-sensitive

 is a pretty misleading description of the difference you've pointed 
 out between SELECT and SELECT/CASE, Brian. 


I would appriciate SELECT/STRICT over /CASE, /STRICT would even be 
usefull to imply case sensitivity, at least it seems better suited 
to express the semantic difference between the refined und the unrefined 
function call .

Same for 

>> find/case [a :a] quote :a
== [:a]
>> replace/case [a :a] quote :a quote a:
== [a a:]
>> alter/case [a] [:a]
== true


DIFFERENCE, UNIQUE and other "set-functions" obviously haven't been 
subject to change when the treatment of blocks, objects and maps 
converged:

>> difference/case [:a] [a:] 
== []
>> unique/case [a: a :a] 
== [a:]
>> union/case [a] [:a] 
== [a]
>> intersect/case [a] [:a] 
== [a]
>> exclude/case [a] [:a]
== []


In all cases, /STRICT would read at least as well as /CASE, if not 
better.

I'm not sure if it isn't by design, at least I wouldn't be surprised 
if being told so. Anyways, I'd prefer it being a bug, so, added it 
to CureCode.

hmm, you should post it as a separate CC item (wish?)

yes, using /CASE for strict word comparison is VERY ugly. the only 
reason I can think of is that Carl didn't want to add a refinement 
just for this.

Well, if there's sufficient backing in the community, we really should 
manifest that in the form of a CC wish.

I'm not sure it's completely OK though, since there is one part of 
strict comparison that SELECT/case doesn't cover: binding.
>> select/case reduce [use [a] ['a] 1 'a 2] 'a
== 1
>> strict-equal? use [a] ['a] 'a
== false

Nor do we want it to, because SELECT, FIND and other functions to 
which /strict would apply would generally not be applied to data 
which could be guaranteed to have the same binding as the value you 
are searching for.

A new refinement for considering datatypes would be a good idea (if 
a bit overhead-inducing), but probably not the name /strict. We have 
to keep the /case refinement because of the legacy naming rules, 
but those don't prohibit adding new refinements.

select/a-bit-more-than-case-but-a-bit-less-than-strict-but-definitely-not-equiv-or-same

We can't remove /case. So the new option would not have to be a superset 
of /case, it would be additive. What would you call an option that 
made it consider datatypes? Keep in mind that this option would only 
apply to block types, so would be overhead for other types that implement 
the FIND and SELECT actions.

I'm OK with having the current behavior of FIND and SELECT, and extending 
it to the set functions. But if others have problems with that and 
want /case to just be case, then we may need the extra option. All 
of this is really a complaint about #1830 being dismissed.

That means expanding the complaint of #1830 and giving it a different 
justification.

And would that mean that calling the new-line function creates a 
new copy of the value, toggles the new-line bit, and places that 
new value in the appropriate slot?

I may not follow what you are after, but is a sign of integers immutable, 
and is that (according to your opinion) observable?

In theory the immediate values are supposed to be immutable
- three objections:


- immediate values are not definable in Rebol (you can define such 
a typeset, but that does not mean, every compatible interpreter would 
need to implement them the way they are implemented in one specific 
case)

- the sentence is uninformative ("are supposed" does not mean "are")
- "in theory" is uninformative as well (what theory?)

Andreas, I can define a function modifying a 128-bit slot so, that 
only the sign of an integer is changed. Would you consider that relevant?

("define a function" == "define a function in rebol") in my above 
statement

I consider the new-line attribute to be an attribute of the value 
slot, that just gets copied over to new value slots when the value 
is copied. But you could consider it to be part of the value that 
doesn't affect anything other than display. It's mutable if the value 
slot is not protected, but the mutation doesn't get carried over 
to the copies, so it's what we generally call "immutable" in REBOL: 
It's just assigning a new value to the value slot.

And here it's getting a bit philosophical, so I leave it at that.

Hmm, actually, not. That is exactly where my POV differs from yours, 
as well as from Brian's. Let's consider a value 1 being "stored" 
in a block B (whatever that means). Now, if the block B is not protected 
in some way, I am able to replace the value by, say #[none] e.g. 
Does that mean I mutated the value 1, mutating the slot? Actually, 
what I mutated was just the block B, replacing 1 by #[none], but 
I did not even attempt to mutate 1, if you are still with me.

In my definition, I mutated a value, but it was the block B, not 
1

And I think the point why your definition makes a lot of sense is 
that we can neither observe nor does it matter, if the new-line bit 
is modified directly by XOR or a MOV,XOR,MOV sequence.

And of course I think we also agree, that the new-line bit being 
observably a value attribute is an implementation detail that should 
not leak through either.

Yup. That matches what I said. We use the term "immutable" for these 
values because mutations to a value slot don't propagate to other 
value slots, and assigning a value to a value slot makes a copy. 
This is useful when compared to "reference" types, where the "value" 
is not copied, just the reference, so changes to the value are seen 
by other references. In R3 we now have real immutability of value 
slots as an option, but that doesn't affect the "immutability" of 
values that we had before. And for the purposes of reasoning about 
the language using CS methods, the "immutability" of values we had 
before is close enough to be considered a useful distinction.

I don't see a problem with copying the new-line attribute. Without 
that we wouldn't be able to format our code and make it stick.

Copy the new-line attributes when you copy a container where the 
items' new-line attribute is display significant.

Does a value slot have a protect bit?

Again, in theory, through the PROTECT bugs are a counterargument.

Value slots of objects can be protected individually. Value slots 
of blocks are protected as a group.

My point would be: are the value slots really immutable, strictly 
speaking, or is there still a mutable protect bit?

As an example of the CS tricks that immutability gives us, protecting 
a series should make it safe to share between R3 tasks without needing 
to copy it or synchronize access. That's nice :)

See the PROTECT bugs. The problem is that once the PROTECT tickets 
are all implemented, we will have a sufficiently capable system, 
but it will be too difficult to use. I think we need to rethink the 
model a little when we do the security/multitasking revamp.

More than 80 for tuple - it has a length attribute in there somewhere.

This is why I mark any suggestion to introduce a new datatype with 
the major flag in CureCode. We have a budget.

Yes, also a possibility.

Nevertheless, these limits may change, if the interpreter is compiled 
for a 64-bit environment, where the available space can increase...

Just a summary of the above "directly modify the slot" readers/watchers, 
that might not understand the whole discussion:


1) In REBOL some values, like blocks, maps, etc. can refer to other 
Rebol values. It is not reasonable to call the referring substructures 
"value slots" (I don't think I disclose too much when I say, that 
these referring substructures are 256-bit "wide"), since it can be 
easily demonstrated, that the substructures in fact don't "contain" 
the values, but rather they refer to them. (this is obvious if the 
value referred to is any of the values, that simply cannot be described 
by less than 256 bits) but is true also in case the value could eventually 
be described in less than 256 bits. (Brian calls such values "immediate", 
but I dislike that notion, since the values Brian calls "immediate" 
cannot, in fact, "fit in" the referring substructures either, and 
everybody having read my identity article knows enough to be able 
to do that as an exercise.).

2) Andreas asked in the discussion above, whether the possibility 
to "directly modify" the referencing substructures does not make 
all REBOL values mutable. The answer was "no", one of the resons 
is the fact, that the ability to "directly modify" the referencing 
substructures makes all values containing them mutable, which means, 
that REBOL blocks containing modifiable referencing substructures 
are mutable, etc... Any modification of the reference substructure 
is a mutation of the value containing the substructure, but cannot 
be a mutation of the value referenced by the substructure exactly 
because the substructures don't contain any values.

The opinion I presented above may be seen as "controversial", since 
it uses notions/definitions from my "Identity" article, which some 
see just a possible, but "unusual" alternative. If asked, I can be 
talked into demonstrating the fact, that the referencing structures 
don't contain any values, but, I do not want to start any flame wars 
about that, so, I reserve my right to not feel obliged to change 
the mind of all people seeing it differently.

It's all a matter of indirections and which abstraction level one 
chooses as a viewpoint. Anyway, as far as I know, value slots are 
currently 128 bits

I apologize if I am not parsing your sentences correctly, ahead of 
time.


We use the term "value slot" because that is the official term, not 
because it fully describes the situation. It's just Carl's term for 
that 128-bit structure.
 

You seem to be misunderstanding what I meant by "immediate" values: 
I meant values of the dataypes in the immediate! typeset.
>> immediate!

== make typeset! [none! logic! integer! decimal! percent! money! 
char! pair! tuple! time! date! datatype! typeset! word! set-word! 
get-word! lit-word! refinement! issue! event!]

Any type not in this typeset is not an immediate type. I don't mean 
anything else by "immediate".


Nonetheless, if you like you can think of all value slots as being 
references, but these are not necessarily references in the C pointer 
sense. For many of the "immediate" types (as defined above) these 
are abstract references. For instance, consider [1]. The first element 
of [1] refers to the abstract idea of an integer, of the value 1, 
plus some extra stuff (like no new-line attribute). However, the 
block [1] just contains a "value slot" which has a bunch of bits 
in it. We have decided that those bits refer to the idea of that 
value (integer, 1, extra stuff), but finally they are just bits. 
If you change the bits, the new set of bits would refer to a different 
idea - the original idea is unchanged, just not referred to anymore 
by the block. This is close enough to "immutable" that we can treat 
"immediate" types as such, which is helpful for reasoning purposes.


Now here is the interesting part: We can consider *all* "immediate" 
types to be immutable. The word types contain pointers (effectively) 
to a symbol and a binding. However, the symbol is immutable, and 
the binding can be considered a reference value - what the binding 
refers to may be modified, but the reference itself is not (in the 
abstract). If you change either of those two pointers, this would 
make it a new word - the old symbol and binding referent are unchanged. 
The actual binding referent is considered to be a separate value 
from the word (a object or context). So, words are still close enough 
to "immutable" for reasoning purposes.


Where it gets iffy is when we get into types that are not in that 
immediate! typeset, because the "immutable" part is only references 
and offsets, not any part of the value that we would usually consider 
valuable. For the purposes of reasoning there really isn't much of 
the value that is worth considering to be inherently "immutable", 
and such types are worth flagging when considering sharing of data 
and other stuff. This is why these types aren't in the immediate! 
typeset (and why we have that typeset predefined).


The reason the typeset is called immediate! rather than immutable! 
is because the feature of the types that we want to emphasize is 
that values of those types, when passed to functions or otherwise 
assigned to other value slots, can at least in an abstract sense 
be considered to be copied to the other value slot (even if the abstract 
idea of the value is still abstractly referred to). This means in 
particular that changes to a value slot can't affect other value 
slots that refer to the same value (at least before the change). 
For non-immediate types all or part of the value is not copied on 
assignment, so changes to the original would affect at least part 
of the value referred to by the new slot. This is the crucial difference 
for CS reasoning purposes. We don't call them "immutable" directly 
because things like using path syntax to fake mutability of tuples, 
or PROTECT making stuff immutable, tends to confuse the issue.


Where it gets even more interesting is when you consider that the 
existence and implementation of value slots is actually irrelevant 
to the behavior of REBOL; all that really matters is the difference 
in apparent behavior between the immediate! types and the rest. You 
could have boxed unique integers and decimals that are referred to 
by pointers if you like, or symbols that don't exist except as unique 
numbers, or a generational or compacting collector that changes the 
location of the referents and updates the references accordingly. 
None of that matters as long as the system at least pretends that 
the immediate! types are unchangeable and copied on assignment.

A lot of these terms are basically arbitrary, and can be considered 
by some to be not very precise, but they were all chosen for very 
good reasons. The above is the reasoning behind our use of the term 
"immediate", which is now the REBOL standard term for that concept, 
for better or worse.

If there are more properties of the immediate! values than the ones 
I listed above, as opposed to the other types, feel free to list 
them. I just gave an overview. As for documentation, that's a little 
behind. I was just going by how the person who writes this stuff 
refers to them. It's been used in some blogs, conversations, etc. 
It's a term taken from compiler construction jargon, appropriate 
since the semantics of REBOL has a lot of overlap with those of a 
compiler.

{Any type not in this typeset ist an immediate type. I don't mean 
anything else by "immediate".} - nevertheless, this provokes a question: 
does that mean, that no matter how these values are implemented (using 
less than 128 bits, or more than 128 bits to completely describe 
them), the typeset definition would not be affected?

I guess, that I owe a little more to the readers, so here is an example 
illustrating what I actually mean:

let's define a block as follows:

    a-block: [[1] [2]]


at the present state, it is obvious, that first a-block and second 
a-block are not identical
illustration:

    same? first a-block second a-block ; == false

now, let's use the CHANGE function:

    change/only next a-block first a-block
    a-block ; == [[1] [1]]

due to the way we did it,

and due to reflexivity of identity, first a-block and second a-block 
yield the same value,
after this operation

("the same" in the sense, that there is only one value, which happens 
to be the value both expressions yield.)


since first a-block and second a-block are two expressions yielding 
just one value,
we conclude (as a consequence of that), that the respective value
is not contained in the first slot of the A-BLOCK block

(if it were "contained" in there we could not be able to see, that 
the value is actually not "contained" in there)


Usíng the same approach for any other REBOL value, we can demonstrate, 
that no value is "contained" in "value slot". Since we *can* find 
out "Which value is the first a-block value?" there is only one conclusion 
we can make: using the first a-block expression we can refer to the 
value (this is why I use the words "reference", "refer"), but that 
does not mean, any other "reference" cannot "refer" to that value 
as well, thus the value "is not contained", but just "referenced".

Another (less useful) way to look at it is to say that no value is 
really the same as or identical to any other value, only to itself 
(the same value slot). But since that's a useless way to look at 
it, we instead compare the bits of the different value slots and 
if they match we then say that they are the SAME? (or IDENTICAL?, 
depending on how many bits we are comparing). Expediency for the 
win!

no value is really the same as or identical to any other value, only 
to itself (the same value slot).

- well, the first part of the sentence is a law of logic - nothing 
can be identical with any other thing except for itself - which is 
true, and I even used that law to define the identity

And then you defined "value" to be something referred to by the value 
slot, not what was in the value slot, or the value slot itself. Without 
that definition, your definition of "identical" doesn't work. Which 
is why that was another way to look at it, the "other" in this case 
referring to way to look at what a value is and how to think of a 
value slot.

Yeah. The main difference between what you are saying and what I'm 
saying is for that what you are referring to by values that don't 
fit in 128 bits, the values that are in the value slots are what 
I've been calling "reference values". Thus the distinction between 
"immediate" types and "reference" types. This is a similar situation 
to (primarily OOP) languages that make a distinction between boxed 
and unboxed values, except for us even the "unboxed" values are in 
a box: the value slot. Making this distinction lets us reuse the 
large amount of existing reasoning that has been applied to OOP languages. 
This is particularly helpful when we are trying to solve the same 
problems that many other languages are, but the existing research 
on those problems is being done by people working in those other 
languages. Finding comparable distinctions makes it easier to implement 
comparable solutions :)

For instance, I'd hate to have to start from scratch in creating 
a concurrency model, especially when we can start from the Go model 
instead.

> except for us even the "unboxed" values are in a box: the value 
slot.


It's the extreme semantic overloading of "value", that is the problem 
here. :)

And we didn't make a typeset for the latter because not existing 
in the former is enough.

Specifying a "REBOL value" as the sum of it's attributes, for example.

Yup. Works great until you try to use "value" in a sentence, because 
of English's ambiguity :(

Even the actual "payload data" of a REBOL value is a type-dependent 
attribute.

And now of course the problem is, that we refer to different entities 
as "value", depending on context. Amongst those entities often referred 
to as "value" are:
- the "REBOL value", as defined above
- the "payload data" of a "REBOL value"
- the "value slot" implementation detail

Is there a way how to mold error into nice looking string?

how... do you have a list of all available error ids?

Pavel... I usually use ASK with any value/message as a break point 
while debugging. Or just PROBE is I don't need to stop the evaluation.

small observation:

>> any-word? #a
== true

Oldes, wasn't there a function in R3 which allows you to get the 
string from an error...directly?

Plus, there is a long-term CC ticket about the off-by-one Near for 
operator-generated errors.

Oldes, a perhaps simpler version for R2 is: http://www.rebol.it/power-mezz/mezz/form-error.html

I thought FORM was supposed to be able to do the same thing on R3, 
not implemented yet?

>> unique reduce [use [c] [a: 'c] use [c] [b: 'c]]
== [c]
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] a
== true
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] b
== false

This seems to be pretty consistent.

Is it a bug if UNIQUE is not stable.

That would end up with bug reports like the ones for SORT not being 
stable. I would consider it a bug.

If it would be a bug otherwise, it is safe to document this behaviour.

The SORT not stable bug http://issue.cc/r3/1152is currently considered 
a "should fix before release" priority, btw.

Yes, SORT sucks, sort-a...

it would be nice to have a few sort algorythms out of the box.

With a rewrite of Ladislav's msort. I'll probably publish it after 
a few more enhancements

I use a custom extension which stably wraps qsort :) I guess it is 
slower than msort, though :)

; Extended Merge Sort, originally by Ladislav Mecir, 2004

context [
	set 'msort func [
		table [series!]
		/skip size [integer!]
		/compare columns [integer! block!]
		/reverse
	][
		unless skip [size: 1]

		if size < length? table [sort table  ; > 1 slot
			copy table
			(length? table) / size
			size
			either integer? columns [reduce [columns]] [columns]
			reverse
		]
		table
	]

	do-compare: func [
		row1 row2
		columns
		/local column a b
	][
		foreach column columns [
			unless equal? a: pick row1 column  b: pick row2 column [
				return all [b  any [not a  a < b]]
			]
		]
		true  ; Equal
	]

	sort: func [
		table shadow
		length [integer!]
		size
		columns
		reverse
		/local half middle
	][
		either length < 4 [  ; 2 or 3 slots

   if length = 3 [sort skip shadow size  skip table size  2  size columns 
   reverse]


   merge table  shadow 1  skip shadow size  length - 1  size columns 
   reverse
		][
			middle: size * half: make integer! length / 2
			sort shadow table half size columns reverse

   sort skip shadow middle  skip table middle  length: length - half 
    size columns reverse
			merge table
				shadow half
				skip shadow middle  length
				size columns reverse
		]
	]

	merge: func [
		table  shadow length  shadow2 length2
		size
		columns
		reverse
	][
		until [

   either either reverse [do-compare shadow2 shadow columns] [do-compare 
   shadow shadow2 columns] [
				table: change table  copy/part shadow size
				shadow: skip shadow size
				-- length
				zero? length
			][
				table: change table  copy/part shadow2 size
				shadow2: skip shadow2 size
				-- length2
				zero? length2
			]
		]
		change change table
			copy/part shadow  length * size
			copy/part shadow2  length2 * size
	]
]

BTW, the last Msort:

http://www.fm.tul.cz/~ladislav/rebol/msort.r

is a bit faster than the older version you used

yeah... FORSKIP is really overkilll just source it and you'll be 
amazed at how much code there is for a loop!  


also don't use FORALL..... cause it calls FORSKIP.    always use 
UNTIL or WHILE in these cases.

Kaj, you should find a way to fire all the <copy/part ... > you're 
doing.
I would try to reuse the same buffer with something like:
>> append/part clear buff ...

>> sort/compare [d a c b] func [x [string!] y [string!]] [probe type? 
x x > y]
word!
word!
word!
word!
word!
word!
word!
== [d c b a]

This is also a problem in R2.

The second might not affect the code, if the == [d c b a] is not 
an error.

Right, [d c b a] is the correct order. Yes, #1516 is a really big 
(security) problem.

Because there is a process of determining how it should be done and 
it might make sense to prepare for it now. There are several possibilities 
for implementation.

really, if we have to choose between encryption and threads... there 
is no contest.... all the "usability" stuff we can code as extensions 
and indeed, the cURL binding is a good example of this.


we need threads to be done... they have an over-arching effect on 
every aspect of REBOL... we can't put this off until later... its 
going to change the design of things for sure.  I can't understand 
why Carl is side-stepping this again.

is carl even aware that there is a cURL binding right now and that 
maybe he can skip this for now?