This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Path searching.


"merry::satchell"@hermes.dra.hmg.gb writes:

> Guile expects to find modules in its search path; as I understand
> things some of this is hard coded in c, and some defined in
> boot-9. Is there a more general abstraction to be had, as loading a
> file from a search path is needed by many programmes.

Two things come to mind.  First, I like slib's notion of a vicinity,
i.e.  you can create a vicinity, and then provide the vicinity to load
primitives, so that the path search is not done repeatedly.  This is a
very clean way to avoid dozens of useless stat system calls, which can
be expensive across NFS or other distributed file systems.

(define guile-vicinity
  (make-vicinity
    (pathname (open-file-from-path "ice-9/boot-9.scm" %load-path))))

Then subsequent module loads can use a different load procedure, that
takes a vicinity as an argument, and avoid the path search:

I.e. 

  (use-modules (ice-9 regex))

could be a macro that expands into:

  (load-module-vicinity guile-vicinity "ice-9/regex.scm")

And no path searching would be required.

Second, it might be worthwhile to examine the CL pathname abstraction,
because they have developed a very general system for locating files
on the file system.  Note the experience of Emacs: not having a
pathname abstraction makes porting the system to other OS's difficult,
or at best users of the other systems must work with Unix conventions
in mind, which is a loser.  If guile is to become ubiquitous, it would
be good to get these things right.

(Ducks from hail of rotten vegetables thrown due to positive CL
reference).

-russ


--
"It's like a love-hate relationship, without the love."
             -- Jamie Zawinski, consummate UNIX hater, on Linux