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

[Bakul Shah <bakul@x>]

On Sun, 01 Jul 2012 00:09:57 EDT 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.

A vector is as general purpose as a list and so they should be
treated equally (IMHO, speaking as an APL fan!).

But string-map and bytevector-map are not as useful as map or
vector-map; a proc may not yield a char or a byte.  Mapping a
sequence is often useful even if the result is not of the same
sequence type. But using conversion functions to/from lists
and map can get unwieldy.  This problem can be avoided if
sequence functions were generic (sort of like Scheme's number
functions). For instance

    (map string "abc" "123") => ("a1" "b2" "c3")

is as clear (if not more) than

    (map string (string->list "abc") (string->list "123"))
or
    (map string (apply map string->list "abc" "123"))

This can make many more useful functions generic instead of
needing N different versions.  Example:

    (sort char<? "taped") => "adept"

If Scheme (cl)aims to be a high level language, it should leave
efficiency issues to implementations and use generic functions
where it makes sense.

Note that a CL style LOOP macro, as Alex suggests, while more
powerful can make compositions uglier (or harder) or "inside
out".

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports