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

Re: [Scheme-reports] Generalization of append, map, and for-each to other sequences

On 2012-07-01, at 5:06 PM, Alex Shinn wrote:

> On Sun, Jul 1, 2012 at 1:09 PM, Marc Feeley <feeley@x> wrote:
>> Formal Comment
>> Submitter's name: Marc Feeley
>> Submitter's email: feeley at iro.umontreal.ca
>> Relevant draft: r7rs draft 6
>> Type: defect
>> Priority: major
>> Relevant section of draft: 6.7. Strings, 6.8. Vectors, 6.9. Bytevectors, 6.10. Control features
>> Summary: Generalization of append, map, and for-each to other sequences
>> R7RS has three vector-like data types: strings, vectors and
>> bytevectors.
>> The procedure
>>   (string-append string ...)
>> exists to concatenate strings, like append concatenates lists.
>> However there is no vector-append and bytevector-append which
>> concatenate vectors and bytevectors.
>> The procedures
>>   (string-map proc string1 string2 ...)
>>   (vector-map proc vector1 vector2 ...)
>>   (string-for-each proc string1 string2 ...)
>>   (vector-for-each proc vector1 vector2 ...)
>> are for strings and vectors what map and for-each are for lists.
>> There is no such procedures for bytevectors.
>> For consistency, these missing procedures should be added.
> Thanks, ticket #436 created.
> My initial reaction is "a foolish consistency is the
> hobgoblin of little minds" as has been quoted perhaps
> too often on this list by now.  I don't like the
> combinatorial explosion in procedures for every new
> type added, and note that a general loop construct
> (as will be in the large language) extends more
> naturally, is often easier to read, and is almost
> universally more efficient since I'm unaware of an
> implementation which inlines *-map.

There is another perfectly valid consistency argument which is to only have the map and for-each operations on lists only.  What is not consistent is to have such conversion procedures for more than one type of sequence, but not all types of sequences.  I personnaly favor removing them from R7RS (because they bloat the small language needlessly), but I'm not strongly against them either because I can understand the other consistency point of view.

By the way, I find it much more important to have the following procedures, which complement append and string-append, which are not in R7RS:


Aside from the consistency argument, these procedures are very useful for divide-and-conquer algorithms on vectors and bytevectors.


Scheme-reports mailing list