The arguments against it being legal basically boil down to allowing
implementations to note specifically what is almost certainly a
programming error.

The arguments for it being legal are 1) It does not appear to be ruled
out; and 2) There is a sensible interpretation of what it means (the
rightmost binding shadows any to the left of it.)

On the implementation front, both the Genera 8.3 and CMU CL 18a
interpreters and compilers give an error about the repeated variable.
The clisp and LispWorks interpreters return 2, and their compilers
issue warnings about the variable FOO (presumably the first one) not
being used.

 > Error: While compiling an anonymous function :
 >        Bad lambda list : (FOO FOO)

 > Error: While compiling an anonymous function :
 >        Bad lambda list : (FOO FOO)

lambda list n. a list that specifies a set of parameters (sometimes called
     lambda variables) and a protocol for receiving values for
     those parameters;

   The first part of that defintion mentions "set".  An implication
   that duplicates aren't allowed, IMHO.  

   I can't seem to find anything protesting about

       (let  (  ( a 1 )
                ( b 2 )
                ( a 3 ) )
          a )

   either. However, I wouldn't expect any standard behaviour.

--

From the HyperSpec:

  3.1.1 Introduction to Environments
  (...)
  Bindings in an environment are partitioned into namespaces. A single
name can
  simultaneously have more than one associated binding per environment,
but can
  have only one associated binding per namespace.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

HyperSpec---one of the best uses of disk space.

FWIW (probably not much!), I thought I'd run it by a bunch of
Schemes, too, Scheme being so much about the Lambda Calculus and all:  ;-}

These gave no error, and produced "1" as an answer:

        SIOD
        SCM
        libscheme
        SEL
        RScheme

These gave no error, and produced "2" as an answer (as CLISP does):

        TinyScheme
        MiniScheme
        Phantom
        HPP
        Scheme->C (the interpreter, might the compiler do better?)
        Scsh [the Scheme Shell, based on Scheme-48]

