World: r3wp

do y/1

no that gives me also x/1

it works fine here?

not here..

>> x: [ 1 2 3 ]
== [1 2 3]
>> y: [ x/1 ]
== [x/1]
>> do y/1
== x/1
>> x: [ 1 2 3 ]
== [1 2 3]
>> y: [ x/1 ]
== [x/1]
>> do y/1
== x/1

odd ...

>> x: [2 4 6]
== [2 4 6]
>> y: [ x/1 ]
== [x/1]
>> y/1
== x/1
>> do y/1
== 2

try a fresh console, I've done it successfully on mac with view 1.3.2 
and winXP with view 2.7.0

your kidding me... Could that be a problem ?

well, if some variable has been changed.

do on paths was added in 1.3.1 or something i think.

hmm... it could be that it evaluates as a path

mmm nope no effect ->
>> x: [ 2 4 6 ]
== [2 4 6]
>> y: [ x/1 ]
== [x/1]
>> y/1
== x/1
>> do y/1
== x/1
>>

rebolinth, system/version ?

REBOL/Core 2.5.6.4.2

use 2.6 :)

otherwise you need to  do y   or  do reduce [y/1]

Mmmmmmmm all that brain cracking the whole day .... in 2.6 its working...

Thanks...I finaly can finish my Brain-Game ;-)

Anyone built an xml to rebol object utility?

I'm talking about well formed xml, no attributes involved.

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