Summary
#!key and #!rest only work when number of rest arguments is even
Metadata
- Id: a5d36ed2982409b0abb0bb7996d35ae464b6474d
- Trac id: 356
- Type: defect
- Reporter: ckeen
- Owner: felix
- Cc:
- Status: closed
- Component: core libraries
- Estimated difficulty:
- Resolution: wontfix
- Priority: major
- Milestone:
- Version: 4.5.x
- Changetime: 2010-08-25 19:13:47 UTC
- Created: 2010-08-24 14:34:19 UTC
- Keywords: DSSSL keyword arguments
Description
Both should work IMHO:
#;72> (apply (lambda (a #!rest r #!key (f #f)) f) '(something 1 2 3 4 5 f: foo)) #f #;73> (apply (lambda (a #!rest r #!key (f #f)) f) '(something 1 2 3 4 f: foo)) foo
Changes and comments
[2010-08-25 14:00:01 UTC] felix removed milestone 4.6.0
[2010-08-25 14:19:27 UTC] felix wrote:
This behaviour seems to match exactly what DSSSL (and the chicken manual) specifiers: if #!key is present, then the remaining arguments must be even-numbered, even if #!rest is used.
[2010-08-25 14:24:36 UTC] ckeen wrote:
It does! So the programmer itself needs to make sure to never violate the rule?
[2010-08-25 14:50:44 UTC] felix wrote:
Replying to ckeen: > It does! So the programmer itself needs to make sure to never violate the rule?
Well, yes. The question is, whether this is a real problem, what kind of performance-impact such a check has and whether it makes sense to accept any combination of keyword/argument pairs. What about
((lambda (#!rest r #!key f) ...) 1 f: f:)
This is legal, since keywords are first-class. Is their any advantage in disallowing this? Can there be cases where someone actually wants this behaviour? I couldn't tell, really.
[2010-08-25 15:14:25 UTC] ckeen wrote:
Replying to felix: > Well, yes. The question is, whether this is a real problem, what kind of performance-impact such a check has and whether it makes sense to accept any combination of keyword/argument pairs. What about > > ((lambda (#!rest r #!key f) ...) 1 f: f:) > > This is legal, since keywords are first-class. Is their any advantage in disallowing this? Can there be cases where someone actually wants this behaviour? I couldn't tell, really.
Beats me. Maybe this is just a nice indication that I am doing things wrong. Since I don't know how to solve this myself I propose that we close this ticket again. We can have a shot at it again when this issue keeps reappearing...
[2010-08-25 19:13:47 UTC] felix changed status from new to closed
[2010-08-25 19:13:47 UTC] felix set resolution to wontfix
[2010-08-25 19:13:47 UTC] felix wrote:
Replying to ckeen: > > > > ((lambda (#!rest r #!key f) ...) 1 f: f:) > > > > This is legal, since keywords are first-class. Is their any advantage in disallowing this? Can there be cases where someone actually wants this behaviour? I couldn't tell, really. > > Beats me. Maybe this is just a nice indication that I am doing things wrong. Since I don't know how to solve this myself I propose that we close this ticket again. We can have a shot at it again when this issue keeps reappearing... >
Another case:
((lambda (#!rest r #!key f g) ...) f: g: g:)
As the keyword-argument list is parsed dynamically, only the position can be a true indication of whether an argument is a keyword marker or a keyword argument value. I agree that it would probably remove one possible user error to check the rest list of being of even length (I think Gambit does this, but it also extends the DSSSL semantics in other way, IIRC). At this stage my performance paranoia kicks in (which is usually wrong, mind you).
So, if this is ok with you, I'll close the ticket. But doing that check is something that we perhaps should keep in mind.