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

Re: remote environments

Thanks for putting together a list of all the questions involved.  I
can't claim to be an expert on the subject, but perhaps my answers
would be useful as a representation of the expectations of a naive
user with few preconceived notions.

>   * Can the class be used as a superclass of a later DEFCLASS?  [clearly yes]
>   * Can it be used as a specializer in a DEFMETHOD?  [clearly yes]

So far, so good.

>   * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."?

Probably not.  We allow other kinds of definitions seen by the
compiler (macros, for example), to be hidden somewhere where they are
not visible in these circumstances.  If you really want the class to
be fully defined at compile time, you should wrap the definition in an

>   * Can the class be used as the :METACLASS option of a later DEFCLASS?
>      - Can that second class be instantiated?

I'm not sure on this one.  I'm inclined to think that users would put
the metaclass definition and all its methods off in a separate file
anyway, so I don't see any compelling reason to -require- that a class
be usable as a metaclass in the same file it is defined in.

>   * Can it be used as the :GENERIC-FUNCTION-CLASS option of a
>   * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.?
>      - Can DEFMETHODs then be done for that generic function?

I don't know enough about the issues involved here.

>   * Referenced by later DEFMETHOD? [clearly yes]


>   * Is the function defined such that it can be called at compile time?

I'd have to say no.  DEFGENERIC is analagous to DEFUN, and DEFUN only makes
the function definition available at load time.

>   * Can it be invoked at compile-time?
>   * In particular, will methods added to standard generic functions be
>     invoked by the system at compile time?

No to both questions.  

>   * Used in a later DEFGENERIC?
>      - Callable at compile-time?

I'm not quite sure what all the issues involved are here.  I think
that I would expect a method combination to be usable later on in the
file.  To me they seem kind of similar to SETF methods (but maybe
that's just a random coincidence). 

> Are there other interactions that need to be considered?

Yes.  How about specifying when checks for lambda-list congruence are
made for DEFMETHOD?  In particular, suppose I have a generic function
FOO fully defined in the compilation environment, but a file I'm
compiling has a method for FOO with a lambda list that is not
congruent.  (Maybe I just fixed the file and I want to recompile and
reload it.)  I think it is reasonable for the compiler to issue a
warning but I don't think this is an error or that an error should be
signalled -- that should happen only at run time.  This would be in
keeping with the general philosophy of allowing functions to be freely