[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some questions

	Date: Tue, 10 Jun 86 11:45 EDT
	From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

	    Date: 29 May 86 21:21 PDT
	    From: miller.pa@Xerox.COM

	    How happy are you with packages?
	    In particular, for those familiar T's reified lexical environments
	    LOCALEs), can you think of any reason for preferring packages?
	    Can T's LOCALEs be added to the language in an upwards compatible

	I'd like to point out, again, that packages get you thinks that locales
	don't (if I understand locales properly -- someone correct me if I'm
	wrong).  Packages provide name scoping for symbols themselves, not for
	values.  Therefore, if symbolics are being used for virtue of their
	identity rather than their value, packages provide name scoping and
	locales do not.  For example, suppose one subsystem uses the A:FOO
	property of symbols, and another subsystem uses the B:FOO property.

	I actually think your example emphasizes my point.  Traditional (old)
lisps had a very simple mapping from print-names to symbols (one to
one), and awkward control over the mapping from symbols to values
(dynamic scoping).  As we started to compose ever larger programs, it
became obvious that we needed better control and flexibility somewhere
in here.  To achieve more flexibility mapping print-names to symbols, we
invented packages.  To achieve flexibility and control mapping symbols
to values, we invented lexical closures, reified lexical environments
(locales), separate name spaces (function / "value" / type / property /
etc..), and object oriented programming.  

	Your example shows a need for scoping in property value space.  You are
simulating this in a global property value space by using the "name
scoping" of packages.  The reason I find this unsatisfying is that this
scoping happens at read time, and the reader is not part of the
computational model of the language.  In the computational model of the
language you are still stuck with a global property space.

	Is there a need for flexibility in the mapping from print-names to
symbols other than to simulate (poorly) flexibility in mapping symbols
to values?  You are correct that packages buy you scoping of symbols
themeselves.  My question is: what's this used for other than scoping

BTW.  The original T did have a single global property space, but I
believe that the new T (T3) has fixed that.  Perhaps one of the T folk
would care to comment (I'm on shaky ground here)