Re: opaque type proposal

[Pavel.pa@Xerox.COM]

I think that I'm not very worried about your ``more mundane'' kind of problem,
viz. upward-compatibility when or if we get around to adding
multiple-inheritance.  Isn't this entirely orthogonal to inheritance?  For
example, what about when we get around to specifying a mechanism for
type-specific print operations, or any of a hundred other little options that we
might later decide to add?  I don't see how the addition of these to
MAKE-RECORD-TYPE's argument list is likely to be any more painless/beautiful.

I'm also not convinced any longer that the issue of ``how not to make mistakes
now that hurt us when we later add multiple-inheritance'' is terribly important.
The notion of opaque types and sub-typing are reasonably well understood
entirely independently of any casual resemblance to an object-oriented
programming facility.  If we're really so concerned that the facility we're
talking about now be extendable into an object-oriented programming facility,
then I submit that we should never decide on such an extension that cannot
handle this very simple and useful semantics.

In short, I'm having a hard time seeing the importance of this
upward-compatibility argument.  All I want is this simple, straightforward
semantics for a very useful facility; it's just not clear to me that the
decision has the great weightiness of future impact that you perceive.  Can you
explain your concern more fully?

	Pavel