World: r3wp

I'd expect path error.

generally spoken, the "post-check" checking after the () part is 
evaluated looks safer (IMO)

so, interpreter should evaluate the argument first, then the set-path?

if implemented the other way around, it is unsafe (IMO again)

but:

>> f: func [/x] [print "huh"]
>> f/x
huh
>> f/x:
huh

so... what happens with a/x: (a: func ...) ?

it would be evaluated out of order.

(if a was already func that is)

My proposal is, that

f: func [/x] [print "huh"]
f/x: 1

should be an error (cannot use set-path on a function)

OTOH,

    f: func [/x] [print "huh"]
    f/x: (f: 1x2 3)

should behave differently

it's mainly a matter of wheter it is more natural for the set-path 
to be evaluated first or last.

the trouble is, that only the second variant may be safe (IMO)

, because the first variant relies on information, that may be "invalid"

I will put these to RAMBO, do you agree?

I agree

well, there is a possibility to use the strategy to "partially evaluate" 
the set-path before evaluating the argument, but then e.g.

a: 1x2 a/x: (a: 3x4 5)

should yield a == 5x2 and

a: 1x2 a/x: (a: [x 4] 3) should yield a == [x 4]

hmm, the last example is strange, actually, I guess, that the only 
reasonable variants for a: 1x2 (a: [x 4] 3) are a == 3x2 or a == 
[x 3]

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