Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

The truth about scope

 [1/45] from: gabriele::colellachiara::com at: 13-Apr-2005 13:01


Hello all, I'll try to say a few words on the topic too. I really hope this helps, and please forgive me if this doesn't make any sense to you. :) REBOL is not the way it is for speed. It's this way because it's simpler, and much more powerful. Yep, simpler. Other languages have scope, REBOL doesn't, so it's actually simpler. And I think this is the source of all your problems: REBOL has no scope . As long as you think in terms of scope, you may get into problems. Now, REBOL gives you the illusion of having something like a scope for "variables". This is just an illusion that is there because it is useful to let new users think that way. You don't have to learn all at once, but can learn one step at a time. Forget about scope and variables. Make your cup of tea empty, so that it can be filled again. :) Everything is data, Gregg says. Let's start from that. So, what is a block? A block is a series of REBOL values. In other words, an ordered sequence of values. More precisely: an ordered sequence of references to values. The "references" thing is an important one. You will have probably noticed the effects of this. The simplest example is:
>> s: "A string."
== "A string."
>> b: reduce [s]
== ["A string."]
>> insert skip s 2 "modified "
== "string."
>> s
== "A modified string."
>> b
== ["A modified string."] The first (and only) element of B is not a copy of the string S, it's a reference to it. S and the first element of B are actually the same value. (Almost, there's a detail I'm not going to reveal here, for the sake of simplicity.) So far, so good. Isn't it? Blocks just contain references to values. They can contain any number of such references. Now comes the scoop: what is a word? A word is a symbol, and a reference to one REBOL value. Is that confusing? Maybe. But that's how things are. A word is like a block with just one value. Don't be fooled by contexts and scope, the value is referenced directly by the word value, just like if it was a block with one value slot. If you think everything it's clear up to here, I'll go on and explain what binding means. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [2/45] from: mokkel:gmx at: 13-Apr-2005 14:36


Hello Gabriele,
> the same value. (Almost, there's a detail I'm not going to reveal > here, for the sake of simplicity.)
So what's the detail ? :-) You could reveal it in the answer to this post. :-) Otherwise: Your answer is in some part what I tried to criticize a bit. For the newcomer to Rebol, RT tries to give the impression it's just a normal language --- but way more powerful ---- but the there is never a concise description of what it is supposed to be that is more powerful (execpt statements like dialecting and such). Over the time one can collect all the little pieces from various pages and articles or Carls comments. But what stays is that in normal dayly use the "kind of normal" lexical scoping rules (and such things) dominate and people use it like this. I understand if the first pages on the Rebol documentation would put the theory first, some people would be scared or wouldn't like it anymore, but it might prevent problems in the long run. And if Rebol is that much easier there should be made an attempt at the beginning to explain this to the people. But thanks for your explanations. I would like to hear you explanation of the persistence of blocks in functions. :-) Or maybe you can correct mine. f: func [x /local bl] [ bl: [] append bl x ]
>> f "hello"
== ["hello"]
>> source f
f: func [x /local bl][ bl: ["hello"] append bl x ] Is it correct that: Because it's only data anyway, the block after the "bl:" is the representation of that particular block during interpretation of that function. Thus if the function appends something to it, the block changes and so its written representation. On the other side when we copy the block before that (bl: copy []), the interpreter encounters again that block, the written representation doesn't change, its still for that block, but the now we got a runtime object attached to the word 'bl and for this runtime-block we don't have anymore a written representation and thus it has the same effect as it would be created everytime new (or just on every function invocation we have an empty block in 'bl). So the point is that because of the evaluation of the function in the first case bl holds a value we have some "persistent" representation for (in the function code/data) and in the second it just exists at runtime and if we would 'save the function it would be lost, unless we try to save it explicitely. Like that: f: func [x /local bp bl] [ bp: [] bl: copy [] append bl x append/only bp bl ]
>> f "hello"
== [["hello"]]
>> f "you"
== [["hello"] ["you"]]
>> source f
f: func [x /local bp bl][ bp: [["hello"] ["you"]] bl: copy [] append bl x append/only bp bl ] So is my model correct in this regard ? Thanks again. Michael

 [3/45] from: gabriele:colellachiara at: 13-Apr-2005 16:14


Hi Michael, On Wednesday, April 13, 2005, 1:36:19 PM, you wrote:
>> the same value. (Almost, there's a detail I'm not going to reveal >> here, for the sake of simplicity.)
MB> So what's the detail ? :-) You could reveal it in the answer to this post. MB> :-) You want to know too much. ;) I'll give you a hint: position. (So now you have a puzzle to solve. ;) MB> Your answer is in some part what I tried to criticize a bit. For the MB> newcomer to Rebol, RT tries to give the impression it's just a normal MB> language --- but way more powerful ---- but the there is never a concise MB> description of what it is supposed to be that is more powerful (execpt MB> statements like dialecting and such). I agree, we need more docs. How many times did I write "we need more docs" in the past years? I guess a LOT. :) MB> And if Rebol is that much MB> easier there should be made an attempt at the beginning to explain this to MB> the people. Simpler, not easier. It has been suggested that "agile" or elegant may be better words. It turns out, indeed, that simpler almost always means more difficult. MB> So is my model correct in this regard ? It is. Everything is data, the function body block is data too. Another example that may clarify it more:
>> b: [bla: []]
== [bla: []]
>> b2: second b
== []
>> insert b2 "hello"
== []
>> b
== [bla: ["hello"]] This doesn't surprise you, does it?
>> f: func [] [bla: []] >> b2: second second :f
== []
>> insert b2 "hello"
== []
>> source f
f: func [][bla: ["hello"]] This is basically the same as above, so if you are surprised just stop thinking about it for a second. :)
>> f: func [x] [bla: [] append bla x] >> f "hello"
== ["hello"]
>> source f
f: func [x][bla: ["hello"] append bla x] Now, if you are surprised here, you should realize that we are doing the same exact thing as above. BTW, even though I think that we need more docs, the best thing to learn something is to discover it by yourself. So trying to develop your own mental model, and proofing it with tests at the console, is really the best way to understand REBOL. It's not the easier way though, that's why we need more docs. Ah, did I say that we need more docs? (Sorry Gregg for copying your style. ;) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [4/45] from: grantwparks:ya:hoo at: 13-Apr-2005 7:55


Thank you. This is a great way to hammer in the core concepts of the language to those who have lots of programming experience in other languages. --- Gabriele Santilli <[gabriele--colellachiara--com]> wrote:

 [5/45] from: maarten:vrijheid at: 13-Apr-2005 17:12


> BTW, even though I think that we need more docs, the best thing to > learn something is to discover it by yourself. So trying to > develop your own mental model, and proofing it with tests at the > console, is really the best way to understand REBOL.
....once upon a time I did that, when I was learning REBOL. I did this with a colleague of mine and the reference model could be captured in a much better name than REBOL: pointer++ That's what is. From pointer++ to binding is just a small step ;-) And then you realize that what's great about REBOL is not that you can do all this. That you can do it with such a small executable on so many platforms and with such speed, *that* is amazing. --Maarten

 [6/45] from: berniegs:prodigy at: 13-Apr-2005 11:40


