[Please send followups to the common-scheme mailing list.]
Note: version 0.3.1 is available with several bugfixes.
On 9/10/05, Neil Jerram neil@ossau.uklinux.net wrote:
Alex Shinn alexshinn@gmail.com writes:
This looks like a very nice idea, but I wonder why you don't put it through the SRFI process.
Thanks for your comments. Which part do you think should be a SRFI? There are 3 aspects to Common-Scheme.
The first is the module system. There are in fact people who know much more than I do about module systems working on this. Some day it will be submitted as a SRFI. After intense flame wars, discussion will trail off, and in maybe 6 to 12 months the SRFI will be finalized. Following a period of time after that various implementations may or may not adopt the new system, with or without compatibilty for their existing module systems.
In the meantime you can actually use Common-Scheme right now with a wide variety of implementations. Worse case scenario is 2 years down the line you make a small change to the headers of your code.
The second aspect of Common-Scheme is the standard modules distributed with the system, like TCP and file-system utilities, which can't be implemented portably. These are easier to nail down, being mostly standardizing existing APIs, and if proposed as SRFIs would be easy to add as optional modules. On the other hand it would still involve a long debate and draft period, and I'm more interested in writing code at the moment than discussing it (I will however gladly listen seriously to comments on the existing APIs I'm using).
The third aspect is the peer-to-peer network (which if you've browser only has three modules at the moment, I'm in the process of converting more). An important thing to remember about the Scheme community is its fragmented nature. To embrace, rather than fight, this nature, Common-Schemes module system is decentralized peer-to-peet, and the core of the system itself is all public domain, so no one's in charge, and people are more free to do their own thing and still share their experiments than in any other package management system out there. Because the module system works side-by-side with the existing module systems, people who want to use a Common-Scheme module don't even have to know anything about CS, but just use it as a native module. And in the 0.4 release users will be able to share native modules of any Scheme implementation, not just those written in the Common-Scheme syntax.
So to answer your question, I'm aiming at a faster paced and more liberal process. I think this will provide a good breeding ground for competing libraries to develop and eventually work their way to SRFI quality.