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

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



	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."

Hah?  I did not suggest a particular wording.  I suggested something
like what I would like to see.  I would have written it in a different
paragraph or in double quotes if I intended those exact words to be
used.  I know that I'm not good at choosing words.

    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.

R3RS (and I think R3.95RS, but I don't have a copy with me) defines "is
an error" as

When speaking of an error situation, this report uses the phrase "an
error is signalled" to indicate that implementations must detect and
report the error.  If such wording does not appear in the discussion
of an error, then implementations are not required to detect or report
the error, though they are encouraged to do so.  An error situation
that implementations are not required to detect is usually referred to
simply as "an error".

Thus if the reports defines something to be an error, a user has a
right to claim that I am sloppy or lax if I don't detect it, although
it may be my right.

I want no such connotation associated with returning one more than one
value to an implicit continuation.

That is why I raised the possibility of phrasing it as the violation
of an implementation restriction, which R3.95RS already defines for
numeric "mismatches".

Defining further terminology, or using unspecified or undefined is
fine by me.