[plt-scheme] Modules and extensions (yes, again)

From: Pedro Pinto (ppinto at cs.cmu.edu)
Date: Sun Apr 20 20:41:08 EDT 2003

Mathew,

Let me prefix this by saying I am relative newcomer to Scheme so
please forgive me for the occasional stupid remark.

Having said that maybe I should try to give some details about what I
am trying to accomplish. I am working on a FFI for Microsoft .NET.
Ideally I would like for this FFI to be as "natural" as possible to
a MzScheme user. What I had in mind was something like this:

(require (assembly "mscorlib"))
    ; `mscorlib' is a dotnet assembly
    ; i.e a library holding dotnet types
    ; this `require' would invoke a special
    ; extension which would create a new
    ' module and populate it with bindings
    ; associated with dotnet types found
    ; in `mscorlib'

(show (new message-box "hello world"))
    ; where `message-box' is a dotnet
    ; type defined in mscorlib and
    ; `show' is one of its methods

I was pleased with this syntax and in fact I had a prototype
implementing it (using the custom resolver/generated module
technique).  Unfortunately with this technique it is not possible to
create modules that use dotnet types. This is a show-stopper since I
do want to build modules for distribution.

The 2nd approach you suggest looks a bit cumbersome for users. If one
wanted to create a module that uses dotnet or if no module is needed
but the (very nice) require machinery (prefix, all-except, rename,
etc) is, then one would first have to create a separate wrapper, then import
that wrapper. This is probably not a big deal but it would be nice to
do without.

Anyway, does this new information change anything on your suggestion?
 I am back to the drawing board so any insights would be welcome.

Thanks for all the help,
-pp







Setting the module-name resolver essentially defines a new dialect of
`module'. If you have a closed world and control all of the code,
that's fine. But it's no good if you want to give modules to others to
incorporate into other programs.

Maybe I shouldn't have suggested the module-name resolver in the first
place. I suggested it because of your original description of the
problem:

 My extension provides a function, load-library, which when invoked
 will load a text file and based on the contents of the that file
 create a new module containing a set of bindings. The module name is
 dependent on the contents of said file and is returned by
 load-library.

This doesn't fit into the current model of PLT modules. In the current
model, a program is a sequence of module declarations. In the model you
have implemented, a program consists of some things that get converted
to module declarations on demand.

This leaves us with a couple of possibilities that I see:

 * You don't run your code in plain MzScheme, but only in your extended
   dialect of MzScheme.

 * Instead of using `load-library' on file "foo" to generate a module,
   you create an actual module for each "foo", say "foo-wrap.ss":

      (module foo-wrap mzscheme
         (require (lib "convert-foo-to-scheme.ss" "ppinto"))
         (include-library "foo"))

   where "convert-foo-to-scheme.ss" defines `include-library'. The
   `include-library' macro could expand to definitions + provides of
   the form

       (define (v1 ... vn)
          (load-library "foo"))
       (provide v1 ... vn)

    The revised `load-library' returns multiple values or the module's
    content, instead of declaring a module. (The `include-library'
    macro must do some of the work of the old `load-library' to figure
    out what the exports should be.)

Option 2 looks promising to me, but I don't know enough about your
`load-library' to be sure.

Matthew>



Posted on the users mailing list.