World: r3wp

And, one more note to the ability to modify the code:


* since the REBOL's ability to modify the code blocks (and, create 
self-modifying code this way) lies at the heart of REBOL's reflexivity, 
which allows to define and process unlimited amount of REBOL dialects, 
I am strictly *for* keeping this feature in REBOL.

As demonstrated above, it is easy (simple) to avoid *undesired* code 
modifications anyway.

BTW, did you already succeed to get your head around the difference 
between a function and a closure?

;-)

Yeah, I have a reasonable understanding of what a function and a 
closure is, and if I remember correctly, R2 functions are neither 
... or are a combination.


Back to the self-modifying code when making objects. Look at this:

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> o: make object! b
ok
>> ? b
B is a block of value: [print 'ok a: 1]


Since making the object doesn't change the block, do you still think, 
the above bug isn't a bug in REBOL?

* since the REBOL's ability to modify the code blocks (and, create 
self-modifying code this way) lies at the heart of REBOL's reflexivity, 
which allows to define and process unlimited amount of REBOL dialects, 
I am strictly *for* keeping this feature in REBOL.


Gettin' rid of this bug doesn't mean, we should or would sacrifice 
self-modifying code, so I don't understand, why you bring this argument 
up.

Since making the object doesn't change the block

 - it does, I leave it as an exercise for the reader to find out how

Gettin' rid of this bug doesn't mean, we should or would sacrifice 
self-modifying code

 - actually, you get rid of the bug by not writing a self-modifying 
 code. Unless you forbid me to write a self-modifying code, I can 
 always recreate the bug.

(one way or the other)

I have a reasonable understanding of what a function and a closure 
is, and if I remember correctly, R2 functions are neither ... or 
are a combination

 - this looks quite superficial. Seems to me you did not read the 
 suggested section of the article and have actually no idea.

(the general definition does not apply to REBOL closures, I am not 
sure I picked a correct name, that may be my mistake)

:) ok

Since making the object doesn't change the block" - it does, I leave 
it as an exercise for the reader to find out how"

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> b2: copy b
== [print 'ok a: 1]
>> make object! b
ok
>> b = b2
== true
>> b == b2
== true


b and b2 are clearly not the same, so I won't test that. 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? And that 
my claim of this being a bug has something to it.


(I know, the difference lies in the binding, so you don't have to 
make any 'smart-ass' points about that, just take a step back and 
look at all this again. That's all I'm asking.)

I don't understand. Are you trying to prove (incorrectly) that the 
MAKE OBJECT! [...] expression does not mutate the block?

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.

Moreover, as already mentioned at least three times: it is easy to 
avoid any problems. It suffices to use a non-modifying SAFE-OBJECT 
function.

If you still try to pretend that there is no difference between the 
SAFE-OBJECT [...] expression and the MAKE OBJECT! [...] expression, 
then you are just presenting your stubbornness, rather than the will 
to find out how the things work.

Anyway, for the readers that are curious, here is the explanation:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1

While, we still get:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third a ; == [print 'ok a: 1]

Sorry, just a paste problem, AltMe is not exactly comfortable as 
far as cut and paste goes.

what does 'third mean on a block?

Posting once again, to not confuse anybody:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1
get third a ; == [print 'ok a: 1]

ah, ok... :)

To not bee too critical, here is a session from the R3 console using 
Geomol's code, which reveals an iconsistency in the R3 == function:

>> b: [print 'ok a: 1]
== [print 'ok a: 1]

>> b2: copy b
== [print 'ok a: 1]

>> make object! b
ok
== make object! [
    a: 1
]

>> b = b2
== true

>> b == b2
== true

>> (third b) == (third b2)
== false

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.