On Sep 9, 2009, at 11:05 AM, Brian Harvey wrote: > But, yes, if push came to shove, and I had to choose between Scheme > sitting > around looking beautiful while Common Lisp brought home the bacon, > vs. both > Scheme and CL toiling away in the coal mines while nobody looks > beautiful, > I would proudly choose the former.
I couldn't disagree more with this sentiment. I've written many large, portable programs in Common Lisp, and have hacked on one implementation (SBCL). As a result, I'm quite familiar with what works in Common Lisp from the perspective of "bringing home the bacon", and it has very little to do with the question of prettiness or ugliness. Quite a lot can be papered over in libraries if a few essential details are taken care of. The issues I see which must yet be addressed are: * How to compile and load libraries from a source distribution * How to vary the interpretation of code based on the chosen implementation, and specifically how to load and use libraries depending on the chosen implementation * The semantics of an interactive top-level * The semantics of reloading a changed version of a library into a running image For all of the progress made on the subject of writing portable libraries by the R6RS, the first two questions were still left unaddressed. There's no standardized mapping of library name to how to actually find the library, and no equivalent of `feature-cond' which was included in the language. Something of a community consensus has evolved: a library (foo bar baz (n)) is typically mapped to something like "foo/bar/baz.sls", or to "foo/bar/baz-implementationname.sls" if it exists. How to actually *find* this path varies widely between implementations. I also find the approach of using a different file per implementation to vary library behavior to be deeply annoying. Where it's sensible, I'll arrange my own library structure to reflect this; however, if I'm facing a situation where N implementations each provide roughly the same functionality with a slightly different name, I'd rather just use a lexical tool like `feature-cond' instead of having to create N different files. (It would be a mistake to assume that this situation won't ever arise. It has in the past and will again in the future.) I expect the last two issues to be contentious, but in my opinion, they are an integral part of the practicality of Common Lisp. Just to give a concrete example, I've had a commercial web application in deployment for a customer for almost four years. It's been served off the same UNIX process for the past 1 year, 2 months. If not for a connectivity failure of the hosting provider earlier this year, it would have provided 100% availability during this time. The process hosting my personal blog has been up for almost exactly one year, with identical availability. Both applications have had changes applied over this time period. If it weren't for the defined semantics of how to evolve a running program in Common Lisp, I wouldn't have been able to achieve this. Furthermore, the applications are fundamentally portable: while they're running on SBCL today, there are no issues which would prevent them from running on *any* of the currently maintained Common Lisp implementations, and they may even work out of the box. (I haven't tried.) I don't think that introducing any ugliness or dirtiness to Scheme is necessary to achieve a similar level of practicality, and in fact, a great deal of what I perceive to be ugly about the R6RS has little to do with achieving this goal. If the WG1 goal is to produce a "core Scheme" for 50-page purists, I hope this frees up WG2 to pursue the goal of providing similar-or-better cross-implementation compatibility and practicality to what is currently available today in the Common Lisp community, building on the efforts of the R6RS committee. -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