Hi Gabriele, Yes, that's it! Your explanation is quite clear, and I really appreciate it.
> And I think this is the source of all your problems: REBOL has
no
> "scope". As long as you think in terms of scope, you may get
into
> problems. > > Now, REBOL gives you the illusion of having something
like a
> "scope" for "variables". This is just an illusion that is
there
> because it is useful to let new users think that way. You
don't
> have to learn all at once, but can learn one step at a time.
When I was just starting with Rebol several years ago, I asked on this forum (or whatever list was active then) if I could safely consider Rebol contexts as the equivalent of scopes in other languages. The answer I received was that I could do that for most purposes. Well, now I'm finding that the answer was the truth, but only up to a point, and now I need to know the "real truth". As you just pointed out, scope is an illusion, and thinking in those terms has indeed gotten me into trouble. I think that it would be appropriate to include an expansion of what you've written here as an appendix to the Rebol User's Guide. It could be considered as something of a Rebol "theory of operation guide", or something like that. It wouldn't be necessary for a beginner to study it, but it would be there for others wishing to get into more advanced applications. I think it would be an extremely helpful contribution to the Rebol documentation.
> If you think everything it's clear up to here, I'll go on
and
> explain what binding means.
Yes, it's much clearer now. You did a great job. Please continue with contexts and bindings. Best regards, Bernie Schneider The individual has always had to struggle to keep from being overwhelmed by the tribe. To be your own man is a hard business. If you try it, you will be lonely often and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche --

 [7/45] from: greggirwin:mindspring at: 13-Apr-2005 10:15


GS> Ah, did I say that we need more docs? (Sorry Gregg for copying GS> your style. ;) :) Maybe we can come up with a good mantra here... Everything is data; blocks of values "Scope" is an illusion Words refer to values, they don't contain them -- Gregg ...the power of a language is a way of measuring how much the language helps you concentrate on the actual problem you wanted to solve in the first place, rather than having to worry about the constraints of the language. -- Brian Harvey

 [8/45] from: andreas:bolka:gmx at: 13-Apr-2005 19:27


Thanks for your precise post Gabriele, much appreciated. Wednesday, April 13, 2005, 1:01:08 PM, Gabriele wrote:
> Now, REBOL gives you the illusion of having something like a "scope" > for "variables". This is just an illusion that is there because it > is useful to let new users think that way. You don't have to learn > all at once, but can learn one step at a time. > Forget about scope and variables. Make your cup of tea empty, so > that it can be filled again. :)
That's certainly just and true when learning REBOL and I wholly second that recommendation. But let me add another angle: In general, scope is always an illusion (or an explanatory concept, to use other words) which needs to be implemented in one way or another. The point where REBOL differs from most other languages is that you have language-level access to the "scoping" implementation - via 'bind and friends. -- Best regards, Andreas

 [9/45] from: volker:nitsch::gmail at: 13-Apr-2005 19:53


On 4/13/05, Michael Berg <[mokkel--gmx--de]> wrote:
> Hello Gabriele, > > the same value. (Almost, there's a detail I'm not going to reveal
<<quoted lines omitted: 10>>
> what stays is that in normal dayly use the "kind of normal" lexical > scoping rules (and such things) dominate and people use it like this.
The advantage of rebols scoping is that you can cut code in pieces and the pieces keep their old scope. which is usefull with dialecting, because dialecting is cutting code in pieces for a big part. :)
> I > understand if the first pages on the Rebol documentation would put the > theory first, some people would be scared or wouldn't like it anymore, but > it might prevent problems in the long run. And if Rebol is that much > easier there should be made an attempt at the beginning to explain this to > the people.
Just ignore scoping at the beginning. its hard enough to learn. you can code it rebol with globals only at first. (if you begin coding. if you begin moving from another language, thats a different matter ;)
> But thanks for your explanations. > I would like to hear you explanation of the persistence of blocks in > functions. :-)
I respectless jump in: because 'if and friends are functions too. now the language-designer could choose: 1) give people auto-copy. then 'if and friends have to copy their code-blocks too. pretty slowdown. 2) don't give auto-copy. people get usually confused. but if you show them with a short 'source, they get it quickly: if you need it as data, use 'copy. 3) do something complicated which works in all situations. unfortunally all my good ideas have proven to be flawed. i guess Carl realized even him can not do better. :) so he choosed 2)
> Or maybe you can correct mine. > f: func [x /local bl] [
<<quoted lines omitted: 13>>
> function. Thus if the function appends something to it, the block changes > and so its written representation.
yep. other example: coming?: func [x /local bl][ either x ["hello"]["bye"] ] the blocks are not copied too, just passed to 'either.
> On the other side when we copy the block before that (bl: copy []), the > interpreter encounters again that block, the written representation
<<quoted lines omitted: 3>>
> would be created everytime new (or just on every function invocation we > have an empty block in 'bl).
Hum, i would say you get a copy of the block. and that copy is created everytime new. and since we change only the copy, the original stays the same. but you can also explain it your way :)
> So the point is that because of the evaluation of the function in the > first case bl holds a value we have some "persistent" representation for
<<quoted lines omitted: 19>>
> ] > So is my model correct in this regard ?
Yes.
> Thanks again. > > Michael > -- > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject. >
-- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [10/45] from: mokkel:gmx at: 13-Apr-2005 21:22


Hello Gabrielle,
> MB> So what's the detail ? :-) You could reveal it in the answer to this > post. > MB> :-) > > You want to know too much. ;) > > I'll give you a hint: position. > > (So now you have a puzzle to solve. ;)
I have no idea what you really mean. :-) I think you don't talk about the position because of the block, or that the interpreter encounters the block later. My other guess was that a block is itself not automatically evaluated and thus the string inside might not change immediately, unless it gets evaluated again and maybe updates the string. (Looking at the block in any way, like printing it or probing it is already evaluating it, thus showing a change, for the case that it really only shows up after an new evaluation.) On the other side this shouldn't have anything to do with the value. :-) So ???? Pleaaaaasee tell meeee. I beg you. ;-) Besides that, I think I really just got what you meant with the "no-scope" statement. Not that it would change anything, but haven't seen the code is data thing too globally so far. Michael

 [11/45] from: greggirwin:mindspring at: 13-Apr-2005 14:05


>> I'll give you a hint: position. >> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> b: next a
== [2 3 4 5]
>> c: skip b 2
== [4 5]
>> reduce [same? a b same? b c same? a c]
== [false false false]
>> reduce [same? a head b same? head b head c same? a head c]
== [true true true]
>> reduce [same? at a 2 b same? at b 3 c same? tail a tail c]
== [true true true] http://www.rebolforces.com/articles/series/ -- Gregg

 [12/45] from: Izkata:Comcast at: 13-Apr-2005 18:57


