[gambit-list] Reflection on the suitability of keeping the Scheme implementation (i.e. Gambit) and the module system split in two completely separate codebases/projects

Mikael mikael.rcv at gmail.com
Wed Jun 8 20:38:19 EDT 2011

In relation with the conversation below on the use of Black Hole, here's a
reflection on Gambit w Black Hole:

That the Scheme environment (i.e. Gambit) and the module system (i.e. Black
Hole) are completely separate, appears to be a good abstraction to me.

Even if for instance R7RS introduces modules at the level of the language
spec, still having that part of the language performed by a separate module
system tool appears like a good idea to me.

(Disclaimer: I didn't study how R7RS does modules, and I'm in no way an
expert on module system implementation)

This as there's so many things a module system could be set up to do - for
instance, access module source code data in various ways such as retrieve
packages from a remote host using who-knows what method to ensure that the
respective package is up to date.
     Also I would guess that there are details about how the code expansion
is done that the R7RS spec leaves open to the individual module system
implementation to decide.
     Also as a sidenote, a module system brings a lot of complexity with it
that you're best off distributing to code that's completely outside of the
Scheme implementation's code, so you can develop, debug and study the both
completely in separate from each other.

So while it's a realistic goal to make a 'perfect' Scheme implementation (in
the sense that it that covers 'all' usecases and could be used for years and
years with only very minor code updates), making a module system that's
'perfect' in this same sense is probably impossible.

Thus there could easily be the need for multiple module systems for a Scheme

So, I'd suppose the solution to the issue Per pointed out below about that
it's hard to integrate a module system into Gambit in a reasonable way, is
to make documentation and tools for the respective module system, that keeps
it super-clear how the user uses the module system (import of modules,
compilation etc.), and what parts of Gambit should not be used anymore by
the user except for as part of intentionally breaking into the module
system's setup during module system debugging or alike, now that the user
has chosen to use the module system.
     Obviously a module system could also block access to the Gambit
features that should no longer be used i.e. (load), (include), possibly the
-exe argument etc., or overload them with corresponding features from the
module system.
     The solution to the issue is not to make a single module system inside
Gambit that's hardwired to it and that's it.

In all cases this is what I perceive as the proper path of development,
based on seeing Gambit and Black Hole currently - how they interact and the
outcome from this interaction.

Corrections, thoughts or suggestions are welcome. For instance, what ways do
you see in which Gambit could be made even more suitable for implementing a
module system atop of it?

Kind regards,

2011/6/8 Per Eckerdal <per.eckerdal at gmail.com>

> Hehe.. The stuff you have been experiencing is a large reason to why I have
> pretty much given up working on Black Hole, it is so hard to integrate it
> into Gambit in a reasonable way.
> It kindof works for me personally, for instance because I know that the
> warning messages you see are from Gambit and not BH, but there are so many
> small things that don't make sense unless you know the inner workings of BH
> (debugging from the REPL and attempting to access the hygienically renamed
> variables is a mess), and I haven't been able to get around it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20110609/de28df54/attachment.htm>

More information about the Gambit-list mailing list