[r6rs-discuss] [Formal] Eliminate compound library names

Felix pfr6rs at pnkfx.org
Mon Nov 13 12:47:04 EST 2006


On Nov 12, 2006, at 11:10 PM, MichaelL at frogware.com wrote:

>  * Compound names invite a misleading sense of file hierarchies.
>
> Compound names might make more sense if they were related to file
> hierarchies, but they aren't. ...

This statement makes it sound like R^{5.91}RS implies that compound  
names cannot be related to hierarchical file/directory structure in  
any way.

But R6RS makes no statement about the relationship between libraries  
and files (as you acknowledged in a different formal comment).

It might be true that the design of the library system does not allow  
a bijective relationship between libraries and scheme file  
hierarchies.  That is, there may be R^{5.91}RS compliant library  
forms that could not be directly mapped to file hierarchies portably  
in any coherent implementation; I have not given sufficient thought  
to the matter.

But this does not preclude a unidirectional relationship, where the  
file hierarchy provides only _some_ of the libraries available to the  
runtime.

For example, perhaps a particular scheme runtime will keep a library  
environment mapping compound names to library objects.  The system  
starts up with the (r6rs *) libraries available in the environment,  
and any libraries defined at the REPL will be incorporated into the  
environment.  But if one attempts to import a library that is not yet  
present in the environment, then the runtime resorts to searching in  
the file system to find the necessary file (perhaps in compiled  
form), and then incorporate that into the library environment.

The benefit of compound names in this hypothetical runtime is that  
there is a natural mapping from (a subset of the) compound names to  
filesystem directory paths.  If names were restricted to being  
identifiers, there would continue to be a natural mapping from names  
to filesystem directory paths, but it would not express directory  
structure portably.  Note that this design does not require that the  
filesystem maintain a directory tree of the form r6rs/*/.

----

The above response is very vague, because R6RS does not specify the  
relationship between files and libraries, and therefore I can only  
talk about hypothetical implementations with extensions like the  
ability to define libraries at the REPL (a feature that is certainly  
not part of R6RS).

Maybe the above response is only adding support to your statement, if  
I have been "misled" in the manner that you claim.

But am not convinced that compound names are a bad idea, precisely  
because I am not convinced that they preclude the use of directory  
structure when storing libraries in files (which at the moment is  
implementation-defined, right?).

-Felix




More information about the r6rs-discuss mailing list