[Snow-users-list] Package model suggestion

Nikita Sidorov nikita1024 at gmail.com
Sun Dec 23 03:21:21 EST 2007


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 at 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 at 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 at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
> >
> >
>
>
>
> --
> James Long
> Coptix, Inc.
> longster at gmail.com



Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/snow-users-list/attachments/20071223/f931cd1c/attachment.html 


More information about the Snow-users-list mailing list