Re: Modules

[Andy Wingo]

Hello list,

A couple weeks ago I wrote about figuring out relative paths for `load'
in 1.9:

On Sun 30 Jan 2011 12:42, Andy Wingo <address@hidden> writes:

> it's not clear what to do, exactly, when
> you have compiled files; you could not have the corresponding .scm at
> all, or in any case when you've loaded the .go you don't actually have a
> port to the .scm, and in fact if the file was loaded via
> `load-from-path' you don't know exactly where the .scm is at all.
>
> Perhaps we should residualize into the .go whether the file was compiled
> for `load' or for `load-from-path', and what was the original path of
> the file.

It turns out we already have this information on the Scheme level, in
the form of source properties of the expressions.  Macros have access to
this via `syntax-source'.  Also, with "relative" filename
canonicalization, the `filename' property of a syntax source will be a
relative path if it was found in the load path, and an absolute path
otherwise.

So, I ended up reimplementing `load' as a macro (!) that expands out to
a call to `load-in-vicinity'.  Relative paths are looked up against the
dirname of the file being expanded.  If the dirname is relative, then
load-from-path is used, and otherwise load is used.

A bare reference to `load' returns a closure that will invoke
`load-in-vicinity' with an appropriate vicinity.

Hopefully this fully fixes bug 30480, discussed in
http://thread.gmane.org/gmane.lisp.guile.bugs/4359, and *part* of this
use case.  We still need an (add-to-load-path "."), as discussed in a
previous mail, to allow use-modules for uninstalled modules to work
reliably.

Cheers,

Andy
-- 
http://wingolog.org/