Taylor R Campbell wrote:
> I haven't scrutinized it thoroughly, but this SRFI looks very nice.
> Some of the formatting is a little confusing: the prototypes are not
> very clearly distinguished from the other text; perhaps it could be
> indented differently, and the word `procedure' could precede the
> prototype or be right-justifed:
>
> procedure: (car /pair/)
> or
> (car /pair/)                                      procedure
>
>   Returns the contents of the car field of /pair/.

I agree the formatting could be improved.  I will try to address this in
the next revision.

> LIST-REF/UPDATE is sometimes overkill -- perhaps an operation just to
> modify the element at a particular index would be worth adding, say
> (LIST-MODIFY <list> <index> <procedure>), which would return just the
> new list with the element E at <index> replaced by (<procedure> E).

I added `list-ref/update', even though `list-ref' and `list-set' are
sufficient.  This operation generalizes both ref & set and the
`list-modify' (I would call it list-update) operation you propose.  The
reason for this is purely concerns of efficiency.  All are implementable
in terms of set & ref in O(log n) total time, but `list-ref/update'
needs to make a single access of the appropriate element in the list.

> Since random-access lists are (or at least may be, in general)
> incompatible with sequential lists, if you have written code to use
> SRFI 101, how do you use rest lists in n-ary procedures, and APPLY,
> or, more generally, how do you use code that expects sequential lists?
> This will be important to address for anyone to actually use
> random-access lists.

Just so there is no confusion:  random-access lists are not incompatible
with sequential lists in the sense that one has to commit to use
random-access lists to the exclusions of traditional lists.  It is
expected that programs may make use of *both* data types in the same
program (via prefixing of identifiers).  They are incompatible in the
sense that they are (potentially) disjoint.  So unless a system uses
random-access lists as its core pair type, bad things will happen if you
`apply' a function to a random-access list of arguments, just as will
happen if you `apply' a function to a vector of arguments.

I could add conversion functions if that seems useful (they are trivial
to define in terms of the folds given).  In a system that really
embraces the random-access pair type as fundamental, these would just be
identities.

But that brings up the issue I mentioned in another thread.  How far
should this library go to make random-access pairs usable in place of
traditional pairs.  Should it define a random-access version of `apply'?
  How about `quote', etc.?  Should it define a `lambda' form that
constructs rest lists as random-access lists?  I am beginning to think
yes, but I'd welcome feedback.  In any case, I will add this to the list
of issues in the next revision.

David