On 2011-03-11, at 08:26, Noah Lavine wrote:

> I believe that in addition to a module system, we need a standard
> directory for people to put R7RS modules in. This would be for modules
> that used the R7RS module system and R7RS modules, and would be in
> addition to whatever place implementations put modules using their own
> extensions.

[...]

> I don't think it matters much where the directory is. To me it would
> seem most natural to use /usr/lib/r7rs on Unix machines and something
> analogous on Windows ones.

Noah,

I'm taking the opportunity to reply to your email in public because I think that although there are serious problems with the details of your proposal, it's a highly meritorious and achievable goal. I hope that your email and this reply start something of a discussion which might help evolve the kind of specification you are talking about.

As to the problems...

First, I'm certain that R7RS is not the right place to standardize this behavior.  For one thing, programming language standards are supposed to be as detached as possible from the environment. ANSI standards used to contain boilerplate about `this standard does not define how a program is processed or stored on a data processing system'. Environments change over time; it's entirely possible, for example, that someone might build a Scheme system as an add-in to a relational DBMS, in which case programs might be stored in tables, or as DBMS procedures, or in some other way. Mobile phone and tablet OSes, too, may have substantial restrictions on where files can live. (And yes, I do appreciate having a Scheme system on my Motorola Milestone :).

Second, the problem is a lot more complicated than it looks, especially when it's going to store modules created by Scheme programmers, as well modules provided by an implementation. For example, a university computer science department might have a standard install directory for a Scheme system, then directories for individual courses; and of course each individual might have his or her own Scheme library. Secondly, you might have several implementations installed on the same machine (I for example generally have four or five different Scheme systems on machines I set up). And you might have different releases of the same system installed (or even different builds of the same release!). Not all of these versions will use the reference implementations of each standard module, and furthermore different releases of a given implementation might each have their own implementation of a specific module. Microsoft messed this up very badly, resulting in what Windows programmers call `DLL Hell'. (Their attempt to fix it ended up with something named after a Klingon delicacy, the `GAC', with its own peculiarities and difficulties.)

These problems can be fixed. For example, recent versions of Python encode the implementation and version into the object file name. Thus foo.py is compiled into foo-cpython3.2.pyc. Similar things can be done here. In fact, some of the R6RS implementations have followed this kind of approach, using a set of standard directory conventions.

I would suggest that a document with a set of workable standards could in fact attract the support of implementers of R7RS-compliant Schemes. If you want to take on the (onerous) job of drafting such a document, I suggest starting by working with the community to derive a set of requirements, and working with implementers to see whether there is a set of standard conventions they could all support. Then a report can be drafted for community input. (It wouldn't need to be very long, I hope, but would need to address all the issues that were identified in the consultation phase.) Implementers could then decide whether or not they wanted to comply with the specification.

Hope you find these thoughts useful. -- vincent
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports