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

[REBOL] Re: The truth about scope

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 > > 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.
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] [ > 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.
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 > 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).
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 > (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 > -- > To unsubscribe from the list, just send an email to > lists at 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