Environments, Naming, and CLOS (was Re: Name that Class)

[kempf%hplabsz@hplabs.HP.COM]

>      2) Inheritance lists would be no problem, since supers must be of
>      the same metaclass anyway.
> That's not true, supers can be of other compatible metaclasses.

	I stand corrected. In the event of a name clash, some means
	of disambiguating the name to class mapping would be needed.
	One possiblility would be to extend the definition of "compatible" 
	to include "not having classes with the same name". Provided,
	of course, that multiply named classes were seen to be such
	an important feature that they should be included (which I
	doubt).
>      
>      
>      But, as Patrick has pointed out, the issue is more complex. The name
>      to class (or name to generic function) binding has an additional component,
>      namely the environment. What I think we *really* want is a way to have
>      the name to object binding be dependent on the environment as well.

> This is an entirely different issue from what you've been talking about.
> Environments and metaclasses are orthogonal.

	To the extent that the metaclass protocol takes into account 
	the processing environment, it may be possible for a particular
	metaclass to do things differently in an environment from
	others. For example, a metaclass supporting a language which
	always resolves inheritance at compile time would need to
	deal with the environment in a different way from the default
	metaclass, where inheritance is resolved much later. 

>      I'll leave it at that for this note. Summarizing, my feeling is that
>      allowing a multiple name per class object binding has some serious problems
>      for user level code, since the names of class objects are and
>      probably should be settable. I don't feel offering the functionality
>      to users is particularly important at this time, but if people want
>      it, then I think restricting the name to object mapping to be one to
>      one on a metaclass by metaclass basis is probably the right way to go.

> I don't see what can be gained by having one namespace per metaclass.  I thin> k> 
> it compromises modularity.  When you list your supers in DEFCLASS, you
> don't/shouldn't have to care what metaclass they belong to as long as they are
> compatible with your metaclass.

	I agree. I can't see much use for allowing multiple names for
	classes in the first place, since it requires more syntatic
	machinery on the part of the programmer to indicate precisely
	which class is meant in user level code. The point of the
	metaclass proposal was that, if anywhere, that might be a
	place where people might want to have multiple classes with
	the same name. Suppose, for example, you want to have a 
	WINDOW class in CLOS and one in Smalltalk (or CommonObjects,
	or Flavors, etc.). But Common Lisp provides packages for 
	seperating namespaces, and I think that's probably enough, as
	long as you don't insist on exporting more than one WINDOW.
	So you could have a FLAVORS::WINDOW and a SMALLTALK::WINDOW.
	
	Personally, I think that this issue (multiple names for classes)
	is a bit of a red herring. I just presented the metclass proposal 
	as an example of how it might make sense, but, as was pointed
	out, additional machinery would be required at the syntatic
	level to support it. The package system, despite its faults,
	is the customary way of modularizing namespaces in Common Lisp,
	and I think we should stick with that for user level code.

	The issue of multiple names in different processing environments
	is somewhat different. Because the package system is read time
	only, and symbols map across compilation and loading into the
	same package, the package system cannot be used to allow a
	class of the same name to co-exist at compile time. Similarly
	for methods. In order for a class or a set of classes and
	their applicable methods to be compilable in the same file,
	the CLOS metaclass protocol must insert enough information
	into the compile time environment so that the methods can
	be defined. At the extreme, the classes being compiled 
	could be simply be completely defined at compile time, but 
	this will, of course trash any existing definitions. This is 
        not a problem for implementations which an easily get new 
	virtual address spaces (modulo lengthening the time required 
	for compilation of a system), since most bootstrapping problems 
	could be solved by simply throwing away the environment and
	getting a new one (there are probably some more subtle problems
	here which I'm missing).

	Is that a fair statement of the problem with environments
	and naming?

	As mentioned in previous notes, I think a section in Part I
	about what CLOS needs in terms of processing environment
	is important. I might add that the ANSI C standard has
	about 8 pages of material on the processing environment at
	the beginning. We are, of course, limited by what CLtL provides,
	but I think, within that limit, we can probably be more
	precise.