This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
We're about done with discussion. I am patching the proposal into conformance with the results of the discussion. One issue remains. I'd like comments and votes on the behavior of procedures that do not necessarily examine the entire list when they are passed dotted lists. Consider FIND. It quits when it finds a list element satisfying the predicate. We are generally restricting most of the list-lib procedures to only be defined on proper lists. OK, so how do we want to spec (find even? '(1 2 3 . d)) Most implementations will return 2. A soft-typer might statically flag this. Do we want to sanction what most (all, more likely) implementations will do, or do we want to define this to be an unchecked error? There are three basic choices. 1. FIND may be passed a dotted list as long as it finds what it seeks -- that is, as long as it doesn't encounter the non-() list terminator. It is an error to pass FIND a dotted list that does not contain the element we seek: (find even? '(1 2 3 . d)) => 2 (find even? '(1 3 . d)) => <error> Note that even this liberal policy will guaranteed pick up errors of applying FIND to an integer or a symbol. 2. It is an error to pass FIND a dotted list. FIND, however, is not required to detect this situation and reliably report an error; that is, FIND's behavior is not specified on dotted lists. (find even? '(1 2 3 . d)) => <error/unspecified> (find even? '(1 3 . d)) => <error/unspecified> 3. The behaviour of FIND is unspecified by this SRFI on dotted lists in cases that do not require FIND to search all the way through the list. It is an error for FIND to search all the to the end of a dotted list. (find even? '(1 2 3 . d)) => <unspecified> (find even? '(1 3 . d)) => <error> These are the affected procedures: mem member memq memv ass assoc assq assv find find-tail any every list-index These procedures terminate when their shortest list argument runs out. The related issue for them is: are longer arguments allowed to be improper? append-map append-map! map filter-map map-in-order map! fold fold-right pair-fold pair-fold-right zip People appear to be all over the map on this one. My votes so far: Choice 1 (allowed): Hukriede Choice 2 (never legal): Shriram, Bawden, Egorov Choice 3 (illegal/unspecified): Felleisen, Shivers (At least, this is my understanding Matthias' opinion, based on some discussion with him.) I plan to make it a detected error for these procedures to encounter a non-nil list terminator, and their behaviour otherwise unspecified on dotted lists. Feel free to post your comments, votes and discussion on this issue while I'm otherwise hacking the proposal into conformance with the previous discussions. -Olin