Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote...

>Smalltalk usually early-binds all variable references, incl. globals. In the
>above solution (export globals via methods in Environment subclasses),
>implicit/inherited references are early-bound (at compile time), while
>qualified references are late-bound (at runtime).
>
>This results in a semantic ambiguity which I believe we need to avoid. I
>think qualified refs should simply also be early-bound.
>
>Thus, the compiler sends these messages at compile time, after e.g. simply
>looking for Capitalized unary message names, and then stores the resulting
>literal in the CompiledMethod, as with globals today. This preserves the
>current, unified semantics of always early-binding variable references.

Hi, Henrik -

Thanks for your careful read of the Environments scheme.

There is a reason why I left foreign references interpreted.  It wasn't for the lateness benefit (ie perhaps changing the binding (but see below)), but so that we could *invalidate* the binding by swapping a module out.  This is one of the things that makes the Environments scheme sort of unusual.

The idea (and this all actually ran at one time) is that you can swap an entire Environment out as an image segment.  Then, since foreign references are of the form
	Envt Thing
an attempt to refer to Thing will cause a message-send to the image segment root stub, giving Squeak a chance to swap in that segment and resume the message send.

If you do the binding early, then you have a literal pointing directly at the association for Thing, and the VM will crank its way into invalid pointers if the segment is out.  Actually, this won't happen.  Instead the segment creation machinery will fail to find a swappable region due to the literal pointers into it.  This can be hacked by making every dictionary entry a root for the segment, but you still have the problem that the VM will try to crank its way through invalid stuff on the literal reference.  This can be further hacked by making every internal referent a root, but I felt it was in conflict with some basic principle.  When I stepped back from all this I said "Ah, references to the internals of an environment can only be made by sending a message," and that's how it works.

By the way, it occurred to me that the late binding property *would* be nice for the following situation:  I have one package called Files, and another called NewFilesExperiment.  I should be able to just type (after saving ;-)
	Files := NewFilesExperiment
and suddenly everything in the system should be running with the new bindings.  I gather this is one of the things people like about packages.

I did think it was pretty cool to get both name spaces and packages in only a few pages of code, but a lot of the work of browser support, package dependence, etc., remains incomplete.

	- Dan
--