[gambit-list] Gambit linking

Matthew Hastie matthastie at gmail.com
Fri Nov 8 12:52:28 EST 2013


I assume there is 1:1 correspondence between a prospective (preload-module
foo) and a "x/y/z/foo.scm".

Do you have a plan for how you intend to map the preload-module identifier
symbols to their corresponding pathed file name strings?

I foresee that *preload-module* can provide a syntax that is isomorphic to
the chez scheme *visit,* and it can thus provide better syntax-case
integration. With preload-module, sources may be able to specify a
dependency on compiled syntax across gambit modules, using a syntax that is
native to gambit.

It is also great to see module loading order removed from the ordering of
objects on the gsc command-line, which if I'm not mistaken is how it is
done today.

Does the existing gsc command-line functionality continue to provide an
implicit module load order in cases where the new syntax is not present?

Is there a reasonable behavior in the absence of *preload-module *syntax,
or use cases where *preload-module* is partially provided by a subset of

Do you anticipate modules with symmetric or symmetric transitive
dependence? In such a use case, I'd presume load order is irrelevant
providing that linkage is complete, but the issue of ordering top-level
initialization may remain. This could be problematic for a proposed syntax
case usage, as it is easy to specify symmetrically dependent compiled
syntax between two files: if cyclic *preload-module* is not permitted, then
syntax-case presumably needs a separate syntax to specify syntax dependency
between files, if symmetrically imported syntax is a warranted feature.

On Wed, Nov 6, 2013 at 7:45 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:

> On Nov 6, 2013, at 3:03 AM, Álvaro Castro-Castilla <
> alvaro.castro.castilla at gmail.com> wrote:
> > It would be like a module system without the namespaces.
> Yes, that's a way to put it.
> Note that my proposal only aims to provide a very basic mechanism for
> loading in a VM modules of code with their dependencies. The "depends-on"
> form could of course be used for building a (slightly) higher-level module
> system to ensuring that module dependencies are satisfied.  By the way, I
> think this form is probably best called preload-module, so that a program
> could be written like this:
> (define (f n)
>   (preload-module math)
>   (+ (math:cbrt n) (math:fact n)))
> (define (g x)
>   (preload-module postscript)
>   (preload-module math)
>   (postscript:circle (math:square x)))
> The code would be roughly equivalent to:
> (if (not (loaded? 'math)) (load 'math))
> (if (not (loaded? 'postscript)) (load 'postscript))
> (define (f n)
>   (+ (math:cbrt n) (math:fact n)))
> (define (g x)
>   (postscript:circle (math:square x)))
> In other words, the requests to preload modules are just annotations that
> are accumulated for the whole module.  The set of requests causes these
> modules to be loaded at the very beginning of the module's execution.
> > I think that this is a very nice step, because it's an important part of
> the functionality of Blackhole or Schemespheres, but with the new features
> that you can implement at a lower level.
> > I'd actually like that this goes one step further an build a minimal
> module system (even if just select which variables to export per module).
> Such a simple module system (export / depends-on) would be very helpful for
> developing bigger applications with Gambit.
> I agree that a lightweight module system would be nice.  This should be
> fairly simple to do once the linker is modified to support preload-module.
> Marc
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131108/a189140f/attachment.htm>

More information about the Gambit-list mailing list