PROG1 as a function; meta-rules of CLtL

[Barry Margolin <barmar@Think.COM>]

    Date: Wed, 4 Jan 89 09:19:35 pst
    From: Eric Benson <eb@lucid.com>

       Date: Tue, 3 Jan 89 20:10 EST
       From: Barry Margolin <barmar@Think.COM>

       One of our users noticed today that Symbolics defines PROG1 as a
       function, rather than as a macro as CLtL specifies.  The definition is
       essentially

	       (defun prog1 (first-form &rest rest-forms)
		 (declare (ignore rest-forms))
		 first-form)

       This works because CL requires left-to-right evaluation of function
       arguments; it just does a bit more consing than a macro implementation
       would need to do.  

    Actually, it doesn't do any more consing than the macro definition,
    because &REST arguments are stack-allocated on Symbolics machines (in
    generally-agreed-on violation of CLtL).  Even in Lucid's implementation
    this definition would not cons, because the ignored rest argument is
    never created in the first place.

True.  I didn't realize that EVAL consed the arguments on the stack (I
thought only compiled code did it). 

    Is it OK to define Common Lisp functions with extra optional or
    keyword parameters, with system dependent meanings?  E.g. Lucid's
    COMPILE-FILE has several keyword arguments not mentioned in CLtL.

    Is it OK to return extra values from Common Lisp functions?

    Is it OK to define the behavior of functions on datatypes not
    explicitly permitted in CLtL?  For example, suppose I defined + on
    vectors to do componentwise addition on the elements?  Arguments to +
    "must" be numbers, meaning that it "is an error" to supply anything
    other than numbers, meaning that anything can happen when you supply
    arguments other than numbers.

Those of us in X3J13 have been thinking about this general problem for
several years, but there still isn't a clear concensus.  I believe that
it was the original intent of the CL designers that implementations be
permitted to do many of these things.  Anything that "is an error" is a
potential place for extension.  Symbolics has done all of the above.

Adding optional parameters or returning extra values is usually safe.
Programs can get in trouble, though, if they use multiple-value-list or
multiple-value-call with functions that have been extended in such ways.
For instance, (multiple-value-call #'cons (floor x y)) looks portable,
but it will try to pass the wrong number of arguments to CONS if FLOOR
returns an extra value.

    Suppose an implementation printed
    >>Attention: Taking CAR of (1 2 3)!
    every time CAR was called.  I don't suppose many people would use
    it, but would it be a legal Common Lisp implementation?

This is something I remember Kent Pitman bringing up a long time ago,
under the general topic of automatic output.  The above is obviously an
extreme case, but there are realistic analogues, such as GC
notifications, autoload heralds, and progress messages from COMPILE-FILE
or LOAD.  Since we weren't sure how to tackle these, we've generally
dismissed them as "environment" features, which CL generally doesn't
address.

                                                barmar