World: r3wp

I think I don't like the "partial evaluation".

I don't see the point to the partial evaluation either. A set-path 
will always evaluate its argument, so you don't need to preevaluate 
the set-path to determine whether the argument will be evaluated 
- it will. Just evaluate the argument ahead of time. If the set-path 
fails later, so be it.

yes, that is my favourite variant too, unfortunately different than 
the one currently used

Ladislav, I would go for the fastest implementation. So double-check 
is out of the question. Then post-check must be the best and safest 
way (I guess!?).

unset 'a a/x: (a: 1x2 3)
should then make a holds 3x2.

a: 1x2 a/x: (a: [x 4] 3)
should make a be [x 3]

a: 1x2 a/x: (unset 'a 3)
should give an error.

I think, this is correct. I'm not 100%.

if you find it intuitive, then I'm for the change too.

Geomol, this looks correct to me too.

This is a strange corner of REBOL. And one not often explored. A 
good developer would probably not do something like:
unset 'a a/x: (a: 1x2 3)

But we can't be sure. Maybe it's a really good trick sometimes to 
write something like that.

In general it's good practise to only set internals of values, IF 
it's valid up front (, so I understand, that Gabriele would expect 
an error). But of course REBOL should be able to handle it, if someone 
wrote such tricky code. It shouldn't be undefined, what would happen. 
I feel, the post-check (that Ladislav is talking about) is the safest 
(and fastest) way to handle this, and then maybe in the documentation 
notice, that it's bad programming practise to do this.

is there any way to do 64bit integer operations with rebol without 
resorting to strings?  something like 36969 * 1234567890 overflows 
rebol :(

decimal unfortunately wont work without large slowdowns as I need 
to do AND/XOR/OR operations on the result

igonre my last post - i see Carl has already written about 64 bit 
in his blog..  Meh, guess ill have to use C# for the meantime :(

Geomol: I agree, but to have it complete, here is a more complicated 
expression:

    a: [1 2 3 4 5 6 7 8 9]
    i: 2
    a/(i: i + 1): (i: i * 2 0)

What should i and a look like?

This leads us to the path evaluation too. What should be the result 
of:

    a: [1 2]
    a/(a: [3 4] 1)

Or to yet another crash:

    a: 1x2
    a/(a: [3 4] 1)

Maybe the actual behaviour should be documented as undefined - ie. 
"don't go there".

yes, that is a reasonable variant too

Ladislav, your example:
	a: [1 2 3 4 5 6 7 8 9]
	i: 2
	a/(i: i + 1): (i: i * 2 0)

The actual behaviour seems good to me. That is, the first paren is 
evaluated, then the path is resolved, then the second paren.

yes, looks OK

Maybe this example
	a: [1 2]
	a/(a: [3 4] 1)
is better as 
	a: [1 2]
	a/(insert clear a [3 4] 1)

how about this one?

a: 1x2 a/(a: 3x4 1): (a: 5x6 7)

Tough questions! :-) In general I'm for evaluation of what possible 
at the earliest time as possible. This way stack space should be 
kept at a minimum. This works against the post-check method mentioned 
earlier. So we have the old fight between speed and size. We want 
both! (Good speed and minimal size = reduced bloat and small foot-print.) 
Examples are good to explore this!

i: 2
a/(i: i + 1): (i: i * 2 0)


Should evaluate the first paren right away, because it's possible. 
This way the path is reduced to: a/3

Now, a/3: might not make sense yet, depending on wheater a is defined 
or not. But we don't care, because it's a set-word, and here post-check 
rules.

a: [1 2]
a/(a: [3 4] 1)

should give 3 (I think).

a: 1x2
a/(a: [3 4] 1)

should also give 3 then.

The last one:
a: 1x2 a/(a: 3x4 1): (a: 5x6 7)
should go like this:
i) a is set to 1x2
ii) a is set  to 3x4

iii) first paren returns 1, so a/1 is about to be set (a is not desided 
yet, because it's a set-word).
iv) a is set to 5x6 and second paren returns 7.

v) a is about to be set, so it's being looked up (a holds at this 
point 5x6).
so result is, that a ends up holding 7x6.

unfortunately the evaluation looks complicated this way

(but the most reliable)

Ladislav, looks like pairs are treated differently. (not a series, 
even though they really should be ?)