These gave error messages (as CMUCL does):

        Elk:
        lambda: foo: duplicate variable binding

        MzScheme:
        let: multiple bindings of "foo" in: (#%let ((foo 1) (foo 2)) foo)

        Gambit:
        *** ERROR IN [compilation] -- Duplicate parameter in parameter list
        (lambda (foo foo) foo)

        Fools' Lisp:
        Incorrect formal parameter redefinition of foo

-Rob

Even absent that, though, I always have to chuckle at people who
say things like "well, it's ok because it's not forbidden".  Not to
make light of someone's good faith interpretation, but really:
semantics is more than saying syntax isn't forbidden--you have to say
what is meant.  And a syntax that is not forbidden but that is assigned
no meaning can't really in any meaningful sense be permitted, unless
you want to quibble about programs like:

 ((lambda (x x) (declare (ignore x x))  3) 4 5) => 3

and whether this is reasonable, because it's clear that

 ((lambda (x x)  x) 3 4)  => ?

might return either 3 or 4.  Why?  Well,

 ((lambda (&key x) x) :x 3 :x 4)

returns 3 [because that's well-defined] and so there's precedent
for assuming that the first binding applies, but this flies in the
face of what most would say is the OBVIOUS interpretation of

 (let ((x 3)) (let* ((x (* 2 x)) (x (1+ x))) x))

which I think most people would say should yield 7.  It's LET*
where I'd expect to find the wording just plain forbidding it,
and it was all over a fight that I personally found silly which
had two components.  The first component was:

 ``We want a nice simple rule that everyone can understand.
   The rule should be "no repeated variables" and should
   not make "subtle" distinctions like binding contours.
   It should refer to the textual shape of the code.  So even
   LET* can't take repeated variables.''

I fortunately don't remember who said this, but I'm prety
sure there were multiple people who did and they're welcome
to associate themselves with this compete put-down of the user
base if the want to.  I and others advoated a rule based on
binding contours that said it was ok for LET* but not ok for LET.

The second component of the argument, which I can only hope was
really the basis of the other argument, and is what they meant
to say instead had to do with some legitimate issues that had
to be dealt with and that I would have simply dealt with by
definition, but that others felt were somehow something that if
we defined our way out of, we'd be admitting a wart in the
language that would somehow be omitted if we went with the
no repeated variables rule.  (Personally, I saw complete symmetry
where you were just trading one set of problems for another and
I wanted the rule to be semantic, not syntactic.)  Anyway,
the weird cases, if anyone cares, were things like:

  (let ((x ...) (x ...)) (declare (string x)) ...)

You might think that this should aply to the inner binding,
but others felt it should apply to both bindings or that it
was at least confusing. Consider specifically:

 (let* ((x 'foo) (x (symbol-name x)))
   (declare (string x))
   ...)

In my view, if the person needs to declare something, you
could just ask him to separate them out, but I felt that
the inner binding only should be the obvious thing for it to
span.  Again, I don't like the textual rule.    Here's another
more subtle one.  

 (lambda (x x) (declare (string x)) ...)

Seems like the same problem, right?  Well, not quite.  They
are in the same contour and so this should be illegal, didn't
I advocate?  Yeah, I did say that.  But think about

 (lambda (&optional x x) (declare (string x)) ...)

and even forget about the fact that the x defaults to nil.
We could make it

 (lambda (&optional (x "foo") (x "foo")) (declare (string x))...)

if that mattered to you.  But the thing you should be thinking about
instead of the stringness is the lack of parallel binding here.  
Optionals are processed like LET*, not like LET, and for all you
know so are required variables.  You think they're equivalent to
LET, but they're really not.  &KEY and &AUX variables are also
left to right.  Consider:

 (lambda (&optional (x 'foo) (x (symbol-name x))) (declare (string x)) ...)

and you'll start to see the issue.  Is it a reasonable conceptual
model to say that optionals and auxes are processed serially but requireds and
rests are processed in parallel... even when you know that there can't
be any way to prove whether the requires or rests are processed that way?
Plainly it's simpler to assume they are also serial, and then plainly
(if we can still call anything plain at this point),

 (lambda (x x) (declare (string x x)) ...)

is like LET*, not like LET.  But this then leaves us with a funny
rule that says that in

 ((lambda (x x &key (x x)) x) 1 2)

we should get 2 as the value since the rightmost binding should
dominate.  But we already said we have defined

 ((lambda (x x &key (x x)) x) 1 2 :x 3 :x 4)

to return 3 rather than 4 because the leftmost actual arg dominates
in a keyword pickup situation (and there's good reason to think
this is the useful thing for reasons I won't go into, so dn't try
to say that decision was just an error).

We could make up some rule that says "rightmost vars, leftmost data"
and claim we meant it that way all along.  (A careful study might
even show there was a deep reason why it has to work out that way and
we might just barely escape with a claim of a rational meaning.)

I wanted to just define that in the case of required lambda vars
or let bindings, you can't duplicate, and only in cases where you
have argument cascading can you do it.  And I'd have compromised
down to saying that when there is a duplicated var, any declaration
needs to apply to both.  but the other camp did have a reasonable
point on this second matter.  So I think we just left things
deadlocked and preserved the CLTL wording.

But I hope I've at least put to rest the idea that if the spec
isn't 100% clear, that you can just decide that since it's not
forbidden it's ok.

It reminds me of that meeting (I think it was the Monterrey
meeting in early 1986) where Steele showed up with a couple of
pages of "trivial fixes" that he thought we'd all approve without
any question and was amazed and how many were controversial.
We learned right there that we had a hard road ahead.

 -kmp

    (let ((foo 1))
      (let ((foo 2))
        foo))

     [ By the way, I now recall a "bug" report I once submited to
       Harlequin for Lispworks.  The interpreter and compiler
       serialized the bindings for "redundant" LET names in
       different orders.  So it wasn't even consistant in the
       same implementation. ]

     Personally, I'd at least always issue a warning if not make
     it an error.  However, it takes "time" to check for such
     dubious code.   I don't think there is a inherently "correct"
     interpretation of this kind of code.

   The problem is how to you serialize parallel bindings. If you
   mandate a serialization then the bindings are NOT parallel.

   I don't think this sort of encoding has any "utility" so totally
   diallowing is would be my vote. However, at time the lisp standards
   don't make the implementations work as hard as they should.

P.S.  the optional argument can have default values which depend upon the
      value of a "previous" (in left to right order) argument.  The
      nonoptional args don't quite fit in this category.

--

  3.1.3 Lambda Expressions

  In a lambda expression, the body is evaluated in a lexical
  environment that is formed by adding the binding of each parameter
  in the lambda list with the corresponding value from the arguments
  to the current lexical environment.

I take this to mean that a lambda expression establishes a *single*
environment.  Each parameter belongs to the same namespace, that of
variables.  One environment, one namespace, therefore one binding.

Besides, the definition of shadowing implies that it takes *two*
forms to have shadowing.

--

The original posting, however, was concerned with the evaluation of
the _body_: ((LAMBDA (X X) X) 1 2) ==> ?  (And in the absence of
non-required parameters.)

May I add that there are (at least) two issues here:

(1) Could we imagine a reasonable Lisp where a lambda list such
as (X X) would be legal?

(2) Can it be definitely deduced from the ANSI Common Lisp standard
that a lambda list such as (X X) is illegal?

  Note: I am not suggesting that anybody in their right mind
        should be allowed to write lambda lists like that.
        There could be contorted situations, however, where
        such a lambda list might be constructed through the
        programmatic combination of two or more lists (like
        the situations where two occurences of the same
        keyword parameter may come up in a function call
        when argument lists are appended together).

As an aside, I find I have forgotten my lambda calculus studies
and can't decide if Lxx.x is well-formed (L stands for lambda).

Maybe this whole issue is not _that_ important, but if I recall
correctly, the definitions of languages such as C and Pascal
_explicitly_ forbid the presence of two different variables
with the same name in the same scope.

Have a nice day,
Vassil.

--

Vassil Nikolov <vniko...@poboxes.com>
(You may want to cc your posting to me if I have to see it.)
LEGEMANVALEMFVTVTVM

We quickly defined a convenience notation that allowed several
arguments, but it was only as a shorthand for nested one-argument
lambdas.

So, Lxx.x would be short for (Lx(Lx.x)), a perfectly legal expression.
Applied on any argument, it would return the identity function (Lx.x)
since the inner lambda protects its x's from being substituted.  (I
have forget the usual terms for this.  Something about free variables)

In Lisp terms, (lambda (x x) x) would return its second argument if
doing things the same way as the lambda calculus _we_ learned.

On the other hand, I know there are other lambda calculi, they might
do things differently.

Consider
(let ((x ...) (x ...))
   (declare (special x) (string x)))

If we take your idea of allowing this for let* such a special
declaration could fold parts of your contour. Anyways, I fail to see
the utility of allowing duplication.

I have received a private message about Lxx.x (I use L for
lambda, maybe others would find another ASCII character more
appropriate), and there has also been a posting.  I could have
figured it out myself...  Anyway, as it has been shown, we have:

  (Lxx.x)12 === (Lx.(Lx.x))12 -> (Lx.x)2 -> 2

  (and also Lxx.x === Lxy.y)

which taken literally means that

  ((lambda (x x) x) 1 2) should=> 2

and that bindings in a lambda expression should be treated
as in a LET* form and not LET.

This doesn't look quite reasonable to me especially that
in Lisp

  (lambda (x y) ...) =/= (lambda (x) (lambda (y) ...))

although it beats me if this is merely a syntactic difference.

(I am also rather curious about what McCarthy would say about
this.)

Have a nice day or night,
Vassil.

USER(34): ((lambda (x x) x) 1 2)
2

CMUCL complaigns "Error: Repeated variable in lambda-list: X."

-- Dwight

It looks to me, basd on my understanding, that Allegro's behavior as
you have described it is conforming, but only because when you do
something that is not defined, an implementation is not constrained to
do anything in particular, and therefore pretty much any behavior
would be conforming.

IMO, it is a bad idea to go around checking to see what
implementations do in illegal cases for any other purpose than to
lobby for change in the language.  Also IMO, it is a VERY BAD idea to
think that observing a certain undocumented behavior is a promise that
the undocumented behavior will persist.

Unless you see in the Allegro doc that it INTENDS to return a certain
value in this case, you should avoid doing it.  Partly because the
behavior isn't portable and partly because it might change without
warning even in the same implementation.

Kent M Pitman <pit...@world.std.com> writes:

* ((lambda (x) (1+ x)) 3)
4

However, this is puzzling to me.  I believe that this is a side effect
of having introduced the LAMBDA macro (therefore punishing me for my
previous comments on it introduction in ANSI CL :) ), but I would
have expected the above form to signal an error.

Any enlightening comments on the matter? Am I missing something from
the specification?

Cheers

Marco

  this has been meaningful since CLtL1 and way before then.  it's called a
  `lambda form' in the standard.  

lambda form n. a form that is a list and that has a first element which is
a lambda expression representing a function to be called on arguments which
are the result of evaluating subsequent elements of the lambda form.

  3.1.2.1.2.4 Lambda Forms reads:

A lambda form is similar to a function form, except that the function name
is replaced by a lambda expression.

A lambda form is equivalent to using funcall of a lexical closure of the
lambda expression on the given arguments.  (In practice, some compilers are
more likely to produce inline code for a lambda form than for an arbitrary
named function that has been declared inline; however, such a difference is
not semantic.)

  http://www.harlequin.com/books/HyperSpec/Body/sym_lambda.html has the
  specification of the symbol LAMBDA.

| Any enlightening comments on the matter? Am I missing something from
| the specification?

  not any more.  :)

But this has been a standard thing ever since Lisp began, and in fact
was an argument against introducing the lambda macro--that it would
confuse people into thinking any form could go in the car of a form
(a la Scheme) if we allowed even one "apparent form" to go there.  
Traditionally, (lambda ...) has been the only compound form which was
permitted to be feval'd (eval'd in the function namespace).  In a
literal sense, the LAMBDA macro is a translator from the variable namespace
to the funciton namespace because it turns
 (lambda (x) x) => (function (lambda (x) x))
In other words, it requests that the form apparently in the variable
namespace be evaluated in the function namespace.  But it does this
only when you put it in a variable namespace position, as in:
 (funcall (lambda (x) x) 3)
which is equivalent to
 (funcall (function (lambda (x) x)) 3)
because the argument to funcall is evaluated in the variable namespace
and consequently is macroexpanded.  The car of a form is the functional
position and is not evaluated in the variable namespace.  In
 (f x)
the F is evaluated as (function F) not as just F, and consequently
it is also not macroexpanded.  So when you see
 ((lambda (x) x) 3)
you are NOT seeing something equivalent to
 ((function (lambda (x) x)) 3)
because macroexpansion does not occur in the car.  Conceptually, the
motivation for this is that
 ((function f) x)

Symbolics Lisp (and maybe all Lisp Machine Lisp dialects, I don't
remember and am too lazy to look) offers define-lambda-macro which
specifically allows you to define the meaning of a name L in an
expression ((L ...) ...) or (function (L ...)).  Effectively, it's
what I would have called an "fmacro" (a macro on compound forms in the
function namespace) since the convention in history has been to prepend
"f" to things that operate on the function namespace [there having been
many operations like FBOUNDP, FEVAL, FDEFINE, etc. in varying
dialects--FBOUNDP showing itself in Common Lisp].  The purpose of
lambda macros in Symbolics Lisp is to support the definition of
things like Interlisp NLAMBDA, which implicitly quoted all of its
args such that ((nlambda (x y z) (list x y z)) a b c) => (A B C)
In the Lisp Machine's Zetalisp dialect (in which the system is written;
keep in mind Lisp Machines have numerous co-resident dialects in the
same address space), you'd say
 ((lambda (&quote x y z) (list x y z)) a b c)
and in fact Zetalisp is general enough that you can also do:
 (let ((c 3))
   ((lambda (&quote x y &eval z) (list x y z)) a b c))
 => (A B 3)
Lambda macros could have also been used, though I never saw it done,
to define things like an "identity" function, such that
 (function (eql 17))
might turn into
 (function (lambda (&rest x) (declare (ignore x)) (quote 17)))
That is, they could be general-purpose macros in a different namespace
(not interfering with the meaning of functions in the variable
namespace).  I proposed the introduction of lambda macros into CL,
but no one liked it and it never happened.

See my web-annotated paper
 http://world.std.com/~pitman/Papers/Special-Forms.html
for why I think &quote and NLAMBDA and related operators (collectively
called FEXPRs in Maclisp parlance) were bad ideas.  They fell really
sharply off into almost total disuse shortly after the paper--though
I've never been sure if it was because of the paper or only because it
was an idea whose time had come and I was just coincidentally writing
about it for the same reason.

Have a nice day or night,
Vassil.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

(defun foo (...)
  ...)
(defun (setf foo) (val ...)
   ...)

(funcall #'foo ...)          ;ok
(funcall #'(setf foo) x ...) ;ok

(funcall 'foo ..)            ;ok
(funcall '(setf foo) x ..)   ;ok

(foo ...)                    ;ok
((setf foo) x ...)    ;Not specifically permitted in ANSI CL