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:yah:oo 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:gm:ail 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:gmai:l 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:gma:il 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:gma:il 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