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 <wi...@pobox.com> 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/
