World: r3wp

Funnily enough, == is not inconsistent in R2, but that is not very 
useful either

Regarding your 

this being a bug" - how that can be a bug of the language is beyond 
my understanding, when I know that it was intended."

*sigh* :)

How do you know, it was intended? You may know, because you've discussed 
it with Carl. How would other than you know?


When I say "bug", I might mean "design flaw". Have you considered 
that? If it was intended and can be considered a design flaw, why 
not just call it a bug then?


Never mind. As I expect, you won't eat your words about this being 
simple, I don't expect a reasonable answer anyway. :)

Note to self: when discussions evolve like this, don't waste your 
time, John.

How would other than you know?
 - exactly as I did, form the public expressions

(not private, as you are suggesting)

And regarding the "time waste", some readers discovered something 
new, so it was not a time waste for them

Regarding the "How would other than you know?" - see e.g. this source:

http://www.rebol.com/r3/docs/functions/make.html

Regarding the "design flaw" - as I said, the MAKE OBJECT! [...] expression 
modifies the block, but it is easy to define the SAFE-OBJECT fucntion 
which does not modify the block. Thus, it is not a design flaw at 
all. It might be considered a design flaw only if we weren't able 
to define such a function.

(but this kind of simplicity does not tell you anything as it looks)

And, while you discovered something new as well (see your posts above 
admitting that), I certainly did not, so, I am the one here answering 
some "time wasting" questions of yours.

And regarding the 

time waste", some readers discovered something new, so it was not 
a time waste for them"
That's right, I did not know that MAKE OBJECT modifies the block.

The

http://www.rebol.net/wiki/Bindology


article discusses this as well (together with other subjects I found 
interesting), but, I have to admit, that it is probably not a reading 
for a "faint of heart"

I confused about COPY on R3. On R2 COPY doesn't work on object! type. 
It does on R3.

>> o: context [a: "x"]
>> p: copy o []
>> append get in o 'a "y"
>> ? p ; a == "xy"

when I change 'a in O, it changes in P as well.

which means o/a and p/a "points" to the same series! I think.
But;
>> same? in o 'a in p 'a
== false

Why?

Your question is equivalent to this one:

a: "x"
b: a
append a "y"
b ; == "xy"
same? 'a 'b ; == false

Oh shame on me! I forgot to GET the values.. Thank you.

One more question, I use COPY on objects to be able to use same series! 
values in different objects, is that right?
I mean pointing to the same series inside different objects.

In R2 I do like that:
>> o: context [a: ""]
>> p: context [b: get in o 'a]
>> append p/b "*"
>> o/a
== "*"

Geomol, your model is one based on "scope". REBOL's model does not 
have such concept, thus, it is "simpler" (less concepts). You have 
a different definition of "simple", which seems closer to "intuitive" 
to me. That's fine with me, but, there's no point in arguing using 
different terms. What me and Ladislav call "simple" is a different 
thing, and it seems Carl agrees with us; changing REBOL your way 
would not be "simple" in our (me, Ladislav, Carl, etc.) sense.

(and, I guess, the same applies to Gabriele as well)

 - correct, as I said, 99.99% of the time copy/deep is not necessary 
 for make object!. The only time i've had to think about using it 
 in the past 12 or so years... is the above example.

I do have a situation where I need to safely and deeply copy an object, 
namely in the undo system, I am building for a program.

Now, before you suggest a fourth type of equal test, maybe you should 
reconsider your statement, that this is a simple part of the language?

 - Ah, so now you are saying that the problem is that REBOL's MOLD 
 function does not *show* the binding of words?


This has nothing to do with simplicity, rather, it has to do with 
being intuitive. make object! changing the binding of words inside 
your B block is not intuitive, i agree. Intuition is not very useful 
when programming; still, there are many programming languages that 
try to be intuitive. I think REBOL is the *least* intuitive, especially 
if you have learned something about programming already.

How do you know, it was intended?

 - because not copying the block passed to make object! is an intentional 
 "optimization". If you don't believe us, ask Carl. If it turns out 
 we are wrong, Carl will add the copy and you will be happy. :-)

«When I say "bug", I might mean "design flaw".» - then call it design 
flaw. I will call it a designed feature, as it turns out to be very 
useful in practice. There are many alternative languages out there 
if what you want is intuitive behavior, for some definition of "intuitive".

Henrik, safely and deeply copying an object is not the same thing 
as copying the spec block you pass to make object!.

Perhaps not, and I don't have the spec block anyway. It may turn 
out to be full of other objects.

Gabriele, I'm afraid, the consequence of such complicated rules is, 
that most programmers will put in COPY/DEEP many places in the code 
in front of blocks. By "most programmers" I mean every REBOL programmer 
except maybe 3.


I don't follow you, when you say, it's an intentional "optimization" 
and then argue, it's a useful feature, we can't live without.

then call it design flaw


When I first saw it, I didn't know, it was intentional behaviour. 
To me, it looked clearly as a bug, so I called it a bug.

Gabriele, if we continue with design flaws related to binding, the 
following is to me in that category:

