This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
I don't see any rationale for: (library <lib-path> <language> <body>) rather than identitying a library with a file, as in: (library <lib-path> <language>) <body> The former is syntactically awkward: Moving definitions from a top-level file to a library requires re-indenting. There is too much indentation and parentheses as it is; I think top-level definitions in a library really should be top-level. A minor advantage: It also opens up for non-Scheme read syntax: (library "my-lib" "xml-scheme://") <define-function name="fact">...</define-function> <!-- I don't claim this is terribly useful! --> Also, the proposal is unclear about non-libraries: Can I import a library into "the top-level"? Would everything be a library in this new world? In that case, having to wrap eveything in a library form would be a pain. Instead, I propose we view the "top-level" as an library that just has imports but no exports. More importantly, there are practical advantages of declaring that library==file. It allows library-name==file-name. This means you can search for libraries without having to scan them or build a "library database". This has worked pretty well for Java - and for Kawa. In Kawa a module is a source file that get compiled to a main class file (and possibly auxilliary classes).You would still have that the "way that URIs for library references are mapped to library declarations is implementation-specific." However,
the most common mechanism would make use of file naming: Relative lib-paths would be interpreted by searching an implementation-specific library search path, but the default initial component of the search path is relative to the current library, using URL resolution. I.e. assume library "util/stack" imports "vector". Then that would resolve to "util/vector", in the normal cases. No configuration files or separate data-base needed: The file-system hierarchy is the library data-base. Note in my proposal you don't really need the <lib-path> to be specified in the library form. The <lib-path> is inferred from the file-name. This is just like you don't have to specify a file's URL - it's just there. This makes the (library ...) form optional. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/