This page is part of the web mail archives of SRFI 101 from before July 7th, 2015. The new archives for SRFI 101 contain all messages, not just those from before July 7th, 2015.
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