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

*To*: common-lisp-object-system@SAIL.Stanford.EDU*Subject*: Error Terminology*From*: Dick Gabriel <RPG@SAIL.Stanford.EDU>*Date*: 22 Mar 88 0811 PST

Here is the concept behind the terminology. Let D be the domain of expressions and A a domain of answers. Let E be a function E: D x Env1 x ... x Envn => A. The meaning is that E takes some expressions in D plus some number of environments and produces an answer. E is the meaning of expressions. Let's restrict D to expressions described in CLOS. We consider projections of the domain of E to D. E is normally a partial function, being defined for only a subset of D, called D'. The error terminology has to do with describing the various elements in D-D'. There are 4 subsets of D' of interest; call them D'1, D'2, D'3, and D'4. D'1 is the subset such that attempting to apply E to its elements results in an error being signaled in all cases and implementations. D'2 is the subset such that attempting to apply E to its elements results in an error being signaled in the interpreter and under the safest compiler safety setting in all implementations. D'3 is the subset on which implementations are free to define new meanings - that is, an implementation is free to extend the domain of well-definedness to subsets of D'3. Note that D'1 and D'2 are pairwise disjoint with D'3. Let D'4 be D'4 = (D-D')-(D'1+D'2+D'3) We are talking about D'1 when we say ``When situation $S$ occurs, an error is signaled.'' We are talking about D'2 when we say ``When situation $S$ occurs, an error should be signaled.'' We are talking about D'3 when we say ``The \CLOS\ may be extended to cover situation $S$.'' And we are talking about D'4 when we say ``When situation $S$ occurs, the results are undefined.'' Notice that D'4 has an odd definition: It's not part of the required well-defined portion of D, we don't want to specify that all implementations try to detect elements of D'4 even in simple cases, and the authors of CLOS don't want anyone to extend CLOS to mean anything on those elements (sometimes because there is no reasonable meaning). Is D'4 empty? No. Here is an example: ``This implies that a programmer must not use {\bf change-class} inside a method if any methods for that generic function access any slots, or the results are undefined.'' We don't want to make implementations detect uses of change-class within a method that accesses slots that might change as a result of the change-class. It's ok if an implementation detects it, though. But it's not ok for any implementor to try to extend CLOS to mean something in this case. An implementor might specify that when this situation happens the system has a conniption, but no reasonable programmer would depend on that. Since we don't seem to want to tell implementors to keep their paws off of D'4, and since I assume we don't want some mathematical treatment like this message, how about telling users to keep their hands off of D'4, thus rendering the attempts of implementors fruitless? Note that we talk about valid programs, not portable ones. Thus someone living in one implementation has to think twice about venturing into D'4 land. ************************************************************************** ``When situation $S$ occurs, the results are undefined.'' This terminology has the following meaning: \beginlist \item{\bull} If this situation occurs, the results are unpredictable. The results may range from harmless to fatal. \item{\bull} Implementations are allowed to detect this situation and signal an error, but no implementation is required to detect the situation. \item{\bull} No valid program may depend on the effects of this situation, and all valid programs are required to treat the effects of this situation as unpredictable. \endlist **************************************************************************** -rpg-

- Prev by Date:
**Proposed Wording Change to the Error Terminology (II)** - Next by Date:
**Error Terminology** - Previous by thread:
**Proposed Wording Change to the Error Terminology (II)** - Next by thread:
**Error Terminology** - Index(es):