[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
- To: Masinter.pa@Xerox.COM
- Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
- From: Dan L. Pierson <pierson@multimax.ARPA>
- Date: Wed, 09 Dec 87 12:58:41 EST
- Cc: cl-cleanup@sail.stanford.edu
- In-reply-to: Your message of 08 Dec 87 15:22:00 -0800. <871208-160538-5539@Xerox>
From: Masinter.pa@Xerox.COM
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
This approach makes a lot of sense, but I think we need to give
somewhat more guidance than just a list of names. We need something
along the lines of:
"The following are suggested features for a ANSI Common Lisp
programming environment. No conforming implementation is required to
support any of these features. However all implementations must
document which of these features they support and must adhere to the
following guidelines for the features they do support. No portable
ANSI Common Lisp program can rely on the behavior of these functions,
because the behavior is sepcifically not specified in the standard."
This would be followed by a set of guidelines that:
1. Guarantee that, for example, ED invokes some sort of
editor.
2. Provide some of the CLtL standard interfaces so that
people porting their programs to a new implementation
will have a fighting chance at simple use of features
TRACE and DRIBBLE without reading the manual.
The second point is important. I was recently a developer at a
software house doing more than 10 simultaneous ports. Each port was
handled by one or more junior porters and developers only got called
in when problems happened. In this sort of environment, the last
thing you want to do is spend an hour or few reading manuals before
looking at the problem.
This approach is sort of like the one take by the FORTH folks for the
Forth-83 standard. They divided Forth up into: the required words,
the optional words with mandatory definitions, and suggested (or were
they experimental) extentions.