1. Re: Globals
- Posted by gertie at visionsix.com
May 22, 2003
On 22 May 2003, at 9:52, Mike Nelson wrote:
>
>
> To clarify my earlier suggestion:
>
> I don't know exactly how Rob implements this in the interpreter, but
> conceptually, the interpreter maintains a global symbol table for the
> program, a local symbol table for each file, and a private symbol table for
> each
> routine. When a symbol is referenced, it is searched for in the current
> private
> symbol table (if any), then the current local symbol table, then the global
> symbol table. If the reference is not found in any of these, it is undefined.
>
> If it is found two or more times in the global table it is ambigous and a
> namespace qualifier is needed. (I assume a global defined in the current file
> itself is also in the local symbol table or is qualified in some way to
> indicate
> it was defined in the current file--the interpreter does not report an
> ambiguity
> when one of the definitions in in the current file.)
>
> My proposal would have a global symbol table for each file. At the top of
> the file, the global symbol table would be empty. Each global defined in the
> file would be added to the global symbol table for its file. When an include
> is
> encountered, its entire global symbol table would be added to the global
> symbol
> table of the current file. Each entry will specify the file where the global
> was defined. If the include is the first time that file has been included, it
> is parsed at this time, if it has already been included, its global symbol
> table
> is copied with no parsing reuqired.
>
> This would solve Derek's "Erroll problem": Chris' tokenize() does not appear
> in
> Bob's global symbol table, and Alice's tokenize() does not appear in Diane's
> global symbol table. Both will appear in Erroll's global symbol table, so he
> will have to resolve the abiguity if he uses tokenize() in his own code
Same as with a "include local", instead of the default plain "include". As
"local" would not be a valid filename, it would be obvious to the interpreter to
manage it differently. I'd prefer to have "global include" and "local include"
on
a per-file basis, but that would mean two new phrases (old words, new
arrangement), which would be asking for too much. It would be in keeping
with "global function" format though.
> --but
> namespacing handles this just fine, though he will need to use include Alice.e
> as alice or include Chris.e as chris, as the case may be.
So would "local include".
> If later Diane rewrites her library to also use Alice's lib, she will have
> to disambiguate tokenize(), but there is no effect on Erroll.
Not with "include local", given RDS's propensity to let us get around things.
Diane would write a new include with pseudo-namespace:
-- begin code
include local Alice.e
global function myAlicefunct(object x)
return Alicefunct(x)
end function
global procedure myAliceproc(object x)
return Aliceproc(x)
end function
-- end code
Write a similar include to establish namespace and scope for Beth's or
Chris's code. This would deny visability to all the other globals in Alice's
code, like Derek's hide(), and provide namespacing and scope restriction.
Errol would not need to do anything different to include all the previous libs,
because te code would not see the original included files.
Kat
