[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 13 Feb 2011 20:05:16 +0100
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
A couple weeks ago I wrote about figuring out relative paths for `load'
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
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
- Re: Modules, Neil Jerram, 2011/02/01
- Re: Modules,
Andy Wingo <=