>> blk: [x]
== [x]
>> x: 1
== 1
>> context [x: 2 append blk 'x]		; 1st alternative x

>> use [x] [x: 3 append blk 'x]		; 2nd alternative x just to show 
different ways to do this
== [x x x]
>> blk
== [x x x]
>> reduce blk
== [1 2 3]


I came to think of this from your comment on scope. To me, REBOL 
does have scope, it's just different from most languages. In REBOL, 
every word belong somewhere, and three times the same word in a block 
can belong to three different places. That's the scoping rules. Now 
I want to save and load that block:


>> save/all %/tmp/ex1.r blk	; using /all , even if it makes no difference 
here, but this questions /all, doesn't it?
>> blk: load %/tmp/ex1.r
== [x x x
]
>> reduce blk
== [1 1 1]


So doing that changes everything. This design flaw (you may call 
it a "design feature") can be the cause of so much confusion and 
program failures, that I might even call it a "bug". ;)

'This design flaw (you may call it a "design feature") can be the 
cause of so much confusion and program failures, that I might even 
call it a "bug". ;)' - that is (IMO) neither of "design flaw", "design 
feature", "bug". I think, that it is a problem, which you might help 
to solve if you come with a good idea ;-)

Typing into the console (REBOL prompt) can be considered the same 
as appending to a block. If I type the same word several times, each 
has the same meaning. So the block should define the binding, not 
each word.

Aha, so you do not want to suggest any LOAD/MOLD changes, you want 
to have C

But, how that can help you with the above issue is a mystery

Example:

x: 1
blk: []
context [x: 2 append append blk 'x 'x]
reduce blk ; == [2 2]
reduce load mold blk ; == [1 1]

(and that is not the only way how to run into trouble)

So, good luck with that!

In your last example here, blk is created outside the context block. 
What I suggest is, that when you append x to blk, it doesn't matter, 
where you do that. The block defines the binding. So reducing blk 
in your example should give [1 1], and reduce load mold blk should 
also give [1 1]. Appending words to a block should mean that: appending 
words.

Just being curious how does the "the block defines the binding" apply 
to the following?


dr: func [block /local r] [r: copy [] foreach sb block [append/only 
r reduce sb]]
x: 1
blk: [[x]]
context [x: 2 append/only blk [x]]
use [x] [x: 3 append/only blk [x]]
blk
dr blk
dr load mold blk

- "The block defines the binding".
It's against Rebol's first law. 
AFAIK binding (context) is a property of words. Series have not.

the consequence of such complicated rules

 - I don't understand where the complication is. Should writing a: 
 [...] also do a copy? Should everything do a copy? You're arguing 
 that sometimes REBOL should copy things, sometimes not. *That* is 
 a list of complicated rules.

most programmers will put in COPY/DEEP many places in the code in 
front of blocks.
 - how many programs on rebol.org do this?

BIND modifying the block is a useful feature at times. For example, 
the copy that has been added "for security reasons" in many places 
makes a number of "tricks" harder to do.

To me, REBOL does have scope, it's just different from most languages.

 - oh well, of course you are free to change the definition of  the 
 word "scope" so that it fits REBOL... lol.

MOLD missing words context: where did I ever say this was a feature? 
As Ladislav said, this is just a non-trivial problem, because to 
solve it you may have to save the whole interpreter state. (One of 
your X there is bound to system/words, if you save that you basically 
save everything.)

So the block should define the binding, not each word.
 - that kills dialecting.


Geomol, really, have a look at Scheme. It works exactly like you 
want... REBOL works differently for a reason.

Ladislav, if you try follow my thoughts, you can figure that out 
yourself.


Steeve, maybe that law is a design flaw, that causes many problems? 
Like the example returning "bug", which started much of this conversation.


Gabriele, ... Gabriele, you strengten my tolerance, and thank you 
for that. "that kills dialecting" I've seen you writing that before, 
and it puzzles me every time. (Well, probably different understanding 
again.) Thank you for suggesting Scheme, but I don't have time to 
dig into a new language right now.

Should we let it rest?

Ladislav, if you try follow my thoughts, you can figure that out 
yourself.
 I cannot, but nevermind

Gabriele, it hard to have a conversation, when you go to extremes 
like in the following:


I don't understand where the complication is. Should writing a: [...] 
also do a copy? Should everything do a copy? You're arguing that 
sometimes REBOL should copy things, sometimes not. *That* is a list 
of complicated rules.


Do REBOL copy things sometimes today? Like in function definitions:

make function! spec body


Maybe REBOL should copy in the example, we discuss, maybe it's a 
bad idea. The complication (for me and most likely others) in the 
above example is, when I read it, I would expect some output from 
my intuition. The actual output is different, and it's really hard 
to see, why that output is intentional.

MAKE function! doesn't copy its arguments. The wrappers for it in 
R3 copy their arguments explicitly, but the MAKE operation doesn't, 
for efficiency and flexibility. The same goes for MAKE closure! vs. 
CLOSURE, and MAKE module! vs. MODULE (for unbinding, not copying).

None of these copy by default for three reasons:

- You can't uncopy something that's been copied, but you can copy 
something that hasn't been copied yet.

- MAKE doesn't take options that can't fit in its argument(s), so 
optional behavior can only happen if the spec says so.

- Efficiency means avoiding copying, particularly in a non-compiled 
language. That's why a so many functions are modifying.

Yes, and there is no reason, why such a rule could not be held for 
e.g. CONTEXT, to follow the suit as well