Re: nested class definitions

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: 3 Sep 86 14:03 PDT
    From: Masinter.pa@Xerox.COM

    Common Lisp has taken the view that while there are local functions with
    FLET/LABELS and local macros with MACROLET, there aren't any local
    structures. Lets suppose we had something like structure-let ...
    This certainly makes sense for (:type list) because it doesn't entail
    any global data-type-space manipulation, but makes less sense for
    structures & classes? In a recursive call, are the types the same
    because they share names? Or different? ...
    you clearly have a dynamic scope the class and its methods. However,
    most languages that have "local types" use a lexical scope instead. How
    can we get lexically scoped classes?

Part of the issue is that you need to clearly define whether the data
which is locally typed wants to be first-class. That is, does it have
indefinite extent?  If so, then what does it mean for its type to have
been local? Does it mean that there are now no valid operations upon it,
or just that there is some kind of state which various objects might
still be carrying around which allows them to speak to the object even
though no one else can. That is, is its type marker invalidated upon
exit from the valid contour/context, or is the accessibility of the type
in the type lookup table just drastically reduced by exit from the
contour/context in question?

I should note for the record that this issue seems to me to be just like
the question people keep asking about why we have local 
(DECLARE (SPECIAL ...)) and don't insist that things be proclaimed
SPECIAL for all time? I'm not sure I have a good answer to that question
either -- seems me to be mostly a convenience issue.

The impact these convenience things (FLET, LABELS, local SPECIAL
declarations, and now local types) on debugging are potentially severe
and I think they need to be studied carefully so I recommend we go
slowly.  For example, if you declare local types to be invalidated upon
return, you're surely going to accidentally return locally-typed objects
during debugging and they'd have to be pretty well-behaved if you were
going to have a debuggable system. PRINT/READ invertibility is obviously
blown away by such a thing. Also, if the language were defined such that
the compiler were allowed to treat certain types totally lexically, then
you'd potentially get something which had its type compiled away --
which has some potential good effects (speed and space efficiency being
key among them) but you'd risk duplicating the Fortran debuggability
problem where you could lose track of the type of an object or where you
could end up cheating on accesses to typed objects in ways that you
really didn't mean to -- or worse, in ways that you did mean to...