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] |
"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