World: r3wp

No matter, xml-to-object works fine.

Please do not run this in REBOL console. Instead I want you to tell 
me what you expect as a result:

unset 'a a/x: (a: 1x2 3)

i'd expect an error.

I would probably expect 'a/x to be 3

depends if it checks whether the path exists or not before the () 
part is evaluated

...and what you expect in case:

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

or:

    a: 1x2 a/x: (unset 'a 3)

a = [x 3]

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)