l...@gnu.org (Ludovic Courtès) writes:
> My current inclination would be to fully reject it, then.
Okay.
> Currently there are two stat(2) for each entry in $GUILE_LOAD_PATH:
[...]
> That would double that.
>
> This is likely to become noticeable with large $GUILE_LOAD_PATH values
> and/or numerous module loads.
Yes, I worried about this too. Even now, the number of stat calls is
unfortunate, especially for people who extend their %load-path.
For Guile 2.2, it might be worthwhile to consider ways to reduce the
expense of loading modules, and if so, maybe we can revisit this
question later.
One option would be to return to Aubrey Jaffer's model (used in SCM),
where a catalog of modules and their locations is maintained and must be
explicitly rebuilt when software is installed. Optionally, if the user
attempted to load a module not found in the catalog, we could fall back
to an explicit search, and if successful, issue a warning with a
reminder to rebuild the catalog.
Alternatively, on systems that support inotify (or something like it),
we could construct this catalog during initialization and efficiently
keep it up-to-date by receiving notifications when changes are made to
the relevant directories, or when %load-path is changed.
> (I’m not sure if searching for a file name with no extension is
> intentional. Ideas?)
I looked into this. Guile has searched for file names with no extension
since its initial import into VCS in 1996 (0f2d19dd). Initially, names
with no extension were searched _before_ *.scm, and this logic was
hard-coded into the search procedure (try-module-autoload in
boot-9.scm). Jim Blandy introduced the '%load-extensions' variable with
default value ("" ".scm") later in 1996 (26544b96), and Mikael Djurfeldt
reversed the order to (".scm" "") in 1999 (0a74e31d). It has been that
way ever since.
Mark
