Re: ANN: Common-Scheme 0.3

[Alex Shinn <alexshinn@gmail.com>]

[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:
> 
> >   http://synthcode.com/scheme/common-scheme/
> 
> 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.

-- 
Alex