> Another example that may clarify it more: >>> b: [bla: []]
<<quoted lines omitted: 20>>
>>> source f > f: func [x][bla: ["hello"] append bla x]
Ah! That reminds me of something I have been experimenting with... Quick example:
>> Data: [4 7 2 9]
== [4 7 2 9]
>> New: rejoin [
[ {Here's the data:} newline [ foreach TMP Data [append {} join TMP { }] [ newline newline [ {Here's the data * 5:} newline [ foreach TMP Data [append {} join TMP * 5 { }] [ ] == {Here's the data: 4 7 2 9 Here's the data * 5: 20 35 10 45 }

 [13/45] from: pwawood:mango:my at: 14-Apr-2005 7:57


GI>> Words refer to values, they don't contain them But surely a word is simply a value that is a reference to another value which in turn could be a reference to another value (and so on) ? Regards Peter -- Internal Virus Database is out-of-date.

 [14/45] from: greggirwin:mindspring at: 13-Apr-2005 22:05


Hi Peter, GI>>> Words refer to values, they don't contain them P> But surely a word is simply a value that is a reference to another value P> which in turn could be a reference to another value (and so on) ? Of course, if the values referred to are words.
>> d: 1 c: 'd b: 'c a: 'b
== b
>> a
== b
>> get get get a
== 1 The mindset shift, for me, is to be conscious that the value exists independently of the word. That is, words refer to values that exist somewhere . -- Gregg

 [15/45] from: lmecir:mbox:vol:cz at: 14-Apr-2005 7:08


Hello Michael, ....
>I have no idea what you really mean. :-) I think you don't talk about the >position because of the block, >
.... I would say that my POV (as well as yours as far as I can guess) differs from Gabriele's POV in this respect. Gabriele seems (sorry for my "wild guess") to try to discern the following: string: "a string" block: reduce [string string] ; == ["a string" "a string"] While I am saying that the first element of Block and the second element of Block are identical and don't differ in any respect (i.e. it is just one Rebol string referenced twice), Gabriele seems to present a POV, that the first element is at the first position of the block while the second element is at the second position of the block. Such an opinion is an illusion, because the position in Block is not a property of the string. It is rather a property of the block, which surealy has "positions" or "places" able to refer to Rebol values. So, it is safe to say, that the first position of Block refers (currently) to the same Rebol string as the second position, while it isn't safe to say, that String has got (either first or second) position in Block (because it doesn't have such property at all).
>Besides that, I think I really just got what you meant with the "no-scope" >statement. >
.... I guess you understood Gabriele's argument. It is a fact that there is no scope - Carl usually says "indefinite scope" in Rebol. To say it more explicitly, it means, that the binding of words doesn't depend on their "positions" at all (like in the String example above, Rebol words don't "know" their "positions"). Ladislav

 [16/45] from: mokkel:gmx at: 14-Apr-2005 9:05


Hello Ladislav,
> I would say that my POV (as well as yours as far as I can guess) differs > from Gabriele's POV in this respect. Gabriele seems (sorry for my "wild
<<quoted lines omitted: 13>>
> say, that String has got (either first or second) position in Block > (because it doesn't have such property at all).
I think so too, but I also didn't think of the blocks and that they can have position either (until Gregg was showing this example) as I was just concerned with the element. So I thought I'm missing something else also. :-)
> Carl usually says "indefinite scope" in Rebol. To say itmore explicitly, > it means, that the binding of words doesn't depend ontheir "positions" > at all (like in the String example above, Rebol wordsdon't "know" their > "positions").
That's what I just got in the last days consciously. But this should be also one of the requirements of a keywordless language. For instance (as far as I understand) in Lisp you can do almost the same powerful things as in Rebol just by the raw power of lambdas. But one has a fixed binding model in the way that one knows what variable is bound to what scope when. I guess this is because at least lambda and the few keywords of Lisp have a defined meaning, which never changes. In Rebol on the other side if we can redefine everything and we just have data, then we need the evaluation model (the rules) and if we want to change something to that we have the bind function which can do whatever is needed. Isn't in this sense bind also a keyword, as also in Rebol there have to be some words which have to be "bound" to the core concepts of Rebol in order to make it working at all ? (should be x: x :x 'x 'bind [] () .... where x is just some word and bind is the word bound to the current mechanism for binding a word to a context and the brackets and parents for the evaluation flow and the invisible general interpreter mechanism with it's rules) ??? :-) I'm still trying to get what was Carls intention in developing Rebol, as it sounds nice to be able use every possible word in some context. On the other side if one uses 'parse this isn't anymore exactly this, because to me 'parse is more like a traditional mechanism (even though one can bind a chosen amount of words there also). Just binding a block to a new context and evaluating it is dangerous and thus not really recommended, so again 'parse should be used. But this could be done in every traditional language as well (maybe not as comfortable, but still). So either I have always a trusted source and can happily evaluate and bind, it's very valuable to be able to do it, but if not and I have to start parsing, doesn't Rebol actually looses some if its power ? Just some questions :-). Thanks for listening. Michael

 [17/45] from: lmecir:mbox:vol:cz at: 14-Apr-2005 9:36


Hello Michael: ....
>>Carl usually says "indefinite scope" in Rebol. To say itmore explicitly, >>it means, that the binding of words doesn't depend ontheir "positions"
<<quoted lines omitted: 4>>
>That's what I just got in the last days consciously. But this should be >also one of the requirements of a keywordless language.
Keywordlessness doesn't influence this, as other (less dynamic) languages illustrate, see below.
> For instance (as >far as I understand) in Lisp you can do almost the same powerful things as >in Rebol just by the raw power of lambdas. But one has a fixed binding >model >
The word "almost" is appropriate as well as the "Fixed Binding Model" notion (thank you). That is an exact description of the way the scope rules are supposed to work. There is a fixed set of rules relating positions of variables in the code (scope) and their binding. The problem is, that "Fixed Binding Model" isn't best suited for a dynamic language, because to know the binding one has to know the scope of the variable. (See the need to introduce macros in Lisp, Lispers usually don't understand, that there may be a language not needing macros at all.) As opposed to that Rebol has got "Computed Binding Model", where: 1) every variable "knows" its binding, i.e. the binding is a "data component" of the "variable", which is a "data value" like e.g. integer 2) during execution of "code" the binding of variables is "computed" by functions - the first function starting this is usually the Load function, which "creates" every variable bound to the Global Context (i.e. to the System/words object). This is followed by other functions like Use, Func, Repeat, Foreach, Context or Bind, which continue their common job to "compute" binding. This means, that the binding of a word is a result of several applications of these functions, one after another.
> in the way that one knows what variable is bound to what scope when. >
This holds for *both* the Fixed Binding Model and for the Computed Binding Model. The difference lies in the fact, that to know the binding of a variable in the Fixed Binding Model one has to know the scope of the variable. For the Computed Binding Model holds, that the binding is a "data component" of a word, i.e. you can *inspect* the binding of a variable at any time (e.g. using some of the functions that can be found in http://www.fm.vslib.cz/~ladislav/rebol/contexts.html ). The main difference lies in the fact, that the binding is "computed" by the functions mentioned above, not fixed as in the Fixed Binding Model. ....
>I guess this is because at least lambda and the few keywords of Lisp have >a defined meaning, which never changes. In Rebol on the other side if we
<<quoted lines omitted: 4>>
>be "bound" to the core concepts of Rebol in order to make it working at >all ?
No, you can use any appropriate function to change binding of a variable, not just the Bind function. See e.g. the Context function, which works differently than the Bind function, or the Load function, which works differently than Bind etc. ....
>??? :-) I'm still trying to get what was Carls intention in developing >Rebol, as it sounds nice to be able use every possible word in some >context. On the other side if one uses 'parse this isn't anymore exactly >this, because to me 'parse is more like a traditional mechanism (even >though one can bind a chosen amount of words there also). >
Right again, Parse is "like a traditional mechanism". But I would underline the word *like*. The difference is, that no other language is able to "manipulate itself" in this way. When you use Regular Expressions in some languages, you can manipulate strings. This is exactly the role Parse has when manipulating strings. OTOH, Parse can manipulate blocks, which is the area, where it is unique, no such instrument exists in any other language. This leads to the possibility to write: view layout [button "Hello world"] without a need to change Rebol syntax. This property of Parse isn't actually a property of Parse at all. This is a property of Rebol. Rebol is designed so, that it can "manipulate" itself. You could do it without Parse, you can even define your own version of Parse using other Rebol functions if you wish and the Computed Binding Model is one of the parts of this "puzzle".
> Just binding a >block to a new context and evaluating it is dangerous and thus not really >recommended, so again 'parse should be used. But this could be done in >every traditional language as well (maybe not as comfortable, but still). >
How would you define your own If version in C without breaking the C standards?
>So either I have always a trusted source and can happily evaluate and >bind, it's very valuable to be able to do it, but if not and I have to >start parsing, doesn't Rebol actually looses some if its power ? >
No, this feature is more powerful than the ability to bind, but they are related as I tried to explain above, i.e. the malleability of the language is a result of the way the language was designed including the Computed Binding Model. -Ladislav

 [18/45] from: gabriele:colellachiara at: 14-Apr-2005 11:55


