Dear all, I'm a Lisper at heart, and I'd like the next Scheme to be the future of Lisp. However, looking at Scheme from the point of view of someone who's lived with Common Lisp, Caml and Haskell, I find that the Scheme world is singularly lacking in abstraction.
Because Scheme standardizes no such thing as abstraction interfaces and implementations, Scheme programs define a vast impenetrable jungle of datatypes with special-purpose monomorphic constructors and accessors, that mutatis mutandis reminds me of Pascal more than any other language (and at least, Pascal had record types). Case in point: your u8 vs char ports. We need a family of disjoint functions, because we can't define a generic type-parameterized "port" abstraction. Generic sequences? No, plenty of functions for lists, plenty of strings, plenty for ports, as many for lazy streams, etc., without even a systematic convention for function names, order of arguments, etc. Common Lisp has generic functions specialized over classes with multiple inheritance mixins, which provides a slightly painful but working mechanism for providing some abstraction. Clojure builds on Java interfaces and provides a somewhat coherent set of generic abstractions for all the usual datatype combinators and algorithms. PLT has the very promising concept of units, but whether there's something wrong about their design or not, they seem vastly underused in the PLT world. In the non-Lisp world, Haskell has type classes, ML has higher-order modules, plenty of languages of objects and classes or prototypes, some have interfaces, etc. Sure, you can always do it with higher-order functions with tens of arguments. Good luck to remember the number and order of arguments, and maintain it as the interfaces evolve. Especially without such things as keyword arguments. Conventions enforced by macros can do it all for you, too. But I don't need no new standard to already invent my own language that only I can speak, I need one to be part of a fruitful ecology of code sharing. In short, instead of arguing whether this or that datastructure with its accompanying flurry of associated (de)constructors should be in the standard, I'd like to see some discussion about what kind of datastructure abstraction should or shouldn't be in the standard. The default answer of "no abstraction" would be quite disappointing, as it would means more jungle and more macheting through it (or avoiding to step into it). But maybe I'm addressing the wrong audience. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis But what about 10 orthogonal constructors for data structures that automatically generate associated constructors, accessors, folders, zippers, etc.? _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
