World: r3wp

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.

stable and predictable; I'm all for that. Beyond the LOAD issue, 
we can do all that, right?

Yes, we can patch rebol and fixed ourselves, but we should remove 
some "surprises" like making CONSTRUCT safe.

It's really a question of default behaviors, right? (making sure 
we're talking about the same thing)  My concern is that, by making 
more things "safe" at the native level, we may create more issues 
than we solve.

I had another issue with the behaviour of APPEND which is different 
for block! hash! than from list! and it is a side effect of INSERT 
and REMOVE
APPEND b: make block! [] [v1 v2] head? b ;== true
APPEND l: make list! [] [v1 v2] head? l ;== false

I don't know how many of this type of examples are there, but is 
quite annoying to debug these side effects.

that has nothing to do with append - that has to do with list!s.

I would say that's a bug in APPEND, because of the way the doc-string 
is worded.

l: append ... would work

but append l ... does NOT change the word 'l

actually, it isn't a bug and it is almost impossible to change, but 
it may need a documentation

We need more consistency. I discuss the APPEND issue extensively 
with Ladislav, and it is about docs and side effects. What I fear 
is the explosing of exceptions.

could be changed, but only for the "head" case, if the list head 
was a special node (like Exec's double linked lists)

I would like also to be able to implement our own types! and be able 
to overload some words. So that an implementation of associative 
arrays can work look like [make aa! 10] instead of [aa/make 10]

Any opposition on proposing the change to CONSTRUCT?

Do you mean CONTEXT?

Sorry CONTEXT.

You can propose it. I'm happy to let Carl decide. I wonder if it 
might cause some confusion as it won't be an exact replacement for 
make object!, which it's just a shortcut for. It could break code 
and change behavior if substituted.

I am quite curious if it breaks really would break some code

Jaime, can you list these issues in the gotchas in the wikibook so 
that they can be documented for all.

I would probably stop using CONTEXT with this change.


I may not be a newbie, but I don't see how this behavior is different 
from the way blocks that aren't explicitly copied are shared throughout 
REBOL. Once you learn this gotcha once (like, the first time you 
make a function with a local block), you have learned it throughout. 
There are always workarounds, and the default behavior can be extremely 
useful if you are expecting it.

I am speaking about the following example:

objects: []
loop 2 [
	append objects make object! [a: 1 block: [a]]
]
objects/2/a: 2
do objects/1/block ; == 2 !

are you sure you can never be caught?

I usually do that kind of thing like this:

objects: []
loop 2 [
	append objects make object! [a: 1 block: does [a]]
]
objects/2/a: 2
objects/1/block ; == 1 !

To me thats the typical copy-problem. i use 'copy in context-blocks 
too.
   make object! [a: 1 block: copy[a]]
In most cases it does not matter, as 'func copies too.
But when it goes wrong, its pretty confusing.

The only time it can get tricky is when sharing parse rules. The 
way I work around that is to encapsulate them in a shared object, 
but occassionally it can cause a problem (simultaneous parsing) that 
only copying can help with.

BrianH: nevertheless, you didn't tell me, when would the changed 
CONTEXT cause you any trouble and what kind of trouble?

Now that we have open/seek, is there some way to compute a check 
sum on a large file by reading it in part by part ?

Ladislav, I frequently use shared data in non-copied data structures 
that are referenced by many objects. This data isn't always in blocks 
- frequently I use hashes, lists or objects. These would be copied 
by your CONTEXT changes too, when my code expects them to stay the 
same. Lists and hashes are not affected by your rebinding problem 
- only blocks, parens and functions are rebound during object creation, 
because only they directly contain code under normal circumstances.


In the past I've found it easier to change the code that treats blocks 
as shared code ckunks into functions, or to make helper functions 
that create and initialize objects appropriately.

Hm this is strange