Hi Michael, On Wednesday, April 13, 2005, 8:22:17 PM, you wrote: MB> I have no idea what you really mean. :-) I think you don't talk about the MB> position because of the block, or that the interpreter encounters the MB> block later. Ok... you're off track here. :) A series does not just have the sequence of elements. It also keeps a position in the sequence.
>> b: ["Hello"]
== ["Hello"]
>> s: skip first b 2
== "llo"
>> insert tail s " world!"
== ""
>> s
== "llo world!"
>> b
== ["Hello world!"] The first element of B and the value referred to by 'S are not *exactly* the same value. They are two series values, referring to the same sequence of elements, but at different positions. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [19/45] from: gabriele:colellachiara at: 14-Apr-2005 11:58


Hi Ladislav, On Thursday, April 14, 2005, 7:08:12 AM, you wrote: LM> I would say that my POV (as well as yours as far as I can guess) differs LM> from Gabriele's POV in this respect. Gabriele seems (sorry for my "wild LM> guess") to try to discern the following: Ah, I didn't mean that. :-) But, the problem with being very precise at explaining REBOL is that you soon get into implementation details. Let's get back to topic now. :) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [20/45] from: lmecir:mbox:vol:cz at: 14-Apr-2005 12:17


Gabriele Santilli napsal(a): ....
>The first element of B and the value referred to by 'S are not >*exactly* the same value. They are two series values, referring to >the same sequence of elements, but at different positions. > >Regards, > Gabriele. >
.... my wild guess seems to be correct. Gabriele "combines" values and their positions in series to obtain a notion of a "series value". It is possible, although not very practical IMO. Compare these: string: "a string" block: reduce [string string "a string"] change string "t" probe block If we always combined the "position property" (I, convinced by the the Same? function don't think it is a "part of the value") with other real properties of a Rebol value, our ability to reason about Rebol would have substantially suffered. Let's try to explain it using the "series value" notion. We know that we have got three "series values" here, but two of them are somewhat more related. If we just use a "value" notion, we may say, that we have got a block with three "places" (or positions) referring to just two values. Doesn't it look shorter? -L

 [21/45] from: gabriele:colellachiara at: 14-Apr-2005 12:29


Hi Bernie, On Wednesday, April 13, 2005, 5:40:36 PM, you wrote: BS> Yes, it's much clearer now. You did a great job. Please continue BS> with contexts and bindings. Ok, so to summarize: The is no scope. Everything is data, and the relation between words and values is data too. You can manipulate this relation in the same way you can manipulate the rest of the data. So, the "connection" (binding) between words and their referred values is not a "rule" in the language, like "scope" is, but it is a property of words. Now... what is a context? And what does binding mean? You can think of a context as a table of words and values. Nothing special here - you have words and their "meaning" listed in some kind of table. But, if words directly refer to values, why do we need contexts? The reason we need them, is that words actually refer to values with an additional layer of indirection. A "double pointer" if you want to call it this way. Why? Because otherwise each word instance would have a different reference. Changing one word would not change all the other words with the same spelling. So we have something like: some-word -----------\ ()---------> value some-word -----------/ some-other-word ----->()---------> value The () in the above picture are contained in the second column of contexts. When you write: some-word: 3 you are not changing the leftmost arrow in the above picture, you are changing the rightmost arrow. Basically you are not changing the word, you are changing the context. Setting the value of a word is an operation on contexts, not an operation on words. Words stay unchanged. Now, the scoop: the leftmost arrow is what is called "binding". The operation of binding is the operation of changing that arrow to make it point to some other (). So: everything is data. Words and their relation to other values are data too. What BIND does is take every word in a block and change it so that it refers to a different context's value slot. What gives the illusion of scope? As Ladislav said, when words are loaded (LOAD), they are bound to the global context. Each time a word is created, a value slot for that word is created in the global context (SYSTEM/WORDS), and this value slot is initialized to the UNSET! value. So, every word starts out being bound there. When code is evaluated, some functions may change the binding of words. Actually, many functions do that. What you get in the end is the illusion of scope, because usually those function are applied on blocks that are nested inside each other. However, this is not a requirement, and this usually confuses people, because they are fooled by the illusion of scope. The "lookup" in the context table is only done at binding time. Once the word has been bound, it "directly" (actually, with a double pointer ) refers to the value, so that when you GET the value of a word no lookup is necessary. This has the nice side effect of making REBOL faster, too. This is why we usually call it "static binding". The connection between words and value is a "static" data structure, not the result of a dynamic computation at runtime. Of course, you can change this structure dynamically, like you can change the contents of a block dynamically. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [22/45] from: gabriele:colellachiara at: 14-Apr-2005 12:30


Hi Ladislav, On Thursday, April 14, 2005, 12:17:58 PM, you wrote: LM> my wild guess seems to be correct. Gabriele "combines" values and their LM> positions in series to obtain a notion of a "series value". It is I mean not the position they have, but the position they refer to. NEXT, SKIP etc. create a new value referring to the same sequence but at different positions. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [23/45] from: maarten:vrijheid at: 14-Apr-2005 13:11


> some-word -----------\ > ()---------> value > some-word -----------/ > > some-other-word ----->()---------> value >
I wasn't joking when I called REBOL pointer++. Thanks for the drawing ;-) --Maarten

 [24/45] from: volker:nitsch:g:mail at: 14-Apr-2005 13:12


Hi Gabriele, i guess you made a typo and now we have a misunderstanding. you wrote
>> s: "A string."
== "A string."
>> b: reduce [s]
== ["A string."]
>> insert skip s 2 "modified "
== "string."
>> s
== "A modified string."
>> b
== ["A modified string."] Here s and b/1 are actually the same. i guess you got confused by the insert skip s 2 "modified " if you would store that, s: insert skip s 2 "modified " you would be right. but you did not, they are the same, and everyone is scratching his head ;) On 4/14/05, Gabriele Santilli <[gabriele--colellachiara--com]> wrote:
> Hi Ladislav, > On Thursday, April 14, 2005, 12:17:58 PM, you wrote:
<<quoted lines omitted: 11>>
> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.
-- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [25/45] from: gabriele:colellachiara at: 14-Apr-2005 14:46


