World: r3wp

; After pasting the first example, I can:
reduce last last spec
; == 2

Sorry, == [2]

The is the kind of side effects are quite dangerous, imo the current 
behaviour seems like a bug and breaks the least surprise premise.

Or doesn't deep copy.

strange isn't it?
same? o1/block o2/block
== true
But if you change the spec to
  block: copy [do [a]]

They are no longer the same, but still return the same value. Odd!

Chris was ahead of me there -- a working solution is
  block: copy/deep [do [a]]

You would need to copy/deep.

:o)

yes, that is true, I wrote a similar example to my Bindology article 
quite some time ago, where it was "clashing" with recursion. Here 
it is a problem even without recursion

Should programmers concern about copy/deep when creating new objects 
from a spec? It seems strange that they do.

As the interpreter is working now, they should, at least in case 
of recursive code or objects with variables having block values

The easiest rule is to write make object! copy/deep spec instead 
of make object! spec

But is this appropriate, why not just have copy/deep by default on 
make object! ?

the reason was, that it is slowing down the interpretation in cases 
it isn't necessary

(I would say, that it can be considered "premature optimization"?)

(or machine time optimization at the cost of human time?)

Why not add a section on the wikibook about "side effect" in Rebol, 
this and other idioms are a must know not only for beginners and 
experts.

right

I think if rebol slows you down, specially with such a subtle problem 
then new programmers may not adopt it. (It will for them look buggy 
or confusing).

It can take a lot of time to find the problem of your code is not 
logic but a side effect of the language implementation.

Perhaps it could come under 'Gotchas' -- it's not a bug so much as 
a 'feature' of Rebol values and contexts?  Just as much as 'copy 
does not automatically 'copy/deep...

regarding the behaviour: I think, that it might be optimal to have 
a function like CONTEXT deep copying by default with eventual /no-copy 
refinement?

It would be *much* better to suggest the beginners to always use 
CONTEXT instead of MAKE OBJECT! and be safe IMO

I agree that hidden things like this can be dangerous, but how many 
of us have actually had a problem with it (this issue) in our applications?

I did

My view is that Carl made this a conscious choice, knowing that advanced 
users could do their own copy/deep when they need to, and it won't 
come up most of the time anyway.

We have encounter a lot of Gotchas in our development, and part of 
the reason we are slowed down many times.

Yes, but you're a special case Ladislav. :-)

We are coding cutting edge stuff. Callbacks, Sophisticated Async 
Networking and others.

well, but my suggestion regarding CONTEXT isn't very aggressive, 
is it?

Right, and I agree that this kind of thing should absolutely be documented, 
but I also think I understand why it works this way.

So if new users start to code complex applications they hit the problems 
that are not well documented and not easy to catch.

context: func [
    "Defines a unique (underived) object."
    blk [block!] "Object variables and values."
][
    make object! copy/deep blk
]

And, yes, I think it might be OK for CONTEXT to do a copy on the 
spec; I wouldn't even add the no-copy option,.

:-)

a similar issue exists for USE (use copy/deep spec) , and FUNC (solved 
by my CLOSURE)

1) Documentation is important.


2) Once you know about this behavior, which applies to most areas 
of REBOL, not just objects, you can easily solve it.

...and MAKE PROTOTYPE-OBJECT SPEC

the CLOSURE case is not that easy

But closures are a very advanced concept; normal people will never 
even hear the term.

The biggest risk I see for normal people, is when you're doing things 
like deserializing objects and such.

wrong - everyone is going to need closures once writing async code

Closures are usefull for concurrent programming which is needed in 
async schemes.

But, again, that is an advanced concept. If only 10 people in the 
world understand it, that's OK, as long as they hide those details 
so it just works, magically, for the rest of us. :-)

but once the core becomes async, everyone will have to adjust to 
it

Why? I don't have to know anything about how REBOL's GC works, do 
I? If *everyone* has to understand and adjust to async, and if even 
10% of people need to know how closures work, that would be a tragedy.

you do not *need* to know how closures work, the only thing you need 
to know is, that when you use a closure instead of a function, some 
bugs vanish

If we are pushing rebol to be capable of handling more and more problem 
spaces, then we need more powerful constructs and excellent docs.

more powerful constructs
, like what? (kind of playing Devil's Advocate here)

closure, associative arrays, construct with deep copy, load on values 
that don't exist in system object, others. Some of the bugs that 
have been fixed are due to our need for more power, stable and predictable 
interpreter.