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

Re: low tech MI

>    From: Kent Pitman <kmp@harlequin.com>
>    Date: Sat, 20 Apr 96 18:17:54 EDT
>       Date: Sat, 20 Apr 1996 04:34:18 -0400
>       From: Alan Bawden <Alan@lcs.mit.edu>
>       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...
> You guys have -almost- made me sorry I mentioned it in the first place.
> Everybody please stop trying to read so much into my mention of the Emacs
> Lisp condition system. 

I was treating it as a possible way to represent conditions, along
the way to make a more general point, namely that the rrrs authors
would not be able to agree on how to represent conditions.

I happen think lists of values that represent condition "types"
(values which don't have to be symbols) is a reasonably good idea.
But I suspect it will be too controversial.

In any case, I think you are not quite right about fear of MI.

> Let me try and restate my point without reference
> to Emacs Lisp:
> Many people are frightened by the mention of MI.  I would guess that this
> fright stems from the fact that in the world of object-oriented
> programming, MI remains controversial.  MI is controversial there chiefly
> because it introduces a lot of complexity (both semantic and
> implementational) into method lookup.

I'm not sure method lookup is the greatest problem.  A number of MI
schemes have general MI method lookup but do something special, with
restrictions, for slots.  Java is one example, the lack of full object
identity is C++ is (indirectly) another.  It's also the reason MI
isn't build into EuLisp and why the EuLisp group spent time on "mixin
inheritance" (see the MCS entry in the Comp.lang.lisp FAQ).

> But I don't think I've seen any proposals that we do method lookup on our
> conditions.  Mostly we want "MI" (or whatever you want to call it), simply
> because we want a partial order on conditions.  My point was that if all
> you want is a partial order, there are -lots- of ways to get one.  The
> subset relation on sets is a particularly simple way.

Just so.


But that needn't stop it from being treated as one...

-- jd