[gambit-list] How to use a module?

Hendrik Boom hendrik at topoi.pooq.com
Fri Oct 14 13:37:10 EDT 2011


On Fri, Oct 14, 2011 at 10:57:23AM -0400, Matthew Koichi Grimes wrote:
> 
> As for Black Hole, one can argue that it should be kept as a separate
> package, but there's nothing in that argument that says it can't be included
> with the default Gambit installation. I would say the same for the SRFI's
> floating around in Snow and Dumping Grounds. I would like for them to be
> included by default, and be kept "separable" if that's something the user
> cares about.

I'm sensitive to the idea that the various potential components of a 
Scheme or Lisp system should be kept separate, because the very nature 
of these languages is their malleability.  But a module system is a 
special case, because it's the thing that enables all these disparate 
functionalities to be combined smoothly.  Which is why I'd be very much 
in  favour of having one specified in R7RS.

But there's no particular reason why the module system needs to be 
embedded within a monolithic implementation.  There are more modularity 
tools available than Scheme's module system.  There separate compilation 
in C.  There's the packaging systems and dependency management in the 
various Linux distribution.  But most important is making sure that 
beginners know what to do to access them, so we can avoid having 
further discussions like this one.

> Such "batteries inculded" installations are nice because they encourage
> exploratory programming by lowering the barrier to trying out new features
> (e.g. SRFI's). They also lower the adoption barrier for Gambit as a whole,
> by lessening fears that every little thing is going to be some obscure
> installation chore. This is particularly important for non-mainstream
> languages, which, with some justification, bear the stigma of being a pain
> to set up.

Accessibility -- to beginners.  Otherwise beginners will remain rare, 
and rarely progress to mature users..

-- hendrik



More information about the Gambit-list mailing list