Hi Volker, On Thursday, April 14, 2005, 1:12:08 PM, you wrote: VN> i guess you made a typo and now we have a misunderstanding. Well, no. But, that is an implementation detail. The position in series is kept in the value. So, S and B/1, from the point of view of implementation, are two distinct but identical values. Of course, Ladislav is right in saying that because you cannot discern them, they are the same. However, they are not in the current implementation, and my point is that they don't need to be (as with the example with SKIP I showed afterwards) to show the behavior we were discussing. The behavior we were discussing is that of modifying a series value. Series values have a reference to the data sequence and a position in the sequence. What you change with INSERT etc. though is the sequence of elements. So, even though you may have two different series values (same sequence but different positions), you are still seeing the behavior we were discussing. For this reason, the sentence "they are the exact same value" is not precise; first, because it is not true in the implementation (and this doesn't mean much, but not knowing this may lead to a wrong model of the implementation, and having a correct model of the implementation helps when you are dealing with GC bugs and trying to work around them, for example ;), and second because even if the values where not the same exact value you'd get the same result. Anyway, here's the reason why I was leaving this detail without discussing about it. You see, it gets very confusing very soon. ;-) And, it doesn't matter for the explanation. To conclude, I agree with Ladislav that [1 1] may be considered a series containing the same value twice, and I agree that the position in the series is not an attribute of the value. However, we know that in the current REBOL implementation a block is an array of value slots and an integer fits one value slot, so [1 1] is two value slots with two values (which are identical). I agree that this is an implementation detail and that it is irrelevant. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [26/45] from: antonr:lexicon at: 15-Apr-2005 0:31


Time to roll out my little demo. Open a Rebol/View console and paste this: do http://www.lexicon.net/antonr/rebol/demo/demo-series.r Anton.

 [27/45] from: mokkel:gmx at: 14-Apr-2005 17:46


Hi Anton, I might a be a bit lazy, but I tried it with every version of View I have here (4 versions) and none was working. Which should I use. (I could of course also try to find the error in the code - this was the lazyness part :-) I hope you don't mind. Michael On Fri, 15 Apr 2005 00:31:20 +1000, Anton Rolls <[antonr--lexicon--net]> wrote:

 [28/45] from: antonr:lexicon at: 15-Apr-2005 1:08


Hmm, that's strange... I'm tempted to ask, did you press the Enter key afterwards :-) ? I've tried it on: REBOL/View 1.2.1.3.1 (the latest full release), and on REBOL/View 1.2.57.3.1 (the latest beta) and I also don't remember having any problems with it before. What versions did you try it on ? Did you get an error message ? Anton.

 [29/45] from: mokkel:gmx at: 14-Apr-2005 18:22


Hi,
> Hmm, that's strange... I'm tempted to ask, did you press > the Enter key afterwards :-) ?
YES. :-)
> I've tried it on: > REBOL/View 1.2.1.3.1 (the latest full release), and on > REBOL/View 1.2.57.3.1 (the latest beta) > > and I also don't remember having any problems with it before. > > What versions did you try it on ?
1.2.57.3.1 and 1.2.56.3.1
>> do http://www.lexicon.net/antonr/rebol/demo/demo-series.r
connecting to: www.lexicon.net Script: "Demo Series" (27-May-2002) connecting to: www.lexicon.net ** Script Error: include has no value ** Near: include [site/gui/arrow360.r [arrow360-style]] s: [A B C D] t:
>>
1.2.1.3.1
>> do http://www.lexicon.net/antonr/rebol/demo/demo-series.r
Include: Couldn't load-thru http://www.lexicon.net/anton/rebol/gui/arrow360.r ** Script Error: arrow360-style has no value ** Where: do-facets ** Near: arrow360-style
>>
1.2.55.3.1
>> do http://www.lexicon.net/antonr/rebol/demo/demo-series.r
connecting to: www.lexicon.net Script: "Demo Series" (27-May-2002) connecting to: www.lexicon.net ** Script Error: split-path expected file argument of type: file url ** Where: include ** Near: set [dir target] split-path :fl if
>>
:-) Maybe something on my side is wrong, but then it has to be something funny, as I didn't anything else as opening the Rebol commandline and copy and paste. I also let the firewall fetch the script, but this shouldn't be related to the firewall. Well, so far. Michael

 [30/45] from: apwing:zonnet:nl at: 14-Apr-2005 17:54


Hi Anton, I get the following errors: connecting to: www.lexicon.net Script: "Demo Series" (27-May-2002) connecting to: www.lexicon.net Include: Couldn't load-thru http://www.lexicon.net/anton/rebol/gui/arrow360.r ** Script Error: arrow360-style has no value ** Where: do-facets ** Near: arrow360-style HTH, Arie Anton Rolls wrote:

 [31/45] from: berniegs:prodigy at: 14-Apr-2005 12:12


Hi, I get a similar result. Here's my console listing: =================================== REBOL/View 1.2.11.3.1 5-Dec-2003 Copyright 2000-2003 REBOL Technologies. All rights reserved. REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM REBOL Mezzanine Extensions 1.1.2.1 29-Nov-2002/18:29:09 Windows Registry Access 1.1.2.4 10-Dec-2002/23:36:56 Network Auto-Configure 1.6.2.6 10-Dec-2002/23:36:21 REBOL Internet Protocols 1.59.2.15 14-Feb-2003/0:45:14 Dynamic Library Access 1.4.2.1 24-Mar-2002/19:13:53 Command Shell Access 1.5.2.5 10-Dec-2002/23:37:05 Graphics 1.1.2.5 23-Jul-2003/20:32:34 View and VID 1.155.2.6 23-Jul-2003/20:36:38 View Desktop 1.26.2.10 26-Jun-2003/5:00:34 Sound 1.2.2.2 24-Mar-2002/19:13:58 Encryption 1.3.2.2 24-Mar-2002/19:13:52 Big Numbers 1.2.2.2 24-Mar-2002/19:13:52 DH/DSA Encryption 1.2.2.2 24-Mar-2002/19:13:52 RSA Encryption 1.3.2.2 24-Mar-2002/19:13:58 System Port 1.1.2.5 30-Nov-2002/16:24:03 Licensing 1.8.2.6 30-May-2003/6:32:41 *** Visit http://www.REBOL.com to license View/Pro features. Type "desktop" to start desktop. WARNING: CALL function enabled in this version.
>> do http://www.lexicon.net/antonr/rebol/demo/demo-series.r
connecting to: www.lexicon.net Script: "Demo Series" (27-May-2002) connecting to: www.lexicon.net ** Script Error: include has no value ** Near: include [site/gui/arrow360.r [arrow360-style]] s: [A B C D] t:
>>
============================================= Bernie Schneider The individual has always had to struggle to keep from being overwhelmed by the tribe. To be your own man is a hard business. If you try it, you will be lonely often and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche --

 [32/45] from: berniegs:prodigy at: 14-Apr-2005 12:08


