Hooks for Common Objects

[Jim Kempf <kempf@hplabsc>]

(Please ignore if this posting is repeated, we're having some
 trouble with our mailer daemon)


At the December Common Lisp meeting in Boston, Alan Snyder
presented a list of proposed language changes which we
felt were needed in order to implement CommonObjects. For
the benefit of those who weren't at the meeting, here
is a quick summary of the changes (with notations for
changes which are also part of Guy Steele's list):

1) Change DEFSTRUCT in the following ways, to better support
   encapsulation:

  a) Specify that the underlying data structure for DEFSTRUCT's is
     a vector-like object to which user access is
     made difficult,

  b) Add a keyword argument specifying that no accessor
     functions be generated. Access to slots would then
     only be through the accessor functions for the underlying
     data structure,

  c) Require that the type predicate, if specified, be used
     by TYPEP,

  d) Allow DEFSTRUCT to take function names for functions to
     be used when two DEFSTRUCT's are compared using EQL, EQUAL,
     and EQUALP.

2) Change the type system in the following ways:

  a) Introduce a new predicate, TYPE-DEFINED-P, which takes a
     symbol and returns T if a type with that name is defined,

  b) Introduce a new function, UNDEFINE-TYPE, which takes a
     symbol and undefines the type, if it is defined. This is
     similar to Steele's proposal for undo functions,

  c) Introduce a new function, RENAME-TYPE, which takes two
     symbols, and renames the type known as the first to the
     second.

3) Introduction of a new special form, LET-PSEUDO, which allows
   the definition of lexical instance variables (might also be
   useful for Smalltalk and Flavors instance variable access).

4) Clarify the role of #, so that load-time execution of embedded forms
   is possible from compiled, as well as interpreted code.

5) Introduce the following optimization hooks:

   a) Allow the environment parameter to DEFMACRO to be queried for various
      information which would make optimization more portable. This is similar
      to Steele's proposal for PARSE-BODY, except DECLARE forms from the
      environment as well as the body would need to be returned,

   b) Allow a macro to be associated with a function name for compilation
      purposes. Most implementations will do this in a nonportably anyway,
      if only to allow arithmetic operations to be optimized,

   c) Add two functions, which facilitate the efficient definition of
      indirect function calls.

6) Introduce the following hooks for seperate compilation:

  a) Allow a macro to inquire on its &ENVIRONMENT parameter if the result
     will be used in a file compilation,

  b) Provide a hash table for each COMPILE-FILE where information associated
     with the compilation can be stored.

People who are interested in more details can ask for the document outlining
the hooks:

	A Common Objects Implementation Kernel, by Alan Snyder, Michael Creech,
	and James Kempf, STL-TM-85-14

Electronic addresses are SNYDER@HPLABS or KEMPF@HPLABS. Mail address is:

	Hewlett-Packard Labs
	1501 Page Mill Rd.
	Palo Alto, CA
	94304

The most critical of the above hooks is 6). Currently, COMPILE-FILE is not
defined to change its environment in any way which would allow one to
know that a file is being compiled. This has many (mostly unpleasent)
consequences for bootstrapping and type definition, and we currently 
use a nonportable technique which catches about 98% of the problems. 

We would be interested in other people's experiences with seperate 
compilation. How does one handle problems with compiling type/flavor/class
defintions which are part of the compiler, for example? Would the above
mentioned changes simplify things, or is there some way within the
current language standard that seperate compilation can be done
safely and portably?

	Jim Kempf	kempf@hplabs