goose <ruse@webmail.co.za> wrote:
+---------------
| Darren New wrote:
| > Sure. So it's not "ANSI C" that lets you write the OS. It's that your
| > particular compiler has finished defining the undefined semantics that
| > C allows.
|
| The C standard differentiates between "undefined" and "implementation
| defined" whereas the Lisp standard doesn not.
+---------------
Actually, the ANSI CL standard *does* differentiate between "undefined"
and "implementation defined", except that it distinguishes them into
"undefined" [the big, bad, snot-monkeys-out-your-nose & thermonulear war
case] and the several sub-cases: "unspecified", "implementations may be
extended", "return values are unspecified", etc. From the CLHS:
http://www.lisp.org/HyperSpec/Body/sec_1-4-2.html
1.4.2 Error Terminology
...
The consequences are unspecified
This means that the consequences are unpredictable but harmless.
Implementations are permitted to specify the consequences of
this situation. No conforming code may depend on the results
or effects of this situation, and all conforming code is
required to treat the results and effects of this situation
as unpredictable but harmless. For example, ``if the second
argument to shared-initialize specifies a name that does not
correspond to any slots accessible in the object, the results
are unspecified.''
The consequences are undefined
This means that the consequences are unpredictable. The
consequences may range from harmless to fatal. No conforming
code may depend on the results or effects. Conforming code
must treat the consequences as unpredictable. In places where
the words ``must,'' ``must not,'' or ``may not'' are used,
then ``the consequences are undefined'' if the stated
requirement is not met and no specific consequence is
explicitly stated. An implementation is permitted to signal
an error in this case.
For example: ``Once a name has been declared by defconstant
to be constant, any further assignment or binding of that
variable has undefined consequences.''
...
The return values are unspecified
This means that only the number and nature of the return
values of a form are not specified. However, the issue of
whether or not any side-effects or transfer of control
occurs is still well-specified.
A program can be well-specified even if it uses a function
whose returns values are unspecified. For example, even if
the return values of some function F are unspecified, an
expression such as (length (list (F))) is still
well-specified because it does not rely on any particular
aspect of the value or values returned by F.
Implementations may be extended to cover this situation
This means that the situation has undefined consequences;
however, a conforming implementation is free to treat the
situation in a more specific way. For example, an implementation
might define that an error is signaled, or that an error
should be signaled, or even that a certain well-defined
non-error behavior occurs.
No conforming code may depend on the consequences of such a
situation; all conforming code must treat the consequences
of the situation as undefined. Implementations are required
to document how the situation is treated.
For example, ``implementations may be extended to define
other type specifiers to have a corresponding class.''
Overall, CL breaks down the issue of "undefined/unspecified" behaviour
into a dozen different cases. See CLHS 1.4.2 for details.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607