Hi Gabriele, Thanks very much. This stuff is quite helpful. Regards, Bernie Schneider The individual has always had to struggle to keep from being overwhelmed by the tribe. To be your own man is a hard business. If you try it, you will be lonely often and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche --

 [33/45] from: antonr:lexicon at: 15-Apr-2005 2:25


Agh! Totally my fault, was referring to the old site. (...just testing how alert you were.) *Now* should work. Anton.

 [34/45] from: volker:nitsch:g:mail at: 14-Apr-2005 18:42


On 4/14/05, Gabriele Santilli <[gabriele--colellachiara--com]> wrote:
> Hi Volker, > On Thursday, April 14, 2005, 1:12:08 PM, you wrote:
<<quoted lines omitted: 4>>
> the point of view of implementation, are two distinct but > identical values.
Now i get it. The confusing point is then, you put s in a series. that leads to the conclusion a series in a series is different. but you mean: a: [] b: a c: b d: reduce[c] now a, b, c and d/1 reference the same block and the words contain the same bits, but the bits are on different memory-locations. they "mean" the same, but they are not the same. i was using "same" in the meaning-sense. and then skipping sticks with the series, but is a bit diffent, so different for the 'same? - function. while an exact copy is same in the 'same? - sense. so i thought you want to demo that and forgot the assignment. sorry ;) -- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [35/45] from: mokkel:gmx at: 14-Apr-2005 19:44


Nice script. So it works. :-) Michael On Fri, 15 Apr 2005 02:25:59 +1000, Anton Rolls <[antonr--lexicon--net]> wrote:

 [36/45] from: mokkel:gmx at: 14-Apr-2005 21:17


Hi Gabrielle,
> The reason we need them, is that words actually refer to values > with an additional layer of indirection. A "double pointer" if you
<<quoted lines omitted: 6>>
> some-word -----------/ > some-other-word ----->()---------> value
I just would like to make sure that I understood it correctly. One could describe a simple example as follows: [ f: func [x] [print [x]] f 1 ; == 1 x: 2 b1: reduce [first second second :f] ; == [x] print b1 ; == 1 ] - () is the indirection pointer Gabrielle used in his arrow sketch, which belongs to a certain word while running the script - value is the right-most side he used global context table: () | value -------------------------------------------------- 'f | reference to 'f 'print | reference to 'print 'first | reference to 'first 'second | reference to 'second 'func | reference to 'func [] | reference to function argument block [] | reference to function body block [] | reference to reduce block 'b1 | reference to reduce block 'x | 2 function context table: () | value ---------------------------------------- 'x | unset! or later 1 [] | block in function block The left side with the words from Gabrielles sketch is either a second table with names which could be there more than once or just references in the Rebol internal structure when interpreting a block. Could it look like that ? [ f-1: func-1 [x-1]-1 [print-1 [x-2]-1]-1 f-2 1 ; == 1 x-3: 2 b1-1: reduce-1 [first-1 second-1 second-2 :f-3]-1 ; == [x-4]-1 print-2 b1-2 ; == 1 ] The -X means always a reference to the according 'word in question in the context table. If I understood correctly that has to be like that as we have actually just data, so after one run of evaluation a block of data it's still just data and we need more versions of one word (this is what I understood as "instances" of a word). So Rebol musst keep internally some map of internal identifiers to names in the block. Like word -> context () ---------------------------- f-1 -> 'f in global context x-1 -> 'x in function context x-2 -> 'x in function context x-3 -> 'x in global context x-4 -> 'x in function context .. .. .. So if one updates or changes 'x in the function context x-1, x-2, x-4 will change too. But if I would bind x-2 into the global context then only the word -> context mapping table has to be modified. Maybe Ladislavs view is even easier, to think just of every instance as some kind of object which has an attached context field and a value field which is double referenced, thus referes to the () and then to the value (or just the () field which is the context anyway). The reason I'm so verbose is that I didn't see so much the need of the leftmost part with the "instances" of a word or wasn't sure what is exactly meant by instances of a word. But because we don't have code and a fixed scope for the variables we can't reduce it to just one word per scope and thus there have to be the many "instances" of one word. I hope I don't annoy somebody with these lengthy post. But I have the feeling that this thread is/was very informative to me at least, stuff I hadn't figured out in detail so far. (unless now somebody tells .... ääähm yes, but .... ) :-) regards Michael P.S.: I thought about just deleting the post, but maybe it's not that stupid (and obvious) after all.

 [37/45] from: lmecir:mbox:vol:cz at: 15-Apr-2005 7:42


A short terminological "detour":
>Hi Volker, >On Thursday, April 14, 2005, 1:12:08 PM, you wrote:
<<quoted lines omitted: 4>>
>the point of view of implementation, are two distinct but >identical values.
This deserves one more comment I think. My POV is: *Value sameness doesn't depend on implementation at all.* Proof: For every mathematician (and some other people too, I hope) knows, that there is only one number one (1). It doesn't matter, that a computer language implementor chooses (practical reasons) to "store" the value at different "positions" in the computer memory. Everybody knows, that all 1's are actually just one (mathematical) 1. Although you surely could say, that the "1's" "stored at distinct places in the memory" are "distinct but identical", such a sentence doesn't have much sense, regardless of the implementation, because you are coupling the number with something, that is not a property of the number at all - the place in the computer memory where the number "resides".
> Of course, Ladislav is right in saying that >because you cannot discern them, they are the same. However, they >are not in the current implementation, >
This is the point showing an "implementation-dependent" look at identity. ....
>To conclude, I agree with Ladislav that [1 1] may be considered a >series containing the same value twice, and I agree that the
<<quoted lines omitted: 5>>
>Regards, > Gabriele.
Conclusion: The main difference, as Gabriele pointed out, is terminological. An implementation-independent terminology is less confusing. (Does not force us to use notions like "distinct but identical"). The only "disadvantage" of it is, that it doesn't try to "directly" describe the implementation, although there aren't any real obstacles to use it when describing the implementation and say, that "one value 1 is stored at two places in the computer memory". Some may feel a "lack" when speaking about modifications like: (implementaion-dependent terminology): I had two "distinct" 1's in the computer memory. I changed the first one to 2. Now I have got one 1 and one 2 in the computer memory. (implementation-independent terminology): I had number 1 "stored" (I can use a notion "referenced by" or "referred to" if I prefer) at two places in the computer memory. I changed the first memory place (Not number 1, nobody is actually able to change number 1!) to "contain" number 2 instead. Now I have got number 1 "stored" at one place in the computer memory and number 2 "stored" at another place in the memory. -Ladislav

 [38/45] from: gabriele:colellachiara at: 15-Apr-2005 13:02


