[Openmcl-devel] Lambda List Troubles

[Gary Byers]

I think that the first level of complaint (and the one that Ben likely
ran into) just has to do with duplicate parameter names in a lambda
list, and that it's only later that things check for non-constant-ness.

I don't know what (if anything) CLHS says about duplicate parameter
names in lambda lists.  I remember that someone (possibly Guy Steele)
raised the issue, but that may have been before the X3J13 cleanup
process started and I don't remember if the issues were ever formally
discussed.  What I remember (and what MCL implemented at that time and
OpenMCL inherited) was based on the result of those (informal) discussions.

It seems clear that:

(defun foo (x x) x)

(foo 3 4)

-if allowed - might return either 3 or 4, and that uncertainty was enough
to make people conclude that "the results were undefined" if a lambda
list contained duplicate parameters.

Some other cases - like


(defun foo (a ignore ignore d)
   (declare (ignore ignore))
   (cons a d))

- might appear to be better-defimed, but that it'd ultimately be better
to disallow duplicate parameter names in portable code.

There's a somewhat similar issue with LET:

(let ((x 1)
       (x 2))
   x)

and a somewhat dissimilar issue with LET*

(let* ((x 1)
        (x (1+ x)))
   ;; Even without the reference to the outer x in the initform
   ;; for the inner binding, it'd be clear that the inner sequential
   ;; binding shadows the outer one.  If we didn't refer to it, we'd
   ;; then have no way of making:
    (declare (ignore x))
    ;; suppress warnings about the outer X not being used ...
    ...)

I haven't seen any language in CLHS which clearly addresses this, but
I can't find any which clearly defines what (DEFUN FOO (X X) ...)
means.  In the case of DEFUN or something similar, it seems likely
that it's a typo or other bug, and it seems clear that there's some
benefit in checking for duplicate parameter names and signalling an
error if they're encountered.  The justification for doing that
in DEFGENERIC's case might be a little weaker (since you aren't
providing the "body" of the generic function and can't even refer
to other parameters in &optional/&key initforms), the names of the
parameters don't generally matter and duplicate parameter names
don't introduce the same kind of ambiguity.

On Thu, 9 Nov 2006, Pascal Costanza wrote:

> No, it's a problem. You are using 't as variable names, but you're
> not allowed to do that because t is a predefined constant in Common
> Lisp.
>
> Pascal
>
> On 9 Nov 2006, at 16:24, Ben Hyde wrote:
>
>> I suspect this is a bug.
>>
>> * 558$ echo "(defclass foo () ()) (defgeneric alpha (foo t t))
>> (quit)" | openmcl -n -Q --batch
>> #<STANDARD-CLASS FOO>
>>> Error: Bad generic function lambda list: (FOO T T)
>>> While executing: CCL::CHECK-GENERIC-FUNCTION-LAMBDA-LIST, in
>> process listener(1).
>>> Type :POP to abort, :R for a list of available restarts.
>>> Type :? for other options.
>>
>> That works in sbcl[1].
>>
>> The results of  (ccl::verify-lambda-list '(float string fixnum)) v.s.
>> (ccl::verify-lambda-list '(float string string)) don't look right
>> either.
>>
>>   - ben
>>
>>
>> [1]
>> 557$ echo "(defclass foo () ()) (defgeneric alpha (foo t t)) (quit)"
>> | sbcl --no-userinit
>> This is SBCL 0.9.16, an implementation of ANSI Common Lisp.
>> More information about SBCL is available at <http://www.sbcl.org/>.
>>
>> SBCL is free software, provided as is, with absolutely no warranty.
>> It is mostly in the public domain; some portions are provided under
>> BSD-style licenses.  See the CREDITS and COPYING files in the
>> distribution for more information.
>> *
>> #<STANDARD-CLASS FOO>
>> *
>> #<STANDARD-GENERIC-FUNCTION ALPHA (0)>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> -- 
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>