Re: PROG1 as a function; meta-rules of CLtL

[Dan L. Pierson <pierson@mist.encore.com>]

    Date: Wed, 4 Jan 89 15:47 EST
    From: Barry Margolin <barmar@Think.COM>
    
        Date: Wed, 4 Jan 89 09:19:35 pst
        From: Eric Benson <eb@lucid.com>
    
        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.

I have to disagree.  Adding new keyword parameters is fairly safe,
since a new version of the Common Lisp standard would have to use that
exact keyword name in an incompatible way to cause a problem.  However
adding a new optional parameter guarantees that any new standard which
adds a new optional or required parameter to the form will cause
trouble (unless, of course, the change in the standard was to adopt
the implementation extension in question).  Since the Common Lisp
standard is (and will be, I hope) created by consensus as much as
possible, the most likely effect of such an implementation extension
is to restrict the options of any new standard.  I would personally
encourage implementations to make any additions to Common Lisp forms
via new keyword arguments rather than optional arguments; I hope that
the final X3J13 standard will specify this.

Returning extra values is a harder problem.  It causes the same
problems as new optional arguments, but there is more likely to be no
reasonable alternative.