low tech MI

[Kent Pitman <kmp@harlequin.com>]

   Date: Sat, 20 Apr 1996 04:34:18 -0400
   From: Alan Bawden <Alan@lcs.mit.edu>

      Date: Fri, 19 Apr 96 19:27:31 BST
      From: Jeff Dalton <jeff@aiai.ed.ac.uk>
   ...
      You probably didn't intend this as a proposal -- that a condition be
      respresented by a list of symbols -- but I think it's instructive to
      treat it as one.

   I thought it was clear that I wasn't making a proposal.

Here's a reason why I think it would be a bad proposal--perhaps a reason Alan
was secretly thinking when he had the good sense not to propose this...

With REAL multiple inheritance, I might write:

 (define invalid-credit-card-account-number
   (make-class 'inherits-from (list security-error)))

 (define invalid-credit-card-password
   (make-class 'inherits-from (list security-error)))
  
and then I might signal, for example invalid-credit-card-account-number.
It wouldn't matter that the definitions of these two is identical, what
would matter is the identity of the class was a unique object.

So if you handle invalid-credit-card-account-number, you don't accidentally
handle invalid-credit-card-password in the way you would if you did the 
low-tech thing Alan didn't (for good reason) propose:

 (define invalid-credit-card-account-number '(security-error))
 (define invalid-credit-card-password '(security-error))

The problem is that when you do

 (signal invalid-credit-card-account-number ...)

there is no longer any way to tell it from

 (signal invalid-credit-card-password ...)

Indeed, even if you did create a way, as in:

 (define invalid-credit-card-account-number (list 'security-error))
 (define invalid-credit-card-password (list 'security-error))

that would be, I think, too little to guarantee that  users would be able to
catch onto the tremendous importance you were placing on the object identity
of a cons cell...

Further, if you make the system so approachable that you can conjure new
combinations on the fly, as in:

 (signal-condition (append x y))

I think you will find numerous newbies thinking they are somehow achieving
the same as if they'd done

 (define xy (append x y))
 (signal-condition x y)

but they have not because the publishing of xy as an object that can be 
compared to would have a big effect on the availability of someone to 
distinguish any arbitrary list (A B C) from some specific list (A B C).
I think this would make teaching a mess.

The fact is that we all know the kinds of errors you run into when you
use lists as cheapshot approximations to new datatypes. We know that
opaque types are a qualitative improvement.  And I think it's not a
stretch to say we really do (or should) know that doing multiple
inheritance instead of single inheritance doesn't suddenly obviate the
need for opaque types--if anything, it strengthens it.

If we're going to have multiple inheritance, we should have it for
real.  Not some lame thing that pretends to be multiple inheritance but isn't.
That will just leave people with a bad taste for multiple inheritance.  Which
I'm sure some people wouldn't mind seeing.  But if they want to achieve that
end result, I think it's incumbent upon them to either make the case 
intellectually that multiple inheritance is the wrong thing, or to run an 
experiment trying it in a fair way.  Falling back on lists of symbols is a 
cute intellectual exercise for the purpose of demonstrating that there are a
range of options.  But it is not a solution to this problem.