Error Proposal #5: difficulties and suggestions

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Thu, 8 May 86 18:15:48 -0100
    From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>

    ... The main reason for doing an implementation was that I'd never used a LispM
    and couldn't really understand how it was all supposed to fit together.  It
    was only after I'd written the code that I could see more or less how it was
    supposed to work. ...
   
I'm glad you've also taken the time to do an implementation, even if it involved
a previous proposal. I'm very concerned that people's feelings not all derive from
the 3600 unless we're going to define that the 3600 implementation is going to -be- 
the standard -- which would be silly.

My work with Macsyma and converting it to Common Lisp have caused me to realize
just how many places the Common Lisp spec is weak and how hard it is to write a
portable program. The problem isn't that Common Lisp isn't trying, but that often
things I think are specified are really not fully specified and not as easy to 
depend on as I might have guessed. 

My feeling is that the fuzziness of the spec often resulted from people taking 
things for granted -- not realizing there were important things they should write
down clearly. The result is that someone who has never talked to us and who just
sits down with the manual and writes an implementation based only on what we wrote
down may end up with a very different thing than we might expect. The only thing
truly portable programs can rely on are the things which are common between the
implementations we're familiar with and the implementations that were written
by strangers. That's often not as much as we might guess.

If we want to really make this error system usable in portable code, we may have 
to tighten up quite a lot of details or risk misinterpretation. The more people
find out about the LispM, the more they may take for granted, hence my concern 
that people try to understand the spec in the abstract or even try to do their 
own personal implementations -- not necessarily for production -- just as a 
learning exercise, as you have done.

I hope that if you or Daniels@Xerox or others have done some of the work to figure 
out what this error system is all about without `cheating' and looking at the 3600
implementation, that you'll provide us with some good feedback about questions,
concerns, etc.

I'm heartened to hear that proposal 5 seemed more specific than proposal 4. 
Hopefully with the comments we've gotten back from Daniels, it'll get more 
specific yet. 

Everyone should please keep those cards and letters coming.