Neil Jerram <[EMAIL PROTECTED]> 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. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user