Christian von Essen wrote:

There was on this list a discussion about (a) a module system for gambit and (b) a package distribution facility with packages called "gems". I wanted to ask about the current development status of both.

I think I have been (as long as I've been reading the list) the first to bring up the "module system" topic and introduced a first (partial) solution in the form of chjmodule. My main interest in chjmodule was being able to modularize my own developments easily; I didn't concentrate on sharing, so there are no package distribution mechanisms in chjmodule, I'm just synchronizing my source code files with a co-worker through GIT. On the other side, package distribution is a primary focus of Snow.

The status of chjmodule is: it works well enough for me, or rather: I have been so busy that I didn't bother fixing some rather blatant bugs and instead got used to live with workarounds (what I mean is that because of some brokenness in tracking modified dependencies *during runtime* I have to restart the Gambit process in many cases); I've been adding some features like declaring source transformers, which I'm using for writing non-hygienic macros which can keep source location information, for example. I haven't done a chjmodule release for a long time, if there's interest I can do a release or publish my git repository. Up to now, I've been too busy to take a close look at Snow; the idea is to somehow add the features I'm needing in my work into Snow, or make a bridge, so that either chjmodule is becoming obsolete or is only taking on a role as a local "working environment" as opposed to Snow which would fulfill the packaging role--I'm not sure yet. Part of the uncertainty is that I don't know which features exactly are necessary for useful work in the future. It's probably pretty clear that the features of the Scheme48 module system are useful. But I'm also thinking/expecting features like:

- cross-module inlining declarations, or things that help the compiler deduce which functions to inline across modules semi-automatically - source transformers: for implementing scheme variations that work lazy-by-default (and/or purely functional), or that offer a static type system (keywords: Hindley–Milner, inference), but I'm not sure [yet?] if this will need special features to integrate those modules with parts of a program which are dynamically typed and strictly evaluated. - for the purely functional modules, additional compiler optimizations can be implemented (code transformations like those e.g. GHC offers) - documentation integration, code search (and autocompletion in emacs), code duplication recognition, ...

You could ask why I'm not using Haskell when it's offering many of those things. Or why I'm thinking about (partly) reimplementing half of Haskell (why not full?) on top of Scheme. My idea is that having a fully interactive and dynamically typed base underneath, you could walk between the worlds (highlevel descriptive vs. lowlevel implementation), both while choosing the level you write your code in, and for debugging.

I'm not sure this vision holds [true/successful/viable]. Could be that Haskell community will add all the dynamic stuff to their systems so that in the end they will approach the above ideal from the other side (and have more momentum). Reasons that keep me believing in writing my own module system are that for one, I'll at least learn how it all works, and for another, the "next big language" (in Steve Yegge's speak) will probably not be Haskell, but rather something like ECMA script, and knowledge how to handle all the difficult software engineering issues (and having code ready in Scheme) can help approach this world in the future (probably better than the rather closed world that Haskell looks like).

Was the package system abandoned for "snow" system? Has the development of the module system come to a halt?

Regarding the "gems" (Gambit specific packages) idea, I think this has been superceded by Snow now (it wouldn't make sense anymore now).

Regarding chjmodule, it's been in "I'm reading Haskell code instead" for some time now and is occasionally in "thinking mode" when I'm having some ideas. Meanwhile it's in "slowly getting new tiny features I need" mode. I'm hoping to get more time in the months to come to start working on a re-/(co-)implementation with Snow with maybe some help from Marc or others.

Personally, I think that a gambit specific package distribution system would help gambit's development a lot, as I am not good enough to hack gambit directly, but probably good enough to write a package.

I envision something like chicken's eggs, of course.

I think Snow pretty much correspond to the eggs approach. (Except that Snow packages can be portable across scheme implementations.) It's just that you probably want more features in the longer run either in Snow by itself or by way of hooks/bridges to add something more interactive like chjmodule, but Snow is probably open to that. (The interactive part could be tied to Gambit, and maybe be distributed itself as Snow module. How to do the lazy / type analyze stuff, I dunno [yet]; maybe as "compiler modules" (which could be distributed as Snow modules)?)

But before such a sytem can become useful, a module system is almost required. I read about gambit's namespaces (why are they not documented, anyway?), and as others have stated, it provides a base on which a module system could be written. Is there any plan to do that?

Gambit's namespaces are not complicated, you'll probably figure it out from mails in the archive (or the examples in the Gambit source distribution) quickly. BTW much of the usefulness of Gambit comes from being able to access it's internals. They being internal is of course the reason they are not documented. But see some recent discussions, e.g. there's a wiki, and some things are documented in the sources, you should read those. You could be put off by the sometimes not very clear structure of the source code, but then just ask (Marc is explicitely open to questions *).

(* https://webmail.iro.umontreal.ca/pipermail/gambit-list/2007-May/001431.html)

As we all now, the R6RS process is ongoing. Does gambit plan to adopt the standard? If not, could you please shortly explain why?

That Gambit didn't have a module system was almost a *reason* to choose it over other implementations for me. I ultimately didn't want to be tied into yet another system that wouldn't allow me to extend it.

What R6RS seems to be doing (I haven't followed development lately, though (I couldn't follow development at the begin either since R6RS has been a closed process in the begin, btw!)) is freeze the way people can work with Scheme more than it's good. They seem to be closing the openness in the hope more people are coming to Scheme. They want to make it more "finished". But I don't believe in that. If I had to choose between two finished/closed systems, one of them offering all the features Haskell offers, and one which just offers dynamic typing and no openness to develop the typing/laziness features of the former, I think I'd rather go directly with Haskell. That's my current, maybe a bit pointed and maybe not fully educated, opinion.

BTW note that Jazzscheme is being ported to Gambit. That will probably also offer a way to write modular code. From what I gather Jazzscheme is putting a strong focus on object oriented programming. You know, somewhere in the middle OO and functional should/will always meet, maybe we get all of that nice stuff (OO, purely functional, lazy, static) together. But it'll probably still mean much experimentation ahead. (Something that R6RS may not offer, to make that point explicit.)

Christian.