ANN: Common-Scheme 0.3

ANN: Common-Scheme 0.3

[Alex Shinn]

Now not only can you write portable code, you can share it easily with
your friends!

  http://synthcode.com/scheme/common-scheme/

Version 0.3 adds the optional "common-scheme" command which acts as a
package management system and multi-platform build tool all in one.
Search and install from a decentralized peer-to-peer network, or
directly from URLs.  No package description files or Makefiles needed -
everything is inferred directly from the source code itself for easy
maintenance.  Sharing has never been easier.

----

Initial support for Gambit has been added, bringing the list of
supported implementations to five (along with Chicken, Gauche, Guile and
SISC).

Major improvements to the module system have been made, including
support for identifier renaming and prefixing, plus module inheritance.
Module inheritance is a simple and intuitive system which lets you
extend a module overriding only some identifiers, or group several
modules into a single name, or provide an abstract module which acts
only as an interface.

Extensive test suites have been added, and the documentation updated and
extended.

----

Common-Scheme is non-intrusive.  You can use native implementation-
specific modules from Common-Scheme code and vice versa.  If you don't
want to bother with Common-Scheme itself you can still use other
people's distributed Common-Scheme modules with no problem using your
native module system.

Common-Scheme is in the Public Domain (though modules distributed in the
peer-to-peer network may be under any license, of course).

You can subscribe to the mailing list at:

  https://mail.gna.org/listinfo/scheme-hackers-common-scheme/

-- 
Alex

Re: ANN: Common-Scheme 0.3

[Neil Jerram]

Alex Shinn <alexshinn@gmail.com> writes:

> Now not only can you write portable code, you can share it easily with
> your friends!
>
>   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.

To my mind, doing this as a SRFI would bring two significant benefits.

1. Quality and breadth of review.  I'm sure there are many nits in the
   attempt to define a common module API, and a SRFI review would help
   to identify and discuss those.

2. Traction/authority.  Something like this will only succeed if it
   succeeds, if you know what I mean.  Getting it approved as a SRFI
   would give it a lot more authority and persuade a lot of people
   (including myself) that it really was the way to write modules in
   future.

Regards,
        Neil



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: ANN: Common-Scheme 0.3

[Alex Shinn]

[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

Re: ANN: Common-Scheme 0.3

[Neil Jerram]

Alex Shinn <alexshinn@gmail.com> writes:

> Thanks for your comments.  Which part do you think should be a SRFI?

The module system.  (As it happens, looking around today I discovered
Andre van Tonder's module system spec, which looks (to my superficial
eyes) quite similar to yours, and which is formatted as though it is
about to be submitted as a SRFI.  So it may be that a SRFI module
system will soon be in the pipeline anyway.)

> 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.

You summarize both sides of the argument very well.  I know the flame
wars are a pain, but I also know from Guile discussions how tricky
module systems are, so I suspect they're worth enduring.

To be honest, though, your comment above has made me realize that I'm
not yet your target audience.  For the next year my plans are
Guile-specific, so I can wait for the SRFI.  common-module probably
does meet the needs of people who can't wait until then, and it will
probably also provide a useful starting point for when it comes to
implementing an agreed module SRFI in various Scheme implementations.

> 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.

This aspect sounds very cool; I need to look more at it.

Regards,
        Neil



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf