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

From: MichaelL_at_frogware.com <MichaelL>
Date: Mon Nov 13 18:22:49 2006

> > * 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?).

Thanks, Felix.

First, let me say that with naming conventions a single identifier could
still be exploded into its component parts. So it would still be possible
to recover a compound name from a single identifier. For example:

        some-library::some-physical-library

becomes

        (some-library some-physical-library)

on demand if we all agree that "::" is a delimeter. (But at least we get
to use a single identifier inside Scheme.)

Second, let me say that if there were two naming conventions you could
distinguish logical hierarchies from physical ones. For example:

        some-library::some-physical-library
        some-library::some-physical-library:some-logical-sublibrary

Here I'm pretending that "::" means "physical" (ie, directories and files)
while ":" means "logical". So the filenames for the above would be:

        some-library/some-physical-library
        some-library/some-physical-library

That is, they're the same because the logical component is ignored when
generating a file name from the identifier. (Just one possibility; there
are of course others.)

If that were the convention, R6RS names would use logical (rather than
physical) naming:

        r6rs:hash-table

        r6rs:records:procedural
        r6rs:records:implicit

I think that's a best-of-both-worlds scenario. (I'm not saying that "::"
and ":" are the way to go, just that the idea of having a single
identifier which can be split when needed is an improvement, and the
ability to distinguish physical from logical boundaries makes it even
better.)

But back to your point.

I agree that R6RS leaves the issue of mapping compound names to file names
open. I agree that an implementation might try to create a mapping.
Indeed, I said I thought that was a specific danger:

> Of course, even worse is the prospect that some implementations might
> actually decide to map compound names to files. That raises the spectre
of
> portability issues since the mapping isn't specified and would
potentially
> differ from one implementation to the next.

To reiterate: It's tempting to think that compound names have some
additional meaning, but they don't--at least, not according to the spec.
If they really have no meaning, we're making things more confusing and it
isn't clear what we gain in return. (Indeed, there are some things we
might lose.) But if we add meaning we're likely to introduce portability
issues since that meaning won't be in the spec; each implementation will
likely have its own unique approach. Since libraries exist in part to
improve portability that would be rather ironic.

But I doubt that reiterating will make my point any stronger, so I'll
stop. :-)

PS: Just in case it isn't obvious: yes, I know the naming convention
suggestion solves the one problem (identifiers) but leaves the other
(mappings) open--unless a mapping or other such algorithm is specified.
Received on Mon Nov 13 2006 - 18:22:15 UTC