[110] in Coldmud discussion meeting

Re: Proposed change regarding MI ambiguities

daemon@ATHENA.MIT.EDU (Fri Dec 10 21:05:53 1993 )

To: Andrew Wilson <Andrew.Wilson@cm.cf.ac.uk>
Cc: coldstuff@MIT.EDU
In-Reply-To: Your message of Sat, 11 Dec 93 01:23:29 +0000.
             <9312110123.AA19035@ruby.cm.cf.ac.uk> 
Date: Fri, 10 Dec 93 20:59:27 EST
From: Greg Hudson <ghudson@MIT.EDU>


> Absolutely not.  It is evident that the ambiguities, if any, can be
> detected when the method is defined.  Such ambiguities are, after
> all, merely syntactic.  There really is no reason at all for not
> creating a @lint, or equivalent mechanism for flagging any
> ambiguities and for refusing to construct an ambiguous lattice.
> Force the semantics to be unambiguous and you are saved the horror
> of run-time lattice verification.  I'd suggest that you read up on
> the implementation of the Eiffel programming language NOW rather
> than later.  Do it right, or don't bother.

Two disagreements:

(1) I disagree that run-time lattice verification is a "nightmare".
As I said, I'm pretty sure I can do it in linear time, which is how
long a method search is going to take in the general case anyway.
There won't be a performance penalty relative to the current system.

If there's some other reason why this isn't "doing it right," then I'd
like to hear it.  Please leave the implementation details up to me,
though.

(2) You're not thinking in terms of a mud language.  I can't restrict
programmers from defining methods on their objects because other
programmers have defined methods on their objects.  Consider the
following hierarchy:

	A

      B   C

	D

Suppose I own B and you own C.  Someone else owns D.  You define a
method 'foo' on C.  Now I can't define a method 'foo' on B, I can't
undefine your method on C because I don't own C, and I can't remove
B as an ancestor of D because I don't own D.  But D's owner is the one
who should have to deal with the problem, since it's D that's (after I
define the 'foo' method) inheriting from incompatible parents.

Also, with a disk-based db, having to check non-local conditions while
making a local change carries severe performance penalties.

--GBH
Remember, MUDs are a harder problem than real programming languages.