Tom Gordon <[email protected]> writes: > The Sbank GTK binding for R6RS looks very promising and I am glad to > see that it is being actively developed. > Thanks. Sorry I've been not responding earlier, but I've thought I'd first finish a first version of the sbank tutorial[0] ;-), so people can get a first glimpse of it more quickly.
[0] http://rotty.yi.org/software/sbank/tutorial.html > I especially like that is aiming to be a portable solution for all > R6RS implementations and that it uses GObject introspection to > assure that the binding is always up-to-date. I also like the object- > oriented API, which seems more concise and natural than the more > direct API currently being used by Ikarus, which maps directly to the > verbose C functions of the GTK library. > > Once Sbank is finished and released, it would be nice if R6RS > implementors would consider including it as part of their > distributions, so that it need not be downloaded and installed > separately, also because this not especially easy to do. > I'm not too sure if that would be a good idea. I think a better solution would be working on making it easier to install (I know that it's kind of mess right now). Making releases (including all dependencies) should be a first step in this direction; I could start doing that (likely in a nightly-build, automated fashion), if there's demand. In the long(er) run, I think the R6RS community should work on an installation system for library collections (like Perl's CPAN, Haskells Cabal, etc.). The current situation, where every other R6RS Schemer has her own library collection, copying code from each other, is quite undesirable, IMO. Right now, I know about at least three bigger library collections that have duplicate code: - xitomatl :: https://code.launchpad.net/~derick-eddington/scheme-libraries/xitomatl - nausicaa :: http://github.com/marcomaggi/nausicaa - spells :: http://github.com/rotty/spells/ (yeah, I'm guilty as well) Off the top of my head, here's a (certainly incomplete) feature list I'd expect from a system for managing library collections: - Dependency and version management on the collection level. - Parallel-installability of the same collection with different versions, to ease transitions. A single program would just be able to use a single version of any library collection, but different programs could use another version of that same library collection. Effectively, you'd have different views upon the set of installed collections. I think this idea may reasonably also be carried further, by including a user id in the collection's "version" component, to allow private branches, as well as entirely avoiding the need for a central naming "authority": If two people chose conflicting (R6RS) library names, they'd be free to, but would force users to chose -- eventually pressure from the userbase would rise, and the name conflict will be resolved (or so I'd imagine ;-). - Provide support for installation both per-user, and system-wide. Ensure that fabricating Debian or RPM packages from a library collection is easy and automatable as far as possible. - Provide a programmatic (i.e. Scheme) as well as a command-line interface. I think these issues have been tackled to various degrees by solutions for Python, Ruby, Haskell et. al. On the Scheme side, there's Descot[1] and SNow![2] (generic), as well as scsh-install-lib[3], PLaneT[4] and Chicken Eggs[5]. Common Lisp has ASDF[6]. I think there should be a single software package, using a liberal (e.g. BSD) license that implements that library collection management for R6RS implementations. Implementations could then include this piece of software, if they wish. I'd appreciate feedback on this issue, and I'd be willing to join hacking on a solution that targets R6RS implementations. [1] http://descot.sacrideo.us/ [2] http://snow.iro.umontreal.ca/ [3] http://lamp.epfl.ch/~schinz/scsh_packages/ [4] http://planet.plt-scheme.org/ [5] http://chicken.wiki.br/eggs [6] http://www.cliki.net/asdf Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
