[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 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
> 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"))
(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
Scheme-reports mailing list