Re: Miscellaneous decisions taken or to be taken

[kempf%hplabsz@hplabs.HP.COM]

>      >   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?

This is a problem. Also with unnamed generic function objects, and
methods. In the interest of simplicity, I'd be willing to forgo this.
I can't think of why anyone would want to name a class NIL anyway.

> 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.
>      

We need some more discussion on this first. I agree that the the compile
environment problem needs solution (especially for single address space
implementations) but I'd rather see some concensus on a general solution
before bringing up specific functions. Even if it means having to revise
the parameter lists of some functions.

>      
>      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.

Does this mean that a decision was made at the July meeting on the point 
Pavel Curtis raised at the March meeting about what relationship CLOS 
should have with the full language standard? Unless implementors of
Common Lisp are required to implement CLOS in order to have "full
ANSI Standard Common Lisp", I think it would be better to allow some
flexibility in where the symbols go.

>      > 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.

I agree with your preferences here. The error message should also give some
information about the classes of the parameters, in addition, to help 
debugging.