[EMAIL PROTECTED] wrote:
>
> On 12/27/1999 at 4:08 PM [EMAIL PROTECTED] wrote:
>
> {{In the standard implementation model, Pascal local variables are
> allocated on the stack upon entry to a procedure, and deallocated
> upon exit from the procedure. There's no way to make a local
> var from one procedure refer to the content of a local var from a
> different procedure (except via pointers, and then one gets into
> the danger of the "dangling reference" problem).
>
> OTOH, by using 'bind it IS possible to make the word/value
> association that exists within one context available to another.
> That's a very large difference, IMHO.}}
>
> Well, allocating locals on the stack is certainly one way to do it,
> but the language itself only requires the behavior.
The _Pascal_User_Manual_and_Report_ was fairly sparse on detail about
local variables, except to say that they were distinct from any other
variables from the enclosing scope with the same name. By the phrase
"standard implementation model", I was just referring to the
explanation I've most commonly seen given for how one could achieve
that effect. I didn't mean to imply that there weren't other ways
it could be done.
> And most
> implementations, I think, clearly defined whether a local variable was
> initialized or not. In the Borland implementation, the answer was not,
> since they included a keyword ABSOLUTE which let you define two
> variables names at the same memory location.
Actually, the _P_U_M_&_R_ specifically states (page 156):
In the case of local variables, their values are undefined at
the beginning of the statement part.
Borland allowed one to declare a variable to reside at a specific
memory address (so that one could write TurboPascal code that played
tricks on PC hardware by manipulating data at locations in memory
that had special significance to the O/S, BIOS, or hardware), but
that was not standard Pascal.
> Meanwhile, I also believe
> C has a static keyword that preserves local variables between
> function calls, which implies those locals at least are stored
> outside the stack. "Nothing new under the sun."
>
And, as c is a different language from both Pascal and REBOL, it's
not surprise that it has its own ideas about the scope and lifetime
of variables.
>
> But, back on thread, since words can be bound as functions as well
> as variables, I imagine the implementation model is probably a tree
> structure, such as is used to scope nested subroutines. Unlike many
> other languages, REBOL needs to store "variables" and "functions" in
> the same space, since a word can be one and then the other, and all
> words can be evaluated, whether they store a scalar or a script.
>
I guess I'd go even further and say that REBOL doesn't even make the
distinction. You can treat a value as "data" or treat it as "code".
REBOL will let you try anything, and will only complain if your
request is too indigestible.
>> a: {print "Hello, world!"}
== {print "Hello, world!"}
>> length? a
== 21
>> do a
Hello, world!
>> b: [print "Hello, world!"]
== [print "Hello, world!"]
>> length? b
== 2
>> do b
Hello, world!
>> c: [ {prin "Hello, "} [print "world!"]]
== [{prin "Hello, "} [print "world!"]]
>> foreach d c [do d]
Hello, world!
>
> I can't just put a Pascal variable on a line by itself and expect
> the compiler to do something with it!
>
But you CAN put a Pascal identifier on a line by itself. If the
identifier is the name of a procedure, the compiler will generate
code to invoke the procedure.
>
> I also wonder if some of the behavior we see in local variables
> retaining values across function calls is by design or happenstance.
> The documentation doesn't seem to specify whether local variables are
> initialized. At the first evaluation, they seem to start out as none,
> but then ...dunno.
>
We can add that to the list of things that would be nice to have
official documentation for.
>
> Incidentally,. I'm really enjoying your posts, Joel.
>
Thanks! I've enjoyed, and benefitted from, most of the conversations
I've had on this list. I'm just trying to swap ideas with fellow
travellers as a way of getting us all further down the road.
-jn-
