[gambit-list] A newbie's question

Christian Jaeger christian at pflanze.mine.nu
Sun Jul 8 08:31:36 EDT 2007


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.




More information about the Gambit-list mailing list