Re: Modified load-path proposal

[Ludovic Courtès]

Neil Jerram <address@hidden> writes:

> How so?  Given that you're about to do a (use-modules (whatnot)), I
> can't see that also doing (initialize-packages "whatnot") will make a
> significant difference.

Because people haven't been doing so for years.  Some of us certainly
don't want to iterate over each and every Guile module to add this line.
It's quite a big change and it's very interpreter-centric (okay, this
last point is maybe not the strongest argument I could come up with
;-)).

It would be different if the `initialize-packages' line could be added
automatically --- in fact, `use-modules' could do it and this would be
completely transparent to the module user (more below).

Furthermore, other interpreters are less intrusive in that respect
AFAIK.

>From a performance viewpoint, you still end up reading _and evaluating_
one more file, thus increasing actual start-up time (because chances are
that 90% of the modules that will ever be loaded by a program are loaded
at start-up time).

> I proposed something very like this before:
> http://lists.gnu.org/archive/html/guile-user/2005-10/msg00098.html
> But then I changed my mind, for reasons given here:
> http://lists.gnu.org/archive/html/guile-user/2005-10/msg00109.html

I suspected this to have already been said.  Sorry for not looking it up
in the archive.

> Sure, but simple is a complicated concept :-).  For example, the
> initialize-packages approach is simple in that it doesn't require a
> post-install script to work (whereas the config.scm approach does).

Right.  But, well, as long as this is encapsulated in some Automake
machinery, it doesn't make a big difference.

> Things aren't clear cut in terms of cycles either.  Suppose you have
> 20 Guile packages installed on your computer, spread across 6
> different load path locations.  With the config.scm approach you will
> always have all 6 locations in your load path, even when running a
> script that uses only one package (or no packages at all), so on
> average it will take a little longer to load every file that the
> script needs.  With the initialize-packages approach, the script's
> load path will only contain the directories that it really needs.

Right.

But then, an intermediate approach could consist in having an `init.d'
directories where files cannot contain arbitrary code, i.e., they only
contain a string (the load path).

Additionally, I'd be quite happy if the `initialize-packages' phase
could be made automatic.  This could be done like this:

  1. Packages install their module hierarchy wherever they want;

  2. In addition, packages may install a start-up file in, say,
     /usr/share/guile/packages/ (installing these files into the right
     Guile directory could be done by a wrapper script, say
     `guile-install-module-init').

     For instance, if I am to install the complete `foo' module
     hierarchy, then I can install /usr/share/guile/packages/foo.init
     that will be read, if available, the first time a `(foo SOMETHING)'
     module is loaded.  If that file was available, its content (a
     string) are added to `%load-path'.


More generally, when module `(foo bar)' is loaded for the first time,
Guile could:

1. Look for /../packages/foo/bar.init and use its content to
   augment `%load-path' if available;

2. If the previous file wasn't available, look for
   /../packages/foo.init and use its content to augment
   `%load-path' if available;

3. If no `init' file was found, just leave `%load-path' unchanged.


This way, `init' files are loaded on demand, like in your
`initialize-packages' approach.  However, it is less intrusive.

This is based on the observation that (i) we want modules to be
installable in *any* directory, but (ii) at some point, there must be a
*fixed* directory to look for files to bootstrap further file loading.

Not being able to execute arbitrary code in an init file is not a
problem: anyway, once an init file has been loaded, the module itself
can be loaded and execute whatever code it wants.

Note that I'm not addressing shared library load paths at all here.
However, such a mechanism could certainly be extended to support it.

Thanks,
Ludovic.