Re: [Scheme-reports] Generalization of append, map, and for-each to other sequences Bakul Shah (01 Jul 2012 22:28 UTC)

Re: [Scheme-reports] Generalization of append, map, and for-each to other sequences Bakul Shah 01 Jul 2012 22:27 UTC

On Sun, 01 Jul 2012 00:09:57 EDT Marc Feeley <feeley@iro.umontreal.ca>  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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports