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

I can't agree more with this.

(Following sentences may seem aggressive, sorry for that.

I really love scheme and its design principle. I hope that scheme turns into a really great language for use.)

I don't think the 'minimal' in the design principle is saying "make the language as easy for implementing as possible". Please rethink about the design principle "not by adding features but by removing limitations".

I also think scheme should has an advanced, polymorphism (dynamic) type system.

As a programmer using C++, Java, Ruby, Clojure, Scheme(Racket) solving practical problems everyday, I don't think scheme is convenient enough for daily use. The main cause of the convenient is partly derived from the "monomorphic" property of scheme. An incomplete set of xxx-map(xxx-filter) is not consistency nor concise. (By the way, for consisitency, 'map'/'filter'... should be called 'list-map'/'list-filter'... )

The inconvenient and inconcise parts of scheme are driving me away to use clojure or ruby.

In my opinions, scheme's standard(RNRS) make little sense. For academic research/teaching, you can choose a subset of any language to demonstrate new ideas as you will. Who cares whether your demonstration conforms to some sort of "standard" as long as you presented your ideas clearly? For practical programmers, this standard is too naive to become a real useful language. These programmers are acctually using racket, guile, chicken... not standard scheme. The codes is not portable even acrossing different implementations.

Sorry for the above words. I cannot resist saying these. This is my real feeling about scheme and RNRS. Igore this mail as you will.

2012/7/2 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

--
--------------------------------------------

Kun Liang

http://freearth.blog.chinaunix.net