Hi Ladislav, On Friday, April 15, 2005, 7:42:21 AM, you wrote: LM> *Value sameness doesn't depend on implementation at all.* I perfectly agree, from an "abstract" point of view. LM> The main difference, as Gabriele pointed out, is terminological. Yes, however the subtle detail we are dealing with may matter in the mental model of, say, a C programmer, who tries to visualize how this would translate into C structures. The difference is that of a pointer versus an "inline" structure. The difference is that of blocks being an array of pointers to values versus being an array of values. It's just an implementation detail, and probably I shouldn't care at all and use an implementation-independent terminology, however I see it as a difference in my head... sorry about that. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [39/45] from: lmecir:mbox:vol:cz at: 15-Apr-2005 14:09


Hi Gabriele: ....
> however I see it as >a difference in my head... sorry about that. :-) >
no need to apologize. My "detour" was meant as a warning for the readers of my articles that a different terminology exists and is used there. Moreover, the RSharp implementation from Doc implements values differently trying to remain compatible nevertheless. -L

 [40/45] from: gabriele:colellachiara at: 15-Apr-2005 19:47


Hi Michael, On Thursday, April 14, 2005, 8:17:01 PM, you wrote: MB> Hi Gabrielle, BTW, just one "l". ;-) MB> I just would like to make sure that I understood it correctly. One could MB> describe a simple example as follows: [...] To make things clearer: considering every word in the same context with the same spelling the same word would probably simplify this, but then you won't really need a "double pointer". The problem with "implementation details" and REBOL, is that we have no idea about what really is an implementation detail, and what is by design. What we know as been mostly obtained by experimenting on the current implementation. So, basically everything we know is an implementation detail. So I'll go into the details now, while still trying to give a simple explanation. The key concept in the implementation is the "value slot", which is basically 16 bytes of data (on 32 bit machines - there is no 64 bit version of REBOL currently so 16 bytes should be correct on all versions available). A value slot can contain completely the scalar values (i.e. integers, tuples, words, and so on); for series values, it contains a pointer to the actual sequence and an offset in the sequence (the position). (Note that LIST!s are different here.) A block is basically an array of value slots. A context is a table with "words" on the first column (probably it's not WORD! values, but you may safely assume so), and value slots on the second column. So, words will have a pointer to the value slot in the context. That value slot is what gets changed when you SET the value of a word. The pointer to the value slot is what changes when you BIND a word. Now, the reason for talking about "instances" is that the same word in two different value slots is two instances of the same word for me. If they are bound to the same context, they will point to the same value slot inside that context. If they are bound to different context, they aren't the same word anymore, and point to different value slots. I'm not sure if this helps, if you find it more confusing please ignore it completely. :) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [41/45] from: mokkel:gmx at: 16-Apr-2005 2:06


Hi Gabriele, (or whoever dares to read this :-) - I appologize for the length beforehand ) sorry for the wrong name, I should have seen it in the e-mail address. I guess I got now the model correctly, also with the different views, which have come up during the thread. I tried to create below some small showcase of how Rebol works, if I'm not too wrong that should be pretty all. If one adds evaluation of words and their different types, then this should be the basic components. Of course during evaluation things get much more complicated, but the basic issues should be like that. 1) - every Rebol object is somehow put into or referenced from a container (gets the name value-slot - for now) - a block is simply a list (however implemented) of value-slots ------------------------------------------------------- e.g. [1 "hallo" a] -> [(1) (|,1) (a)] | | | (unset!) | (h)-(a)-(l)-(l)-(o) () = represents a value slot (|,0) = a pointer to some other slot and with series position (1) = value slot with native value (a) = value slot with word which references a value slot a: 5 [1 "hallo" a] -> [(1) (|,1) (a)] | | | (5) | (h)-(a)-(l)-(l)-(o) 2) words have a context, which is a mapping of words with different spelling to a value-slot (in the most extreme case just to one value-slot if every words referes to the same ------------------------------------------------ a: b: c: 1 d: next "hallo" context-table: word -- value-slot a --\ b -- (1) c --/ d -- (|,2) | (h)-(a)-(l)-(l)-(o) 3) creating new objects out of other object simply copies its value-slot --------------------------------------------------------- a: 5 bl: [a 1 "hallo"] bl2: [] append bl2 bl bl -> [(a) (1) (|,1)] | | (5) | | (h)-(a)-(l)-(l)-(o) | | | | bl2 -> [(a) (1) (|,1)] 4) binding a word to a new context simply changes the pointer to the value-slot of the word in the new context ----------------------------------------------------------- a: 1 c: context [a: 5] bl: [a] global-context-table: word -- value-slot a -- (1)* c -- (|) ;references a block of dataelements | [(a:) (5)] bl-- (|) | [(a)] | (1)* ;is the same value-slot as in the context table, thus a is bound to global context c-context-table: word -- value-slot a -- (5)*** binding 'a in the block 'bl to context of block attached to 'c bind bl in c 'a bl -> [(a)] | (5)*** ; bound to the context of the block attached to 'c or via global context-table global-context-table: word -- value-slot a -- (1)* c -- (|) | [(a:) (5)] bl-- (|) | [(a)] | (5)*** ; bound to the context of the block attached to 'c 5) obviously words with the same spelling in the same context reference the same value-slot ---------------------------------------------------------------------------- a: 1 bl: [a a] c: context [a: 5] append bl bind 'a in c 'a append bl bind 'a in c 'a bl -> [(a) (a) (a) (a)] \ / \ / \ / \ / (1) (5) global-context-table: word -- value-slot a -- (1) bl-- ..... c -- ..... c-context-table: word -- value-slot a -- (5) Maybe I was mainly so confused because the double pointer analogy is helpful only when one thinks of values as attached directly to words, then the indirection layer is needed, to make clear that it's just a place which is referenced. If one thinks like above then they are not necessary (as a desciption). I stumbles over another interesting binding issue and I guess it also proves the above description (and what you wrote). E.g. why 'bind is not able to in-place bind a single word like bl: [a b] c: context [a: 5] bind first bl in c 'a ; the 'a in 'bl would be supposed to be bound to the context This looks quite logical actually. The next would make less sense: a: 2 a: 1 c: context [a: 5] bind 'a in c 'a ; Which 'a to bind? But when one thinks about the code=data duality and thinks in value-slot terms, its logical that neither of the two examples above can work. The first would look like: (bl:) [(a) (b)] (c:) (context) [(a:) (5)] (bind) (first) (bl) (in) (c) ('a) the last line reduces for evaluation to (bind) (a) (in) (c) ('a) ;just for this example, there happens more of course So we got actually a word 'a in a value-slot and again there is no sense where 'a belongs to, it has no place. On the opposite with a block we would have: bl: [a] c: context [a: 5] bind bl in c 'a -> (bl:) [(a)] (c:) (context) [(a:) (5)] (bind) (bl) (in) (c) ('a) | [(a)] ; so we can change a word in a block, and only this word So this time we have a word to reference (indirectly) and due to the reference character of blocks it will stay referenced (if we have a reference of course). In the first case because the value-slots are always copied when a new value-slot is created due to some action, it wouldn't work, because we can't keep a reference to a single particular word (there are no "instances" of words - as I understood it in a previous post and now has been clarified). So thanks a lot for the patience. :-) Michael

 [42/45] from: mokkel::gmx::de at: 16-Apr-2005 2:30

Re: The truth about scope --- mistake correction


I made a mistake at point two, which has to be corrected: 2) words have a context, which is a mapping of words with different spelling to a value-slot of each word ------------------------------------------------ a: b: c: 1 d: next "hallo" e: head d context-table: word -- value-slot a -- (1) b -- (1) c -- (2) d -- (|**,2) ;**this particular pointer gets copied and the position changed by next | (h)-(a)-(l)-(l)-(o) \ \ e -- (|**,1) Of course every word has its own value-slot in the context. Only if references are involved then the value-slots of more objects can contain references to the same object. Michael

 [43/45] from: volker:nitsch::gmail at: 16-Apr-2005 3:42

Re: The truth about scope


Looks good. About bind bl in c 'a Actually the value has a place! Because 'bind has a return value ;) a: 1 c: context [a: 5] bind 'a in c 'a ; Which 'a to bind? probe bind 'a in c 'a probe get bind 'a in c 'a ; bind returns word, we can get its value probe bind 'a 'system ; finds the global 'a probe get bind 'a 'system gives a 5 a 1 Why that happens is in your explanation :) On 4/16/05, Michael Berg <[mokkel--gmx--de]> wrote:
[snipped, hope you have the original ;) ] -- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [44/45] from: mokkel:gmx at: 16-Apr-2005 11:37


