[r6rs-discuss] [Formal] Requirement to detect circular lists

From: Shiro Kawai <shiro>
Date: Tue Oct 3 18:42:13 2006

From: dyb_at_cs.indiana.edu
Subject: Re: [r6rs-discuss] [Formal] Requirement to detect circular lists
Date: Tue, 03 Oct 2006 09:53:57 -0400

> > I understand the importance of portable semantics. Yet a question
> > remains: what do we gain by limiting the domain of 'map' to plausible
> > lists of length-n, instead of explicitly allowing circular lists and/or
> > lists of different lengths (e.g. plausible lists up to n).
>
> By extending the domain of map, we would allow some map calls to produce
> values that would otherwise have raised exceptions. In some cases, this
> behavior would be desirable; in others, it would mask errors in the
> program.

Yes... by extending numbers from integers to rationals, we would allow
some '/' calls to produce values that would otherwise have raised
exceptions; in some cases this masks errors, since a programmer
may be thinking he is always passing a dividend which can be divisible
by a divisor. How can we know?

I agree on the general principle to err on the safe side, but
to me, passing circular or lists of different lengths to map
and expecting map to work on the first N elements of each where
N is the length of the shortest proper list, is a plausible
way of coding. Well, even a strongly typed language like Haskell
allows that:

    Hugs> zipWith (+) [1, 2, 3] [4, 5]
    [5,7]

Talking about errors, mutating a list while traversing it seems
much more likely to be an error than passing circular list to
the traverser (except the case that mutation doesn't change the
traversing order). CommonLisp explicitly prohibits such mutation
(section 7.9 in CLtL2). It hits funny to me that R6RS discusses
on such weird examples, yet prohibits more natural (to me) coding
of passing lists of different lengths/circular lists to 'map'.

Another thought hit me. This 'plausible list' check on the argument
can be done at any moment between the call of 'map' and alike and
the return from it, right? So an implementation can check the
arguments upfront, before calling the given procedure, or it can
check arguments while applying the procedure element by element.
So the following code may return or raise an exception, when
xs and/or ys are not plausible list of length N.

 (call/cc
   (lambda (k)
     (for-each (lambda (x y) (if (negaive? x) (k y))) xs ys)))

Doesn't this scar the goal of portability? And the implemenations
that doesn't check arguments upfront are "masking the errors"---
it wouldn't detect violation as far as xs contains a negative number
and shorter than ys. So I doubt how effective, as an error
detection mechanism, the "plausible list of length-N" restriction is.

Eventually it comes to a balance. I think the claim on the
restriction as to err on the safe side has its merit, but I
feel the current spec is off-balance (trying to detect a narrow
range of errors while letting bigger errors pass through;
I mean not prohibiting mutation during traversing).

--shiro
             
Received on Tue Oct 03 2006 - 18:43:27 UTC