Stephen Leach scripsit:

> But this doesn't seem consistent with some of the actual uses of the
> phrase list in the function definitions. For example, list-tail is
> described as applying to a list rather than a proper list or improper
> list. However the example implementation is not constrained to work on
> a proper list. So the question arises, is that a feature you can rely on?

If the argument is a proper list, you can rely on the documented
behavior.  It is an error to pass an argument that is not a proper list
(as implied by the use of "list" as the argument), which means the
implementation may do what it likes.

> A similar question applies to list-ref and list-set! - can they
> reliably be applied to an improper list? It seems completely
> implausible to me that there would be such a constraint.

Same story.

> However, I was quite surprised to find that Guile, for example, does
> signal an error for memq for an improper list - which seems to incur
> a considerable cost - but MIT/GNU Scheme does not. So different
> implementors have made inconsistent choices.

Indeed they have: horses for courses.  I tested memq of an improper
list, first against an object that appears in the list, then against an
object that does not.

In the first case, all 39 Schemes return the tail of the improper list
except Mosh, which signals an error.

In the second case, the following Schemes signal an error:  Racket,
MIT, Gambit, Scheme48/scsh, Guile, SISC, Chez, SCM, Ikarus/Vicare,
Larceny, Ypsilon, IronScheme, NexJ, KSi, SigScheme, Shoe, Dream, BDC,
Rep, Schemik, Elk, UMB, VX, Oaklisp, Owl Lisp.  The following Schemes
quietly return #f: Gauche, Chicken, Bigloo, Guile, Chibi, STklos, Scheme
7, XLisp.  I was not able to replicate your results with MIT Scheme.

> Strictly speaking the draft clear: one cannot reliably use list-tail,
> list-ref etc on an improper list as the result is unspecified. I just
> wanted to check that this was the intention as it strikes me as a
> strange thing not to determine.

There are very few cases where R7RS implementations are required to
signal an error.  In general, passing an argument of the wrong type
"is an error"; that is, a portable program should not do it, and an
implementation may do what it likes.

> In a slightly pedantic vein I have a further query. We have
> the definition of (list-copy LIST) which does support improper
> lists. However the phrasing is not in terms of improper versus proper
> lists. In passing I note that the closing parenthesis in the text is
> missing.

Rewritten thus:

\proto{list-copy}{ obj}{procedure}}

Returns a newly allocated copy of the given \var{obj} if it is a list.
Only the pairs themselves are copied; the cars of the result are
the same (in the sense of {\cf eqv?}) as the cars of \var{list}.
If \var{obj} is an improper list, so is the result, and the final
cdrs are the same in the sense of {\cf eqv?}.
An \var{obj} which is not a list is returned unchanged.

> The same kind of issue applies to append.

Rewritten thus:

\proto{append}{ list \dotsfoo}{procedure}}

\domain{The last argument, if there is one, may be of any type.}
Returns a list consisting of the elements of the first \var{list}
followed by the elements of the other \var{list}s.
If there are no arguments, the empty list is returned.
If there is exactly one argument, it is returned.
Otherwise the resulting list is always newly allocated, except that it shares
structure with the last \var{list} argument.
An improper list results if the last argument is not a
proper list.

--
It was impossible to inveigle           John Cowan <cowan@ccil.org>
Georg Wilhelm Friedrich Hegel           http://www.ccil.org/~cowan
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People" (1953)

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports