It sounds like we're talking about slightly different things. The find-scheme-libraries! procedure is supposed to be called by an end user who has a bunch of libraries that they potentially want to import. It's not intended to be used during the import process, which works pretty much as you suggest, except that map from library name to pathname is created by a previous call to find-scheme-libraries!.
The loader's job _is_ simple -- when asked to import something, it looks up the required libraries and their dependencies in the in-memory database, then loads them in a dependency-mediated order. If one or more of the needed libraries aren't in the database, then an error is signaled and nothing else happens. The database itself is static at load time (modulo perhaps adding the content property that is deliberately not set for unloaded modules). I will probably add some additional checks such as making sure there have been no relevant changes since the pre-registrations were saved, but again that will simply cause the load to error out rather than try to repair. It's the end user's responsibility to make sure that any libraries they want to import are pre-registered in the database. If changes are made to the library files are made, they need only re-run find-scheme-libraries!, which will update the database with the new information. The in-memory database isn't a cache -- it's the source of truth, as defined by the end user. It's true that the deregistration of old versions of libraries aren't guaranteed to be correctly removed by the process, although it handles many cases now. That can be improved with more work; keeping track of registered pathnames better, etc. But ultimately we have to trust that the end user won't do anything that causes confusion, such as use symbolic/hard links. We can protect against that but not prevent it. On Sat, Nov 24, 2018 at 9:32 PM Taylor R Campbell <campb...@mumble.net> wrote: > > Date: Sat, 24 Nov 2018 15:16:39 -0800 > > From: Chris Hanson <c...@chris-hanson.org> > > > > I'm a little confused about what the problem is. Could you give specific > > examples? > > > > I'm also unsure about why having a file-system cache will help. Other > than > > persistence, what advantage does having the cache in the file system > > provide? I can see an argument that the file system forces a particular > > organization to the cache, but the downside is that the implementation is > > more complex than one in memory. > > > > I've been assuming that it's OK to have more than one library in a single > > file. The file-system approach doesn't handle that naturally, though > > multiple links to a single file is reasonable. > > What I'm asking for is that the loader's job be simple: to load an > installed library (foo bar baz), map it to a pathname, say > $libdir/mit-scheme-svm1/sld/foo/bar/baz.sld, and try to load that. If > that means installing a set of libraries defined in a single file > requires making multiple symlinks to that file, that's fine. > > Right now there's no cache, but if the process by which Scheme > discovers loadable libraries is to find everything named > *.scm/*.bin/*.com anywhere under $libdir/mit-scheme-svm1, it will be > tempting to make a cache since that's not going to be fast (and both > the on-disk cache and the in-memory cache that find-scheme-libraries! > currently creates will have to have some way to be invalidated). >
_______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
