[R6RS] Modules

[R. Kent Dybvig]

Manuel and Mike have suggested some fundamental changes to my module
proposal that destroy much of what I think is good about what Matthew
and I came up with through our discussions and compromises.  I've tried
without success to reconcile these changes with how I think the module
system should work.

Here are some points I feel strongly about where there appears to be too
much disagreement for compromise.  If someone sees room for compromise
on these points, please let us all know.

- Implicit export declarations should always be required, for reasons
  I've already stated.

- Local require forms should be permitted, for reasons I've already
  stated.

- We should be able to write macros that expand into require, provide,
  and even module forms.  The opening paragraph of the r5rs expresses
  the guiding principle here:

    Programming languages should be designed not by piling feature on top
    of feature, but by removing the weaknesses and restrictions that make
    additional features appear necessary.  Scheme demonstrates that a very
    small number of rules for forming expressions, with no restrictions
    on how they are composed, suffice to form a practical and efficient
    programming language that is flexible enough to support most of the
    major programming paradigms in use today.

  Note specifically the part about "no restrictions on how they are
  composed".  I realize I may be the only one, but I truly dislike having
  any reserved words or un-abstractable meta language.

  (I'm not necessarily opposed to a convention for shared libraries stored
  in some standard "CSAN" repository that, say, requires the top-level
  forms of a library file to be module forms, but such restrictions
  should not apply to Scheme programs in general.)

- While I don't mind including support for separate interfaces, they
  should not be required.

- While I don't mind including support for type declarations, they
  should not be required.

- There should be a standard way for a require forms to specify where to
  look for implementations of the required modules.  A portable Scheme
  source file (e.g., shell script) should be just as easy to write as,
  say, a Perl script, and should not require any external configuration
  file to tell the implementation where to find required modules.
  In particular, there should be a way to specify pathnames that are
  relative to the current directory and pathnames that are relative to
  some installation-specific set of library directories.

We may be able to resolve, in a sense, some of our disagreements by
giving some things the "it is an error" label, as Matthew has suggested,
and leaving other details implementation dependent, but this will not
give us truly portable libraries.

Here are some questions I have for others, regarding claims or preferences
that I don't understand.

* Why are any changes to my proposal necessary to allow the use of
  Unix "Make"?  In particular, having a separate specification language
  is not necessary, and being able to determine requirements without
  expansion is not necessary, or Make could not be used for C.
  Incidentally, I too prefer to use Make and have used it extensively
  for over 20 years.

* If actual requirements are specified via some external configuration
  language, why do we need a require form at all?  If it's just to
  specify the particular set of identifiers that need to be made
  visible from a required module, why is there any resistance to allowing
  abstraction of require forms and/or require forms to appear in local
  scopes?

* For those who favor separate configuration information, what do you
  anticipate a Scheme shell script that requires one or more portable
  modules will look like?  Will all scripts have to have separate
  configuration and/or Make files?

* For those who want require and provide forms to be hard-wired so that
  they can be processed by external tools, would you extend this argument
  also to the definitions appearing with the body of the module?  If not,
  why not?  If there is useful information to be gleaned from the require
  and provide forms, there is surely even more useful information to be
  gleaned from the actual definitions.

Kent