Hi Volker,
> About > bind bl in c 'a > Actually the value has a place! > Because 'bind has a return value ;)
Yes I know, I just first wanted to complain (note) that it's kind of awkward that one can't bind a single word in-place (bind 'a in c 'a). The 'a after the 'bind won't be changed. In the case of the "picking it out of a block" this looks to me quite naturally as I (one) decided what word to rebind (if one want's to bind a whole block it will always bind all words, but what if there are some words which shouldn't be bound - might be a bit constructed case nevertheless). So I just though would be good to check it against the model, whether it makes actually sense to try to do so. And then the observation was that because value-slots are copied (shallow), there is no way to reference a certain word, the spelling simply get's copied and thus there is no way to pick (and designate) a word out of a block, which will be changed. We will only get another "instance" of the word and if we 'get it, it referes to the value-slot in its according context-table. So in case of single words, bind has to return another word as return-value, that in case of a block it is returned also, is just consistency I guess. :-) I also haven't been too exact about the representation of block references in-code/data. Actually it should have been looked always like: a: 5 bl: [a "hallo" 1] -> (bl:) (|,1) | (a)-(|,1)-(1) ; real value-slot list | | (5) | (h)-(a)-(l)-(l)-(o) ; this are actually no real (I guess) value-slots any-more I usually only wrote (bl:) [(a) (|,1) (1)] ....... Thanks for taking a look at it. Regards Michael

 [45/45] from: rotenca:telvia:it at: 17-Apr-2005 2:52


Ladislav Mecir wrote:
>This deserves one more comment I think. My POV is: >*Value sameness doesn't depend on implementation at all.*
<<quoted lines omitted: 9>>
>"coupling" the number with something, that is not a property of the >number at all - the place in the computer memory where the number "resides".
You already know that our POV are not exactly the same on this question. I do not want to start a flame, but i find it an interestering question, you know, and i can't resist to start my joke. DISCLAIMER: If you do not want to be confused about Rebol language, stop reading at this point or continue at your own risk. The problem of your "proof" is that it is true that "every mathematician .... knows, that there is only one number one (1)", but computers are not mathematicians . The number "1 is only one" only from a logical point of view, a point of view that, until AI will develop a little more, no computer can understand or can have also a raw idea of what it can mean. So i must conclude that "1 is equal to every other 1" only in an human head, not in the real world in which i find some computers which are able to run the program "rebol.exe". Well, what are you speaking of? My thesis: "Rebol number are not mathematical number" The proof: x: 1 / 2e305 ;== 5E-306 x = 0 ;== false y: x + 1 - 1 ;== 0.0 y = 0 ;== true As you can see this behaviour is against mathematical rules. So Rebol numbers are not the same as mathematical numbers. Said in other words, you are speaking as Rebol number would be THE REAL numbers, but this is not true; they are only machine states which with a little effort (and some round) we can use to model, in our head, real numbers. So when you speak of Rebol values, you should not think they are exactly abstract matematical values. And what you think it is true for matematical numbers it is not always true for Rebol numbers. You could answer that the different behaviour of Rebol number is only an implementation detail, but if this is true, it is also true that decimal! are the same of integer! (the difference is only an implementation detail) and that Java number, Visual Basic number, and C number are the same (the difference are only implementation details), so the is no real difference between this languages and Rebol about number.
>> Of course, Ladislav is right in saying that >>because you cannot discern them, they are the same. However, they
<<quoted lines omitted: 4>>
>This is the point showing an "implementation-dependent" look at identity. >...
Well if you think as this, you should also agree on these thesis: Two strings in Rebol can be the same or cannot be the same. x: "house" same: reduce [x x] not-same: reduce [copy x copy x] But in my head the word "house" is only one, so this behaviour is implementation-dependent. And also: Two words in Rebol can be the same or cannot be the same. x: 'house same: reduce [x x] not-same: reduce [first to-block mold x x] But in my head the word "house" is only one, so this beahviour is implementation-dependent. In the last example, because the main difference between the two not-same words is in binding, your POV should be that "Rebol binding is not a propriety of the Rebol language but only an implementation detail". Going this way you will agree also on this: Every propriety of the rebol language is an implementation detail. And my conclusion is: I you want to speak of sameness in the Rebol language, you can only speak of its implementation.
>(implementation-independent terminology): I had number 1 "stored" (I can >use a notion "referenced by" or "referred to" if I prefer) at two places >in the computer memory. I changed the first memory place (Not number 1, >nobody is actually able to change number 1!) to "contain" number 2 >instead. Now I have got number 1 "stored" at one place in the computer >memory and number 2 "stored" at another place in the memory. >
Computer are unable "to change number 1" only because they are unable to store them. Numbers are only in a man's head or in a Platonic world (for some matematicians, and between them, the great Kurt Godel), but nobody can believe they are stored in computers.
>-Ladislav >
End of joke. -- Ciao Romano Paolo Tenca

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted