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

Code as Spec: {Issue: THE-AMBIGUITY (Version 2)}

      Clarify that the type specifier in
	    (THE type exp)
      may be any valid type specifier.  In the case that exp returns one
      value and type is not a VALUES type specifier, (THE type exp) is
      equivalent to
	    (LET ((g exp))
	      (DECLARE (TYPE type g))
      where "g" is a gensym.

I'm not very happy with this style of specification: instead of
spelling out what "for declaration" means, a piece of code is
offered which is allegedly "equivalent".  But "equivalent" under
what terms?  Does this mean that for those types for which <type>
has specialized storage (and for which the compiler takes advantage
of declarations to use that specialization) then 

        (THE type exp)

imples that "exp" must also be in specialized storeage?

I remember a similar misleading definition -- the one that was worked
out "on the fly" at the Boston meeting for:
    (COERCE '(LAMBDA (...) ...) 'FUNCTION)
It said that such a form should be like:
    (EVAL '(FUNCTION (LAMBDA (...) ...)))
[or, words like that].  Presumably this was a cheap way of trying to say
"closure in the null lexical environment".  I objected to this as being a
circular definition, since both forms will be implemented by some
non-portable code in each implementation, and it is precisely the
behaviour of that non-portable action that need specification.  Anyway,
I mention this now because some vendors have, upon ocasion, delivered a
subseted Common Lisp without an interpreter in it; the above-mentioned
style of definition would imply that COERCE should not work in such a
subset.  But in fact, COERCE can quite easily work; it is APPLY that
probably cannot work.

Code as illustrative example, of course, is fine.  And while the
colloquialisms of code segments can be a shorthand for fuller
definitions, we need to be awfully careful that we don't use it in
situations where the reader will really understand it only if he 
already knows what it is trying to say.

-- JonL --