"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."
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. Thank you. 2012/7/2 Bakul Shah <[email protected]> > On Sun, 01 Jul 2012 00:09:57 EDT Marc Feeley <[email protected]> > 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 > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > -- -------------------------------------------- Kun Liang http://freearth.blog.chinaunix.net
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
