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