From: Stephen W. <wi...@mu...> - 2007-01-03 23:05:37
|
Juho Snellman <js...@ik...> writes: > Stephen Wilson <wi...@mu...> writes: > > Note that, in the interpreter, it is not an error for there to be > > duplicate go tags. I was not aware of this divergent behavior > > before. However, I believe the interpreter has the correct behavior. > > There are other issues tied to this (general binding semantics, > > esp. lambda args/parsing, all ANSI issues), which I can write about > > shortly. > > Ok, it would be good if you could expand a bit on that. I don't quite > understand why signaling an error for duplicate tags in compiled code > but not in interpreted would be the correct behaviour. (Beyond the > "it's undefined, so anything we do is correct" cop out). I meant that duplicate tags should be OK in compiled code, but with a warning emitted instead of an error. Of course, you are right that the behavior is undefined. That being the case, my argument is based on symmetry with other language constructs. Unfortunately, I believe SBCL is currently mishandling some of these so its difficult to use them as a counter example. Let me point out one of the issues. Duplicate parameters in lambdas are not accepted currently. The standard does not forbid duplicate parameters. It specifies the semantics of lambda arg parsing in such a way that it is consistent when duplicate parameters exist. I believe this kind of general specification should be implemented in an equally general way. I dont think the standard intended that lambda args are handled in an implementation dependent manner. I believe we should have the following: (defun foo (a a &key k (k (cons k) k-p)) (list a k k-p)) ==> WARNING: first parameter A not used. (foo 1) ==> ERROR: expected two arguments. (foo 1 2) ==> (2 (nil) nil) (foo 1 2 :k 3) ==> (2 (3) nil) (foo 1 2 :k 3 :k 4) ==> (2 4 t) Of course, my notion of conformance might be a bit whacked. I would like to know what you think. And so, my reasoning that duplicate go tags should be OK is based on agreement with the above and a belief that binding semantics should be applied consistently, even if it isnt `strictly' defined. Thanks, Steve |