[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: "Dan L. Pierson" <@multimax.arpa:pierson@mist>, Sandra J Loosemore <"firstname.lastname@example.org"@multimax.arpa>
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Wed, 7 Sep 88 20:01:41 BST
- Cc: email@example.com
- In-reply-to: Dan L. Pierson's message of Wed, 07 Sep 88 13:31:34 EDT
> "Crash and burn" does seem a bit excessive. The problem is that the
> error terminology in CLtL is too vague. We could borrow the conventions
> the CLOS folks came up with and say that the behavior is "unspecified"
> I think that we have to do that in general. One of the things that
> the whole committee really needs to decide in October is to use one of
> the two new error terminologies (CLOS or Pitman) everywhere.
Um, unspecified is unspecified: the implementation can do whatever it
wants. Soemthing in the C stabdard (pragmas, I think) was defined in
this way, and for a while gcc would run rogue, or gnu emacs, or, ...
-- depending on what it could find -- whenever it encountered a
So this particular problem is not a reason to prefer "unspecified" to
"is an error" -- both allow "crash and burn".