Re: Modules

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hi Marek,
>
> On Sat 29 Jan 2011 13:13, Marek Kubica <address@hidden> writes:
>
>> What about "the same directory that the file is in"? The point is, when
>> writing scripts that become larger than one file, splitting them into
>> modules becomes immensely painful because the modules cannot find each
>> other.
>
> For what purpose?  If you are using modules, they are already in one
> global namespace, the various roots of which are in the %load-path
> and/or %load-compiled-path.  (resolve-module '(foo bar)) should work
> regardless of what file calls it.

If the modules are installed, that's true.  What if they are not?

Even if all of the non-installed modules are in a single tree, things
are a bit fiddly.  For work from a REPL or from Geiser, you can put

(set! %load-path (cons "whatever" %load-path))

in ~/.guile, and 

(load (in-vicinity (getenv "HOME") ".guile"))

in ~/.guile-geiser, but this doesn't do the job for scripts that want to
use those modules.  (Because scripts do not load ~/.guile.)

For scripts that use uninstalled modules, then, some kind of solution is
needed; ideally one that works for both 1.8 and 1.9/2.0, allows the code
needed to live in a single common file, rather than duplicated at the
top of each script; and continues to work if the script+module tree as a
whole is moved to a different place in the filesystem.  Also I think
it's preferable if the solution is a Guile one, as opposed to based on
the #! line, or needing a shell script wrapper.

> Perhaps you are interested in `load', which is problematic regarding
> compiled files; for example when loading from a compiled file, how will
> `load' know what is the current directory?  Note that .go files are
> installed to e.g. /usr/lib64/guile, while source is in /usr/share/guile.

Good point, thanks for the reminder about that.  But (for 1.9/2.0)
`include' will always be well-defined and reliably relative to the
containing file's name, won't it?

Regards,
        Neil