[R6RS] Modules

[Michael Sperber]

I've attached a---from my point of view---minimal revision of Kent's
proposal to make me happy.  Manuel and, I think, Richard, agree with
the changes and their rationale, but may want to make more changes.
There are some notes (specifically some marked "KENT") and some
unresolved issues.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
-------------- next part --------------
Rationale:

This proposal is based on Kent's presentation in Snowbird.  It is
supposed to represent a set of minimal modifications to make Mike
happy.  The important difference is that the module definition
language is completely separate from the core language used to define
the module body.  This makes the module definition language
intentially non-extensible, which in turn enables:

- a human-accessible process for looking where an identifier comes
  from, construct a dependency graph, and so on
  (This is the main point.)

- writing of simple tools to construct the dependency graph, perform
  make, etc.

- later extensions to support module bodies written in other
  languages, other read syntaxes, etc.

Minor changes to Kent's proposal:

- Either it should be "require" and "provide" or "requires" and
  "provides," not a mix, I think.  KENT: was the mix in your proposal
  on purpose?

- I replaced "name" by "<identifier>" in accordance with R5RS.  (KENT:
  Or is the difference intentional?)

- I added the <require-modifier> clause for more fine-grained control
  over requires; these are taken from the Scheme 48 module system.

- Treating the "initial language" specially isn't necessary in a
  separate configuration language---it can just be a regular import.

Unresolved issues:

- syntax of <path-name> / standard file layout

- provisions for more efficient module initialization

Module specification language:
==============================

<library> -> <module-form>*

<module-form> -> (MODULE <module-name> <body-form>*)

<language> -> <module-spec>

<body-form> -> <require-form> | <provide-form> | <code-form>

<require-form> -> (REQUIRE <require-spec>*)
<require-spec> -> <module-spec>
                | (<module-name> FROM <path-name>)
                | (ONLY <module-spec> <identifier>*)
                | (WITH-PREFIX <module-spec> <identifier>)
                | (MODIFY <module-spec> <require-modifier>*)
<require-modifier> -> (EXPOSE <identifier>*)
                    | (HIDE <identifier>*)
                    | (RENAME (<identifier> <identifier>)*)
                    | (ALIAS (<identifier> <identifier>)*)
                    | (PREFIX (<identifier>)

<provide-form> -> (PROVIDE <provide-spec>*)
<provide-spec> -> <identifier>
                | (<identifier> :SYNTAX) 

<code-form> -> (CODE <command or definition>+)
             | (FILE <path-name>)

<provide-form> -> (PROVIDE <provide-spec>*)

Module linking language
=======================

This will be left implementation-specific by R6RS.  A future revision
of the Scheme standard may provide a standard linking language.

R6RS should probably specify some kind of standard file layout or
distribution format that will assign module definitions to module
names.

Core language
=============

A DEFINE-SYNTAX form may carry an additional specification of the
implicit imports of the syntax transformer.  If it isn't present, all
global bindings of a module (or some other approximation to the
implicit exports) might be implicitly exported.

<syntax-definition> -> (DEFINE-SYNTAX <keyword> <transformer spec> <implicit exports>?)

<implicit exports> -> (<identifier>*)

NOTE: I'm not sure one should be able to leave out the <implicit
      exports> part in general---but at least for SYNTAX-RULES, it
      should be possible.

NOTE: Should the implicit syntax exports be specially marked, just
      like the regular exports?