Hi all,
Scheme is a language of my choice and for me, as probably for many other scheme users, sharing code between different scheme systems is a concern. It is really important to have a platform like Snow where users of all major implementations could effectively collaborate. But it seems to me that Snow has unnecessary limitation of reliyng on portable code only (please, correct me if I'm wrong). It means that a package cannot use a functionality that is not available as a snow package even when the functionality is implemented by most of scheme systems. SRFI-69 (hashtables) is a good example. I think the problem is in the package model. In the current model a package provides only one feature that is the name of the package itself. It also implies that a certain functionality may have only one implementation - a portable one.
I'd like to suggest a bit different package model that is alike those used in package managers of linux distributions (rpm,deb). In this model a package may provide several features and several implementations of the same api are possible. In addition, every snow system will have a preinstalled package that provides an implementation-specific feature. For mzscheme it will look something like this: (package* snow-mzscheme (provides mzscheme)) For sisc: (package* snow-sisc (provides sisc))
Having such model we can use implementations of apis specific to scheme system. Let's consider an example with srfi-69. In mzscheme srfi-69 is loaded by this: (require (lib "69.ss" "srfi"))
In SISC it is done in this way: (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Respective implementation-specific packages will look like this:
srfi-69-mzscheme.scm : (package* srfi-69-mzscheme (provides srfi-69) (requires mzscheme)) (require (lib "69.ss" "srfi"))
srfi-69-sisc.scm : (package* srfi-69-sisc (provides srfi-69) (requires sisc)) (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Similar packages are created for other systems that support srfi-69. Having this done we can create a package that uses srfi-69 and runs on all the platforms that provide it:
(package* my-package (requires srfi-69))
(define table (make-hash-table)) ...
What do you think about this model?
Nikita
Afficher les réponses par date
Check out 'cond-expand' in snow's documentation. There are some srfi's implemented in snow that probably use it. I don't see what the aforementioned model gives us.
I'd rather see Scheme48's module system implemented in gambit... *hides*
On Dec 21, 2007 11:17 AM, Nikita Sidorov nikita1024@gmail.com wrote:
Hi all,
Scheme is a language of my choice and for me, as probably for many other scheme users, sharing code between different scheme systems is a concern. It is really important to have a platform like Snow where users of all major implementations could effectively collaborate. But it seems to me that Snow has unnecessary limitation of reliyng on portable code only (please, correct me if I'm wrong). It means that a package cannot use a functionality that is not available as a snow package even when the functionality is implemented by most of scheme systems. SRFI-69 (hashtables) is a good example. I think the problem is in the package model. In the current model a package provides only one feature that is the name of the package itself. It also implies that a certain functionality may have only one implementation - a portable one.
I'd like to suggest a bit different package model that is alike those used in package managers of linux distributions (rpm,deb). In this model a package may provide several features and several implementations of the same api are possible. In addition, every snow system will have a preinstalled package that provides an implementation-specific feature. For mzscheme it will look something like this: (package* snow-mzscheme (provides mzscheme)) For sisc: (package* snow-sisc (provides sisc))
Having such model we can use implementations of apis specific to scheme system. Let's consider an example with srfi-69. In mzscheme srfi-69 is loaded by this: (require (lib "69.ss" "srfi"))
In SISC it is done in this way: (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Respective implementation-specific packages will look like this:
srfi-69-mzscheme.scm : (package* srfi-69-mzscheme (provides srfi-69) (requires mzscheme)) (require (lib "69.ss" "srfi"))
srfi-69-sisc.scm : (package* srfi-69-sisc (provides srfi-69) (requires sisc)) (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Similar packages are created for other systems that support srfi-69. Having this done we can create a package that uses srfi-69 and runs on all the platforms that provide it:
(package* my-package (requires srfi-69))
(define table (make-hash-table)) ...
What do you think about this model?
Nikita
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
Thank you for the hint, I didn't know about 'cond-expand'.
But still, even taking cond-expand into account there might be seen several advantages of the proposed model.
First of all, it might be more convenient to develop and maintain packages for each scheme implementation independently, as developers are unlikely to support all the platforms. Let's imagine that I've got a library that relies on srfi-69 and implementation I mainly use is xxx. If 'cond-expand' is the only available option then to submit the library I will have to include cond-expand code for each implementation that has srfi-69 or I will have to wait until srfi-69 package appears in the repository. In either case the submission of the library is rather complicated. A more natural way would be if I had to create two packages: the library itself and a package called srfi-69-xxx that provides srfi-69 for my platform. The support for the rest the platforms could be easily added by their users afterwards.
Secondly, the presence or the absence of a particular feature is probably better to resolve at the package level rather than at the code level. If a platform doesn't provide a required feature and cond-expand is used then the problem will appear at compile-time (or probably run-time?). But in case of the new package model the problem will become evident at the package installation phase, which seems to be more favourable. In some way it is similar to rpm vs. tar.gz
And finally, it is probably sensible to adopt one of the most sophisticated package models - the one that is found in linux distributions - from the very beginning as package relations are likely to get more and more complicated with time.
On 12/21/07, James Long longster@gmail.com wrote:
Check out 'cond-expand' in snow's documentation. There are some srfi's implemented in snow that probably use it. I don't see what the aforementioned model gives us.
I'd rather see Scheme48's module system implemented in gambit... *hides*
On Dec 21, 2007 11:17 AM, Nikita Sidorov nikita1024@gmail.com wrote:
Hi all,
Scheme is a language of my choice and for me, as probably for many other scheme users, sharing code between different scheme systems is a
concern. It
is really important to have a platform like Snow where users of all
major
implementations could effectively collaborate. But it seems to me that
Snow
has unnecessary limitation of reliyng on portable code only (please,
correct
me if I'm wrong). It means that a package cannot use a functionality
that is
not available as a snow package even when the functionality is
implemented
by most of scheme systems. SRFI-69 (hashtables) is a good example. I
think
the problem is in the package model. In the current model a package
provides
only one feature that is the name of the package itself. It also implies that a certain functionality may have only one implementation - a
portable
one.
I'd like to suggest a bit different package model that is alike those
used
in package managers of linux distributions (rpm,deb). In this model a package may provide several features and several implementations of the
same
api are possible. In addition, every snow system will have a
preinstalled
package that provides an implementation-specific feature. For mzscheme
it
will look something like this: (package* snow-mzscheme (provides mzscheme)) For sisc: (package* snow-sisc (provides sisc))
Having such model we can use implementations of apis specific to scheme system. Let's consider an example with srfi-69. In mzscheme srfi-69 is loaded by this: (require (lib "69.ss" "srfi"))
In SISC it is done in this way: (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Respective implementation-specific packages will look like this:
srfi-69-mzscheme.scm : (package* srfi-69-mzscheme (provides srfi-69) (requires mzscheme)) (require (lib "69.ss" "srfi"))
srfi-69-sisc.scm : (package* srfi-69-sisc (provides srfi-69) (requires sisc)) (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69)
Similar packages are created for other systems that support srfi-69.
Having
this done we can create a package that uses srfi-69 and runs on all the platforms that provide it:
(package* my-package (requires srfi-69))
(define table (make-hash-table)) ...
What do you think about this model?
Nikita
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
-- James Long Coptix, Inc. longster@gmail.com
Nikita
snow-users-list@iro.umontreal.ca