Re: First Try at Terminology

[Jim Kempf <kempf%hplabsz@hplabs.HP.COM>]

>The definition of a situation is designed to cover function invocations,
>macro calls, and instances of the use of special forms as well as
>conditions that might arise within a running CLOS system. A situation is
>not a purely syntactic state of affairs, because the preconditions for an
>error usually requires that something about the nature of the arguments
>to a function, for example, be known. The wording of these definitions will
>need further work.

Why not go one step further and use preconditions
and postconditions on the functions and macros, ala` Hoare logic?

Example from 87-002 spec (RET is the returned value, ARG the argument):

CLASS-OF

Pre: T
Post: RET is an element of C, the set of defined classes, if ARG is an
      instance of a class | error

The postconditions could contain error postconditions of three types:

1) errors at all optimization levels (1 in the original message)
2) errors at the lowest only (2 in the orignal message) 
3) errors which implementations are permitted to extend CLOS to
   cover.

>I believe we wish to control where extensions to CLOS are allowed to occur.
>The first four terms are designed to control semantic extensions while the 
>fifth is designed to control syntactic extensions, which are somewhat
>different.

Yes, this is a laudable goal, but I fear that any attempt to do this
in English may remain open to ambiguous interpretation. 

>I believe we want to define precise terms such as these and use them
>exactly in the CLOS specification so that, rather than the CLOS
>specification being a pseudo-user's-guide as CLtL is, it can be a
>specification suitable for an implementor.

100% agreement. Barring any agreement on more rigorous formalism, I
can live with the terminology in the base note. It's a whole lot better
than CLtL.

			Jim Kempf	kempf@hplabs.hp.com