Opened 12 years ago
Last modified 12 years ago
#328 reopened enhancement
(map 'list #'identity '(x . "abc")) should signal type-error
Reported by: | S11001001 | Owned by: | gb |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | ANSI CL Compliance | Version: | trunk |
Keywords: | Cc: |
Description
By CLHS, "Should be prepared to signal an error of type type-error if any sequence is not a proper sequence."
Instead:
cl-user> (map 'list #'identity '(x . "abc")) (x #\b #\c)
Attachments (1)
Change History (6)
comment:1 follow-up: ↓ 2 Changed 12 years ago by gb
- Status changed from new to assigned
comment:2 in reply to: ↑ 1 Changed 12 years ago by S11001001
Replying to gb:
The example there - calling FIND on a dotted list - seems superficially to be almost identical to what you consider to be a bug here, and FIND has the same "should be prepared to signal a type error ..." constraint. If there's something different about the MAP case, I can't see it.
There isn't a difference, but FIND, at least, signals such an error as of current trunk.
comment:3 Changed 12 years ago by gb
- Resolution set to invalid
- Status changed from assigned to closed
FIND happens to signal an error. MAP happens not to signal an error. If a function description says that it "should be prepared to signal an error" in some situation, code cannot count on an error being signaled in that case (or count on an error not being signaled in that case), so both behaviors (and several other behaviors) are correct.
comment:4 Changed 12 years ago by gz
- Priority changed from major to minor
- Resolution invalid deleted
- Status changed from closed to reopened
- Type changed from defect to enhancement
Now that we've resolved that either way is legal, the question remains: which is more useful for (map 'list #'identity '(x . "abc")), to signal an error or to return (x #\b #\c)? I can't imagine any use for the latter, so I'd find it more helpful if it signalled an error.
comment:5 Changed 12 years ago by S11001001
Thanks for clearing this up, gb. One might say that "should" in the ticket summary is in the sense of RFC 2119.
I'm not sure that this is a bug. The phrase "Should be prepared to signal an error" is precisely defined (in the "Error terminology" section of chapter 1 of the spec.) The example there - calling FIND on a dotted list - seems superficially to be almost identical to what you consider to be a bug here, and FIND has the same "should be prepared to signal a type error ..." constraint. If there's something different about the MAP case, I can't see it.