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

[REBOL] Re: Binding

From: brett:codeconscious at: 20-Nov-2002 23:45

Hi Robert,
> > expression: compose/deep [ rejoin [(instances-of-greeting)] ] > > I have question here: How does the evaluation sequence look like? Will > compose/deep (a) evaluate instance-of-greeting and replace the parens > with the result or (b) keep a live reference to the different greeting > so that I even could change the value?
I think (a). In my example, instance-of-greeting when evaluated results in a block.
> > ; But just because it looks like code doesn't mean we can't > > ; treat it as data. > > ;-) That's cool and I'm not used to it...
Oh good. ;^)
> > ; Or demonstrate how the words in a function body are bound > > ; to the function arguments. > > This sounds logical but it's really tricky I think. This means that > EXPRESSION is switching clothes.
Yes the wording is not good (I should have been in bed). I think Ladislav and Gabriele explain it better.
> I mean, if you think of the words as > pointers to some value, in C the pointers would stay the same. No matter > where you look at the pointes. In Rebol the pointers get new values > depending of the context ;-) you read them out. Pretty nice, but very > complex to understand and even more complex to keep track of.
With much respect, thinking "of the words as pointers" is your concept :^) Thinking in this way is making things complex to understand. When thinking this way it *seems* that pointers get new value depending on the context. But I believe REBOL does not have or need that idea. In C a variable brings to mind a a memory location where some bits are stored. I think there's even an operator or function that can get the actual memory address when given a variable. Compiled languages do that. In REBOL a word can be used to represent variable data but I think it is *not* helpful to imagine it as a memory location - it a symbol for something else. Joel published an interesting link to an article on "Leaky Abstractions". REBOL gives a nice strong abstraction, but we should not try too hard to drill holes in it! :^)
> > g: func [ greeting ] expression > > g "Yo" > > > > ; Which is like using BIND on the expression itself - lets > > bind it to ; the swedish context. > > > > new-expression: bind/copy expression in sweden 'self > > do new-expression > > For GREETING it's now clear what happens. But what happens for REJOIN? I > mean this word isn't in the swedish context. So Rebol key-words must > somehow be marked so that BIND knowns to skip these. Is it this way?
Yes - the spelling of the words identifies them :^) I think BIND parses the block. Each word it encouters it tries to find a match in the supplied "known" context. If it finds a word in the known context with the same spelling it will bind the word it is working on to the "known" context. Something like that :^) When you load the script (paste it into the console) all the words start in the global context (system/words). After the bind in the example has finished all the GREETING words are modified [or replaced - ask Ladislav :^) ] but REJOIN is left unchanged because it does not exist in the "known" context.
> > ; BIND changes the context of words in a block > > Ok, to the context you specify through the KNOWN-WORD argument. > > > so does FUNC to its body block. > > And here, to what context are those words bound?
I think Ladislav in another post said that the context is created when the function is evaluated.
> > CONTEXT (make object!) also changes the > > context of ; words in a block it is given. ; In this next > > example, treat the script block as data like we did ; before. > > > > currency-name: "Dollar" > > script: [ > > euro-zone: context [ > > currency-name: "Euro" > > print-currency: does [print currency-name] > > ] > > ] > > get script/context/does/2 > > == "Dollar" because executed in the "global" context. > > > ; Now see the change after the script block is evaluated. > > > > do script > > get script/context/does/2 > > Ok, and here the code is doing a name-lookup for "currency-name" and > finds this first definitio within the "euro-zone" context.
This line: get script/context/does/2 is not dependent on what the code is doing. So there is no name-lookup for currency-name . This bit: script/context/does/2 results in the word "currency-name" in the context symbolised by euro-zone. The GET then gets the value of this currency-name-in-the-euro-zone word. In my mind, the currency-name-in-the-euro-zone word *is a different word instance* to the currency-name-in-the-global-context word. But that is just my mind :^)
> Thanks a lot for all these very helpful examples. Robert
You are very welcome. Brett.