(map 'list #'identity '(x . "abc")) should signal type-error

[S11001001]

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)

[gb]

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.

[S11001001]

a small patch for this issue

[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.

[gb]

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.

[gz]

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.

[S11001001]

Thanks for clearing this up, gb. One might say that "should" in the ticket summary is in the sense of  RFC 2119.