[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: miscellaneous

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
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.