lists

[Chris Hanson <cph@martigny.ai.mit.edu>]

   Date: Mon, 19 Jul 93 12:24:32 CDT
   From: Andrew Wright <wright@cs.rice.edu>

   It appears my earlier message is going to be easily misinterpreted.

   My point is that the R4RS seems to be a bit schizophrenic about what
   a list is.  On the one hand, there are "proper lists", which are
   finite length, nil terminated, and tested for by list?  On the other
   hand, there are {\it list}s that are used as domain specifiers for
   the inputs to various procedures like list-tail and member.  As
   David Carlton remarks, we don't want to make list-tail, member, etc.
   more expensive by requiring them to test that their argument is
   a "proper list".  Perhaps the section about errors and domain extension
   that David quotes is enough, but I think the description of lists could
   be made a bit clearer on this point.

   Andrew

R4RS very carefully defines a "list" to be what you are calling a
"proper list".  It also carefully defines an "improper list", and
states that an "improper list" isn't a "list".

R4RS also uses the notation {\it list} to specify arguments to
procedures which are required to be "list" objects.  This usage is
similar to that defined in section 1.3.3 but is, strictly speaking,
not covered by that section (because "list" is not one of the types
listed in section 3.4).  However, if you're willing to be less than
completely strict it is pretty obvious that any argument named {\it
list} is required to satisfy `list?'.

I think you could make a good point by saying that section 1.3.3
should be amended to include "list" in addition to the types listed in
section 3.4; this omission was obviously an oversight.

But it sounds to me like you are unhappy about the supposed vagueness
of the language in section 1.3.2.  I think that section is extremely
clear:

    When speaking of an error situation, this report uses the phrase
    ``an error is signalled'' to indicate that implementations must
    detect and report the error.  If such wording does not appear in
    the discussion of an error, then implementations are not required
    to detect or report the error, though they are encouraged to do
    so.

This magical phrase appears in only one or two places in the entire
document, not including `member' or `list-tail'.  I think that is an
unambiguous statement that these procedures, along with virtually all
other procedures in the report, are not required to signal errors when
passed data that is not strictly within their domains.