Subject: Re: Amazon used lisp & C exclusively? (clc,cll)
From: (Rob Warnock)
Date: Fri, 14 Jul 2006 21:02:42 -0500
Newsgroups: comp.lang.c,comp.lang.lisp
Message-ID: <>
goose <> 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:
    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 Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607