right, pairs differ from series (are not mutable)

(according to the definition used in http://www.fm.tul.cz/~ladislav/rebol/identity.html
article)

Path evaluation order once again: it looks to me, that the algorithm 
working as follows:

a: 1x2 a/(a: 3x4 1): (a: 5x6 7)
a ; == 7x2


is more than two times faster than the "more natural" one yielding 
a == 7x6. The difference lies in the fact, that the latter algorithm 
needs to rebuild the path before applying it, while the former one 
can "evaluate on the fly", without rebuilding.

Moreover, the a == 7x2 result is compatible with the way how functions 
are evalutated:

f: func [x] ["first"]
g: func [x] ["second"]
h: :f
h (h: :g 1) ; == "first"

apparently i lost it completly...;-) 


I have to following issue: I want A to be a block and B thave the 
initial values of A, but B may not change when A changes!

so i tried it all , but it always turns out that b changes with a 
i.e.

a: [ [ 987987 ] [ kljhljkh] ]
b: []
b: a
a/1/1: 'blabla  
then b changes too... ;-) 


Oke..i know this, but how do I apply a to b without b changing to 
'a everytime I change a

I need to be able to compare A with B after A changed x times... 
so B must be a block..when using 'equal? B A

I tried 'append 'insert 'foreach but it keeps changing in B too when 
changing A.. That bring me too an issue in rebol, How can I check 
if a Type is a relative of a different Type? like 'copy does..

Im unable to see if B is a copy of A, i can only check if the Type 
is the same but thats useless I cant check if B is a Relative of 
A...

Rebolinth:  you can use b: copy/deep a

;-) Thats something I never ued befor, I always thought that was 
for the use of nested blocks... Thanks !

Mmmmmm "/deep - Also copies series values within the block."  I cant 
say thats a realy clear eplenation ;-) never the less it works...

It is the most precise explanation.

Icarii, you can probably use bitsets for what you want. I did some 
bitset math stuff a while back, so Maarten could do 160-bit checksums 
(IIRC).

How about "Recursively copies series! values within the block." ?

That would be the most precise explanation.

unfortunately, it doesn't copy all series:
>> a: ["aa"]
== ["aa"]
>> b: copy/deep a
== ["aa"]
>> same? first a first b
== false

ah, sorry, actually, it did, in this case

yes its strange actualy to find this function under copy... I would 
expect a name like copy/static or someting..but whats in the name 
;-)

rebolinth, well, copy copies. copy/deep copies deeply. /static makes 
me think of the opposite (what does copy/static mean???)

hi, I want to call a rebol script in a separate process and pass 
parameters e.g.  launch {c:\script.r param} but does not set  system/script/args

what am i doing wrong ?

Ladislav, if a: 1x2 a/(a: 3x4 1): (a: 5x6 7) resulting in 7x2 is 
more than 2 times faster than the post-check method resulting in 
7x6, then that is a very good argument to have it that way. Anyway 
your example is something, that should be avoided (if you're a good 
developer, I guess), so speed is better than a "more natural" result. 
That's my view.

yes, but the crash can (and should) be eliminated

if it results in 7x2, does it mean that 'a in paren! is local?

(half-jokingly)

I think, that it really needs an explanation.

* The 7x2 evaluation can work as follows: 

1) the interpreter first sets its Path-start variable to 1x2 and 
its Path-variable to 'a

2) the evaluation of the paren changes the A variable, but that does 
not influence the interpreter Path-start variable, so the path will 
be evaluated as Path-start/1:

3) the argument is evaluated, which changes the A variable again, 
but not the Path-start. The argument value is 7
4) Path-start/1: 7 is evaluated, which yields Path-start = 7x2

5) The variable A is set to the new value of the Path-start variable


The same algorithm can be used for longer paths too and we do not 
have to remember the complete path - it always suffices to remember 
"where we are".


The 7x6 evaluation cannot work like that, since we never know "where 
we are" - the Path start can change anytime, so we cannot "traverse" 
the path when evaluating parens. We need to "rebuild the path" evaluating 
all parens and remembering all intermediate results. Only when done 
and when the argument is evaluated, we can start to traverse the 
rebuilt path knowing the Path start.

Joe, I can't get it to work either. It looks like LAUNCH always just 
converts its VALUE argument to a file and then tries to do it.