Re: Miscellaneous decisions taken or to be taken

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

     >   We need to decide whether class-name of an anonymous class is nil.
     
     Two choices are 1) NIL 2) CLASS-NAME signals an error. I vote for the
     second. An anonymous class should be a class with NO name. 

If we signal an error on class-name, then we have to come up with a
predicate to test if the class is named or not. Is it worth the trouble?

     Additionally, it would be nice if
     top level forms would also print out something at compile time. Our
     applications developers are asking for some feedback about what gets
     done at compile time. Maybe that's an implementation issue, though.

You're right, it is an implementation issue, some compilers have a
verbose option.
     

     > 2-13 class-named needs a new name for consistency.  get-class would be wrong
     > because the other get-xxx functions aren't name operations.  symbol-class
     > is the agreed name.  It needs an environment argument.  The errorp argument
     > gets in the way.  I think we agree that symbol-class should be setf'able,
     > but can it only be set once for a given symbol or is it allowed to change
     > the symbol-to-class-object mapping?
     
     Why an environment argument? Since we haven't agreed to lexically scoped
     class names, this would seem unnecessary. Is it to deal with the ERRORP
     argument? Why do people think it will get in the way? Why not just make
     it a keyword argument? A user might want to not have it signal an error
     especially in metaclass programming. If whether or not it signals an
     error is dependent on a (second-class) environment argument, then it
     will be more difficult for a user to arrange. I think the name SYMBOL-CLASS 
     is OK, and that it should be allowed to change the 
     symbol-to-class-object mapping.
     The important thing in CLOS is the object, and the name to object mapping
     should be changable.

The environment argument will be necessary to address the compile
environment problem.  The term might be confusing, it is not necessary
an environment like the &environment argument in a macro definition.
     
     
     > What can be done with method objects, e.g. can one method be added
     > to more than one generic function?
     
     There may be a problem if the method invokes CALL-NEXT-METHOD. This
     relates back to whether CALL-NEXT-METHOD is dynamic  or indefinite
     in extent. If it is dynamic, then there should be no problem, since
     the binding of CALL-NEXT-METHOD is done when the method begins executing,
     at the latest, or during calculation of the effective method, at the
     earliest. Thus the same method object on multiple generic functions
     would be no problem, since that case could be detected and establishment
     of CALL-NEXT-METHOD's binding deferred as late as possible. If the
     extent is indefinite, then the binding could potentially remain outside
     of a particular method invocation, and so adding the same method to
     more than one generic function may cause a problem.
     
     > Which symbols defined by the standard go in what package?
     
     >   July: I think we said some will go in LISP: and some will go in CLOS: and
     >   we don't know yet where to draw the line.
     
     I think they should all go into CLOS, except those which are already in
     LISP (like DOCUMENTATION) or those which are designed to replace aspects
     of LISP already existing (like PRINT-OBJECT). Very few are in these categories.
     
We said that some of the symbols will go to LISP because CLOS is
supposed to be part of ANSI Common Lisp. The top level macros and
functions should be part of LISP.  The internal functions specified for
the sake of metaclass programming can reside in CLOS.

     >   Gregor doesn't like the ability to specify constraints on the ordering
     >   of classes that only apply conditionally, i.e. if those classes are
     >   actually present among the superclasses.  He considers this bad style.
     >   Moon volunteered to write a proposal with some examples, and we agreed
     >   to resolve this over the mail.
     
     I agree with Gregor. I think that user specified changes in the CPL
     should be controlled through COMPUTE-CLASS-PRECEDENCE-LIST, or, if
     the default algorithm can't make a decision. 

Let's see what Moon's proposal before discussing the issue.
     
     > I'm not sure if we said anywhere what happens when you call a generic
     > function and there is no applicable method; I think it ought to signal
     > an error.
     
     Yes, and CALL-NEXT-METHOD should do the same. Again, we need to clarify
     in the context of Dick's proposed error naming scheme.

If we can assume that the ANSI will standardize an error handler then I
am in favor of signalling an error and specifying the signal name.  If
we can't assume that, I would rather call a generic function like
NO-MATCHING-METHOD.