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/
Afficher les réponses par date
Alex Shinn alexshinn@gmail.com writes:
Now not only can you write portable code, you can share it easily with your friends!
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
[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.
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
-
Alex Shinn -
Neil Jerram