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

user interface macros: the environment issue



It might pay to read this message starting at the end, unless you don't
remember all the context.

    Date: Tue, 1 May 90 15:59 EDT
    From: Cyphers@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM

	 This document defines just enough of the compiler processing of the user
	 interface macros to allow portable metaobject classes to determine whether
	 instances are being created to represent definitions in the compile file
	 environment.  In such cases, the values of other keyword and initialization
	 arguments may differ from the specified values so portable code must test
	 for such cases to prevent encountering unexpected values.
     
	 Testing for these cases is possible because compiler processing of the
	 user-interface macros calls the functions {\bf ensure-class} and {\bf
	 ensure-generic-function} with a non-null value for the {\bf :environment}
	 keyword argument.  

    Defining NULL to be the predicate that tests whether an environment is the
    run-time environment is not very abstract.  This could run into serious
    problems with future extensions that unify this environment with the
    &environment argument to macros or that implement more than just the run-time
    and compilation environments.  On the one hand, NIL might not be the only
    representation for the "ordinary" environment, and on the other hand, there
    might be several distinct environments that all have the property of
    containing classes that can be instantiated and methods that can be executed.

I didn't include in this message my later message expanding on the previous
two sentences.  I hope they're clear now.

    I think we must choose either not to document any predicates on the
    environment, and require portable metaobject classes to operate some other
    way, or else to add one or more predicates that perform the specific tests on
    environments that are actually needed.  I was unable to figure out what
    specific predicates are needed, nor what the specific problem is that needs to
    be solved (alluded to in "testing for these cases" above).  As a strawman,
    I'll suggest (RUN-TIME-ENVIRONMENT-P env) => true if env is an environment
    that causes FIND-CLASS to return instantiable classes and causes
    ENSURE-GENERIC-FUNCTION to return callable generic functions.

    The term "run time environment" is from section 4.2 of the draft ANSI CL
    specification, revision 7.31 of 8/29/89.

    [from our example of how option parsing could be done:]
    The function COMPILE-FILE-ENVIRONMENT takes an environment as an argument
    and returns an object with indefinite extent which has the same
    COMPILE-FILEness properties as its argument.

That function probably has the wrong name.  The basic idea is that since Common
Lisp does not allow a macro to incorporate its &environment argument into the
expansion it returns, a macro that needs to do something like that (as DEFCLASS
does), has to pass the &environment argument through a function that makes it into
a sanitized argument with the same semnatics but indefinite extent.  This is only
needed as part of the protocol if users are making their own macros that resemble
DEFCLASS or DEFMETHOD -and- if those macros need to play eval-when games.  So I
wouldn't worry too much about this right now.

    Date: Wed, 2 May 90 16:13 PDT
    From: Gregor J. Kiczales <Gregor.PA@Xerox.COM>

	Defining NULL to be the predicate that tests whether an environment is the
	run-time environment is not very abstract.  This could run into serious
	problems with future extensions that unify this environment with the
	&environment argument to macros or that implement more than just the run-time
	and compilation environments.  On the one hand, NIL might not be the only
	representation for the "ordinary" environment, and on the other hand, there
	might be several distinct environments that all have the property of
	containing classes that can be instantiated and methods that can be executed.

    I agree with all of these comments.  What if we just added an argument
    :COMPILE-ENVIRONMENT-P or something.  It would be true or false.  In
    cases where it is true it would mean the some other information, passed
    in implementation-specific keyword arguments had the real compile
    environment.

    Date: Thu, 3 May 90 11:47:44 PDT
    From: David Gray <gray@lucid.com>

    No, there should be just one environment argument.  

I agree 100%.  I'd also like to add that any time you add more arguments
rather than making the extsing argument more expressive, you are not
adhering faithfully to the object-oriented religion.

							Perhaps there should be
    a function to test whether it is a compile-time environment (NULL is most
    certainly not that function), but I would want to see the need for that
    demonstrated first.  For the metaclass writer, the point is to be
    consistent about passing the received environment on to FIND-CLASS,
    MACROEXPAND, ENSURE-GENERIC-FUNCTION, etc.

    Date: Thu, 3 May 90 12:21 PDT
    From: Gregor J. Kiczales <Gregor.PA@Xerox.COM>

    My idea was that the predicate would be the extra argument.  User code
    would still be required to pass the argument on to the other functions
    (find-class etc.).  User code would pass the value of the :environment
    argument, no other values.  The other argument would just be a flag to
    user code that this was in the compile environment and things might be
    weird.

So "user code" would get information from one argument and "system code"
would get the same information from a different argument?  Since I don't
believe there is any real difference between "user code" and "system code",
and since specific pieces of code often migrate from one category to the
other (in both directions, in fact), I don't think this will fly.

    Date: Thu, 3 May 90 13:21:20 PDT
    From: David Gray <gray@lucid.com>

    That still seems like an undesirable and unnecessary complication; I'd
    rather have a predicate function than a redundant argument.

    Date: Fri, 4 May 90 17:59 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    There is the additional issue of whether such a predicate is needed
    at all.  Moon and Cyphers said:

      I was unable to figure out what specific predicates are needed, nor
      what the specific problem is that needs to be solved (alluded to in
      "testing for these cases" above).

    Gray said:

      I would want to see the need for that demonstrated first.

    So I think we agree that we're not yet convinced such a predicate is
    needed.  Gregor hasn't addressed this issue yet.

Let's start by addressing the question of whether any predicates on
environments are needed at all, and if so, what exactly those predicates
are testing for.  My strawman proposal is that the metaobject protocol
documents no operations on environments other than the ones that are
already in 88-002R (such as the environment argument to FIND-CLASS) and
obvious extensions of the same thing.  Thus no run-time versus
compile-time predicate at all.  Let's look at where this breaks down,
if at all, to see whether there is a need for anything else.  I know
it will break down for users writing their own macros that do what
DEFCLASS does.  I haven't yet been shown a case where it will break down
for users writing methods that get called by the expansion of any of the
defining macros.