On Apr 6, 1:05 pm, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Just as a possibility, if each library was in a virtual file system, you
> could arrange them in some consistent way that could be independent of
> operating systems etc, and if you can access the file that holds the
> virtual file system then everything from there ought to just work. At
> least you get to decide how it works, and it can be independent of OS
> etc. Would that help clear up this thicket?
LF" library-anchor.fs" REQUIRED
and
LF" library-file.fs" INCLUDED
are pre-adapted to that. That is, if an implementation has its
libraries organized into OS-portable virtual file systems, then the
LF" word would put in a prefix that is impossible in the local OS, and
the REQUIRED and INCLUDED would recognize that prefix as indicating
that the reference is to the virtual file systems, with the leading
'subdirectory' being the name of the respective virtual file systems.
> Or is it important to use libraries to set a precedent that helps solve
> the problem more generally?
That should be encouraged, but its not the job of the standard.
Different systems set up their library systems differently, LF" allows
each to export their library hierarchies to portable source. That
makes it easier for more complex portable sources to include the
libraries that they use, to be installed somewhere into the host
library system.
At least, I am proposing it as a solution. If two implementations with
different library systems were to adopt it, that would generate the
experience from existing practice to see whether it is a workable
solution.
The original semantics I wrote was coming from my experience in single-
user systems ... in a multi-tasking, multi-user OS, the library needs
to be a path so that at a minimum, different users can share a common
library, and each have their own additions/modifications to that
library somewhere in their home directory file system.
|
