Revised WITH-VALUES and VALUES (I think we are near agreement!)

[Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>]

    Date: Thu, 24 Aug 89 16:22:48 pdt
    From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
    To: ramsdell@linus.mitre.org

	 I must use the phrase "an error"
	to describe situations in which some implementations can signal an
	error, and others do not have to.  

    The meaning of "is an error" is that the program is incorrect, but the
    implementation may not signal the violation.  This goes very much
    against the grain of what I want, since it says that the program was
    illegal in the first place.

    I would rather say that the implementation may report the violation of
    an implementation restriction (just like in the numeric section).  The
    program is not in error, neither is the implementation, there is
    purely a mismatch.

Any encoding of information (such as an English sentence or a computer
program) must have -implicit- in it an encoding strategy.  You cannot
say "oh, and by the way, this sentence is in English" at the end of a
sentence because that phrase may be interpreted differently in another
language.  In the end, it's a grand leap of faith that anyone ever
understands anything anyone else says.

By my terminology, a mismatch can occur only when someone tries to run
an interpreter on a piece of code that it was not intended to be run on.
e.g.,
 (PRINT (+ (VALUES 1 2) 3))
If you try to evaluate it in Scheme and it gives you an error, someone
in the office nearby might be right for saying "You dummy. That file was
named foo.lisp, not foo.scheme.  It was never intended to work there.
You have a program/language mismatch."

By my terminology, once you've established the dialect which you believe
should be used to interpret the sentences in your language, it is
appropriate to call those things which are not well-defined `errors.'

Calling them errors does not entail signalling an error because the
behavior in an error situation need not be well-defined.  It is this
property which allows you to establish a conforming processor of Scheme
which also supports an interesting superset.

My assumption is that you are really just fearing that saying that such
an expression "is an error" means that you are precluded from defining
it in a superset, which I don't think is Ramsdell's intent.

Btw, in our work on ANSI CL, we found the phrase "is an error" to be too
broad for practical purposes.  It is well-defined, but it spans a number
of cases which people would like to be distinct.  Mostly it does not
distinguish between cases where you left something undefined for
efficiency reasons (e.g., it might be too hard to check type information
on + in code compiled for speed) vs something you left undefined because
two stubborn factions couldn't agree (e.g., this issue of truncating
VALUES).

The net result for Common Lisp was that the old CLtL "is an error"
terminology will be replaced in ANSI CL by a whole bunch of new terms,
which cover the same turf in more refined fashion.  The phrase "is an
error" will still have meaning in ANSI CL, but it will be a synonym for
the new and more preferred phrase "is undefined"--and it still fails to
distinguish the intent of leaving something undefined.  To fix that, we
added more specific terms which we try to use where appropriate.  e.g.,
"should signal an error" was introduced as a refinement of "is an error"
for cases where implementations are not free to extend the functionality
and where they must detect and signal the error when code is processed
in the highest safety setting. There are several other such refined
phrases which attempt to offer more intent about why something is
undefined.  I could pass along the current draft meanings of those terms
if anyone on Scheme was serious about establishing some more refined
error terminology.

[Also, my AI Lab working paper ``Exceptional Situations In Lisp'' deals
at more length and with much greater clarity on some of these issues
than I have done here. Anyone interested in a copy can send me mail
privately with their address and I'll try to mail them a copy--I don't
think MIT still stocks it since it was only a working paper and never
promoted to memo status.]