procedures allow to pick the same name for different arguments

[certainty]

Currently the following is legal:

(lambda (x x) x)
(define (foo x x) x)

According to the standard it is an error for a variable to appear more than once in the formals of a procedure.
Guile and Gambit produce an error whereas Gauche and Scheme48 don't.

It appears reasonable to me to reject code like this and produce an error.

[sjamaan]

I think it's best to make this behave the same as LET and other binding constructs. Right now that gives a warning when it detects a variable being bound multiple times. Unfortunately, I think we can't do it at this level because this complicates things a lot when considering DSSSL lambda lists.

Also, the LET warning is kind of useless because it doesn't show the line number. So perhaps this should be moved elsewhere. It could be put in compiler.scm/eval.scm, but that complicates those already very complex handlers even more. I'm not sure about the best solution for this.

Felix, if you're reading this, maybe you have an idea?

[felix winkelmann]

From the top of my head, I have no idea whether this is hard or not. The DSSSL lambda-list-deconstruction is already pretty messy.

I wonder whether this is really a problem. From simple experiments it seems that the first occurrence wins, both in compiled code and the interpreter (but I haven't tried very hard, DSSSL-llists may behave differently)

[sjamaan]

My initial thought was to add the check to decompose-lambda-list, but then you have two problems:

• The compiler calls this many times, so you would get spammed with warnings.
• The DSSSL lambda list conversion happens before calling this, so you wouldn't see the original lambda form, unless we pass that in as an extra argument of course.

If you move this into the ##sys#expand-extended-lambda-list, it would only work for regular lambda lists, not receive, define-inline, define-values and so on. Besides, I think this is only called when it actually is an extended lambda list.

[sjamaan]

For now this is too difficult to implement cleanly, and not important enough to rework the entire code for.