[plt-scheme] Best place to install custom current-module-name-resolver?

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Apr 11 09:33:12 EDT 2008

At Thu, 10 Apr 2008 17:21:18 -0700, Derick Eddington wrote:
>      A. On Thu, 2008-04-10 at 17:17 -0500, Grant Rettke wrote:
> > On Thu, Apr 10, 2008 at 4:57 PM, Derick Eddington
> > <derick.eddington at gmail.com> wrote:
> > >  I'm not sure which problem you're trying to understand.  The technical
> > >  problem I mentioned or my end goal?
> > 
> > The end goal.
> It is to allow the use of "compatibility" libraries across R6RS
> implementations.  The purpose is to have portable automatic selection of
> libraries which use implementation-specific features, depending on the
> implementation being used.  So, a (foo) library you want to use on
> multiple implementations imports the (foo compat) library which exports
> and maybe wraps the implementation-specific features in a common way.
> Under MzScheme, foo/compat.mzscheme.ss will be chosen but not
> foo/compat.ikarus.ss nor foo/compat.larceny.ss.  This is trying to solve
> the same problem as SRFIs 0 and 7 but they can't be used for
> parameterizing the (import ---) form of R6RS programs or libraries to
> accomplish: "when running on mzscheme, need to (import (mzscheme)) to
> get `format'".  It is already supported by Ikarus, and Larceny is
> planning to support it.

To support R6RS programs, its better to change the R6RS library
resolution process, which is in "collects/r6rs/private/parse-ref.ss".

I have some reservations about changing the library-to-file mapping. My
preference would be to rely on implementation-specific library
installers and not tune the run-time search. That gives implementations
more freedom in the way that libraries are mapped to files, and it
supports operations such as installing R6RS libraries as if they were
written in a language that doesn't support mutable pairs.

In other words, I think the ".mzscheme.ss" selection probably should be
implemented in `plt-r6rs --install' instead of the module loader. Other
details of our R6RS support require an installer anyway, such as the
fact that a library must be prefixed with `#!r6rs' and R6RS libraries
cannot be used at all until they are installed in a collection.

At the same time, if it turns out that you can edit and use the same
files directly when developing with multiple implementations (by
setting enough environment variables, always using `#!r6rs', etc.), I
can see why the load-time search for ".mzscheme.ss" could be more

So, if you can create a patch to "parse-ref.ss" (and probably
"find-version.ss") to search for ".sls", ".mzscheme.sls", and
".mzscheme.ss", I'll apply the patch.


Posted on the users mailing list.