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

[no subject]

Thanks for all the answers.  It looks good so far.  I look forward to
seeing your extended descriptions of the meta-class machinery, MLET and
MLABELS, some examples of annotated values, and some additional examples
of method slots.

One thing that I didn't notice before was that the type-restrictions on
the arguments of a discriminating function would indeed serve as a type
declaration for that argument variable.  (This should be made explicit,
so that it is clear that the argument variable cannot alter be set to
something of the wrong type.)  As you say, given this declaration it
should be relatively straightforward to open-code many slot references,
but I am still a bit worried about being able to do this in more complex
situations.  When the details of this are worked out, we will all see
whether the efficiency is sufficient in the important cases, I guess.

I agree that the safe thing to do for now is to forbid specialization of
any of the built-in functions in code that is meant to be portable.
Everything in Common Lisp is potentially compiled inline at present, and
there are many cases in which the simpler cases of complex functions
like Format are source-transformed into something that does not go
through the original function's value cell.  I suppose we could allow a
built-in function to be specialized with the understanding that the
change is not retroactive, but only applies to user-level code compiled
after the specialization is created.

Both Dave Touretzky and Rob Maclachlan have independently raised
questions about the assumption (which CommonLoops shares with flavors)
that if a class adds a slot (access function) named "FOO" when it
already has a "FOO" by inheritance, then these are necessarily the same
slot.  There are a lot of situations where this is treacherous.
Touretzky has written up a critque/proposal on this, and I will
encourage him to send it in to this mailing list.

-- Scott