opaque types for conditions

[Kent Pitman <kmp@harlequin.com>]

By "inspect data within" I neither meant to imply arbitrary ability to
pick apart objects without their accessors nor ability to preclude it.
I'm agnostic on that point.  I believe the INITIALIZATION protocol for
object creation needs to be standard so that you can mix objects of
different types in a standard way.  But you can EITHER do that by
encapsulation of the mixed parts and structured control of accessors
OR by a plist-based format that is entirely inspectable.  I don't much
care which of these is used.  My assumption is that the person who
will READ the data will understand the condition (or its parent).  But
the person who is constructing the data needs to be able to blend
paradigms usefully.  The absolute weakest case of "mixing" would be
(MAKE-COMPOUND-CONDITION 	
 (LIST (MAKE-FRED-STYLE-CONDITION ...fred-style-data...)
       (MAKE-GEORGE-STYLE-CONDITION ...george-style-data...))).  I say
this to emphasize that when I say "mix" I'm being abstract and not
meaning mix in a way like Flavors or CLOS (though I don't mean to
preclude that either).

When I said opaque, I meant only that it would be opaque to
non-condition-understanders.  Opacity is not supposed to preclude doing
condition-related things to the object, and so I DO want to do
for example, recognizing something as a condition or non-condition, and
condition reporting.  I don't want someone creating new condition types
that don't offer these services.

Probably the use of the word "opaque" is just a red herring here.
I used it only to mean "not a list whose car is a magic token" and 
"not a function which has to be called with just the right arguments".

I do think the language should have opaque types.

But for this purpose, if you want, "unique" is fine.