[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/)
(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
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
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.