[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modules

From: Andy Wingo
Subject: Re: Modules
Date: Sun, 13 Feb 2011 20:05:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

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

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, 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]