On Dec 16, 2005, at 6:37 AM, C Y wrote: > Anyway, does the idea of a grass roots effort to contact the copyright > holders of the dpANS content sound like a worthwhile project? It > would > need to be coordinated and organized, of course, and people would have > to be very polite and patient when contacting people. Any thoughts on > how to organize something like that?
I think in the *very* long run the idea of a "Community Lisp" is an interesting one (and a great name). But I also think it needs to be approached very carefully. For better or worse, the current standard is the locus of a lot of strong feelings--on the one hand it is one of the great strengths of Common Lisp and it was also produced at great cost, both financial and emotional. So any proposal to muck with it in any way is--fairly or not--going to stir up a lot of strong emotions. While eventually it might be desirable to get the dpANS licensed in a way that would allow the creation of an open source derived work, that seems to me to also be putting the cart before the horse. It seems to me better (and more in lines with the CL Gardener philosophy) to work on building grass roots support for whatever things might go into a new language specification and *then* worry about how to get those things codified. The whole point of having a standard, de jure or de facto, is to encourage conversations like this: User: Say, Mr. Implementor, don't you implement the FOO standard? Implementor: Why, yes I do. User: Hmmm, well the FOO standard says X but your implementation does not X. Implementor: Whoops, that's a bug. I'll get you a patch. But the important thing to remember is that there's nothing about having even an ANSI standard that forces the conversation to go that way. The implementor can also come back with, "Yeah, technically you're right but I think that's an unimportant part of the standard." Thus the only thing that *really* causes the conversation to go the way we want is that enough users care about feature FOO that enough implementors decide they better get with the program and implement it rather than blowing it off. The best way, I think, to build a strong base of user support for some new feature is to go ahead and build it--either as a portable library (c.f. Portable Common Loops) or as a proof of concept in some particular implementation. The former seems more likely to succeed than the latter if only because the latter tends to trigger the not- invented-here antibodies in other implementations unless the new feature is so incredibly and obviously good that everybody just has to have it. And even then, folks never seem to be able to resist mucking with things. Another possibility, and one that can proceed in parallel, is for folks to start now contributing to the various open source Common Lisp implementations so that when the time is ripe for the Community Lisp revolution, each open source Common Lisp implementation has at least one member in good standing who supports the idea. The reason the ANSI standardization worked at all was because the people involved were the implementors--they were in a position to agree to implement the standard they wrote. So that all said, I'd be much more interested in building a list of things that might differentiate Community Lisp from Common Lisp and then looking at how to get each of those made available across Lisp implementations *without* having to write a whole new language standard. -Peter -- Peter Seibel * [EMAIL PROTECTED] Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/ _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
