[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

final issue -- partial examination of dotted lists



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