Re: Improper lists [Was: SRFI-1 round 3 discussion]

[Lars Thomas Hansen <lth@xxxxxxxxxxx>]

Michael Sperber writes:

>>>>>> "Sergei" == Sergei Egorov <esl@xxxxxxxxxxxxxxx> writes:
>
>Sergei> I think that the whole idea of "robustness" (meaning don't break under
>Sergei> any circumstances) is not in a Scheme tradition: after all these years
>Sergei> spent trying to convince programmers that (car '()) is an error,
>Sergei> we are back to (length "abc") => 0. Since "improper list" is synonymous
>Sergei> to "any object" (anything or a pair = anything), we will end up with a
>Sergei> list library that accepts (and often produces) nonsensical data.
>
>I agree with Sergei.

As do I.

Olin Shivers writes:

>Let's consider a binary (APPEND x y). Here's the traditional pattern:
>
>    (let recur ((x x))
>      (if (null? x) 
>          y
>          (cons (car x) (recur (cdr x)))))
>
>Again, the (CAR X) and (CDR X) expressions are not guaranteed to
>work. If you focus on *pairness*, they are guaranteed to work:
>    
>    (let recur ((x x))
>      (if (pair? x) 
>          (cons (car x) (recur (cdr x)))
>          y))

But this borders on the absurd, because under this definition,

   (append '(a b c . d) '(e f g)) => (a b c e f g)

that is, the d is silently dropped.  What kind of sense does that make?

>Now, you can focus on pairness, and still rule out improper lists by
>writing this definition:
>
>    (let recur ((x x))
>      (cond ((pair? x) (cons (car x) (recur (cdr x))))
>            ((null? x) y)
>            (else (error ...))))
>
>All this means, however, that we basically coded in a gratuitous
>restriction to our definition that wasn't at all needed. It is not
>one with the structure of the problem; we just bolted it on.

The restriction is not gratuitous; rather, it restricts the domain of
APPEND to those arguments for which APPEND makes sense.

You can well argue that we need richer operations for programming with
improper lists, but conflating those operations with operations on lists
makes programming with lists more error prone or surprising, and that
hardly seems desirable.

--lars