Re: Enhancements to the include system
On Sun, 17 Dec 2006 13:47:50 -0800, Chris Bensler
<guest at RapidEuphoria.com> wrote:
This message just bounced on me ;-( , so I'll re-try.
(My apologies if you already got this/see it twice)
>I think automatic inclusion is a bad idea.
I think I asked for that particular slap in the face 
>it should never make assumptions.
It is NOT an assumption, it is part of the language definition.
Technically, there is no functional difference between say open()
invoking some machine code in the back-end or auto-including pfileio.e
Personally, it drives me nuts that open is pre-defined but seek is
not, ditto current_dir and chdir, get_key and wait_key, rand and
set_rand, print and sprint...
I guess if 99% of your programs start with eg include win32lib.ew,
then you don't notice this much.
Anyway, I'm quite happy that the gotcha I mentioned is a feature of
*overriding builtins* and is only of concern if such introduces an
*incompatibility*. Onto matters real:
<snip>
>forces the programmer to have to expose certain declarations that are
>only intended for cross-file use among the API they are developing.
OK, I see.
Now you mention it I tend to cross fingers and hope on that one.
>
>Second, a way to isolate how far a global declaration should extend
>*by the developer who declared it*, would add a great deal of control.
>This has to do with my idea for chained includes, or global chaining,
>in other words. It's too much to explain here.
Aha!
I know it is complicated but that is more, not less reason to discuss.
>
>Third, the ability to gain access to 3rd party declarations that were
>never intended to be global would create an additional way
>that declarations could be internally shared among files of an API
>without exposing them globally or forcing a programmer to modify
>foreign code. This is more for creating flexibility while preserving
>code and is perhaps more of an enhancement than anything to do with
>reducing global contamination, but I think it's related. Again, I'm
>not going to get into my idea for implementation at the moment. The
>purpose of this post is to point out the issues that need to be
>recognized. I'd like to encourage ideas and proper resolution, not
>enforce my own.
>
Umm, even more interesting...
The way I see it is you want to "ringfence" stuff.
You want globals to work normally within this fence.
You want to limit "what gets out"; other globals remain within.
You *may* want "qualified" access back inside.
How does this strike you:
global scope gsname
...
end scope [gsname] [export g1,g2,g3...]
Within the scope, globals behave normally, after the end scope,
globals specified in the list can be accessed unqualified, those not
in the list can be accessed as gsname:<id> and as you may expect,
non-globals within such a construct cannot be accessed externally,
period.
External view of nested gscopes depends *entirely* on the last export
statement. Nested gscopes cannot "hop over" their container.
<pause here; suggestion complete, what follows is technical>
Putting the export list on the end scope may make life simpler for the
compiler, though I guess it would not be that difficult to save
line/col start/end if the consensus is it looks better on the start.
I believe you could implement such a [nested] scheme quite
efficiently, the cost being that if the symtab lookup runs into an
unqualified global with scope no > 1, then it has to check if that
scope is still open [else skip it the same as a hash collision].
All the export statement has to do is set the scope no to that of the
including parent. The gsname entry in the symtab would be a little
like an existing namespace entry, except global, and ... erm the
rest is probably a bit trial and error
[symtab needs a new uniq "scope no" field for globals, obvs]
Behaviour of still open gscopes is *undefined*, at least for now.
(ie/eg global scope x ... x:yyy() ... end scope x... the "x:" has no
real meaning within, far as my logic yet goes, and I think correct to
avoid seriously mental games within nested scopes.)
LIkewise, the above remains *theory*, or at least vapourware..
You could of course allow global scope noname to avoid unnecessarily
polluting the global namespace with global scope names
Regards,
Pete
|
Not Categorized, Please Help
|
|
