[R6RS] Modules

[Matthew Flatt]

At Wed, 3 Nov 2004 06:55:19 +0100, Manuel Serrano wrote:
> 1- get rid of the language parameter.
> 
> I really don't see the necessity of the language specification. As far
> as I understand, with the language argument, one should write:
> 
>    (module foo r6rs ...foobar...)
> 
> without it, he should write:
> 
>    (module foo (require r6rs) ..foobar...)
> 
> Is it really for saving 10 characters that we are introducing this 
> irregularity? 

No, but that's not what it's for. The reason to have a language
position is to have a place that binds `require', and to thus support
languages that do not provide `require'.

> 2- I really don't like the closing of the MODULE form. I don't like to
> put the definition inside the definition of the module. I would really
> push in favor of a form where the module only contains the require and
> provide forms, the definitions being written elsewhere. 

I prefer putting the module all in one set of parens, because it
integrates in an obvious way with a REPL and with a stream
representation of modules.

> iii- The solution B enables splitting a module across several files. 

As long as we have an `include' form, a module implementation can be in
multiple files, anyway.

> If you want a more "general" example, imagine a very old but very interesting
> Scheme source file "interesting.scm" implemented in Scheme R4Rs. Imagine now
> that with your favorite R6RS implementation you provide a backward 
> compatibility kit. Then, with solution B you could have two files:
> 
> -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
> file1.scm:
> (module very-interesting-r4rs-implementation (require r4rs)
>   (provide ...))
> 
> interesting.scm:
> <your very interesting r4rs code>

Or, if you have `include':

 (module very-interesting-r4rs-implementation r4rs+provide+include
   (provide ...)
   (include "interesting.scm"))
 
 interesting.scm:
 <your very interesting r4rs code>

> 3- I definitively think that we should not permit module definitions to
> contain module/file association. [...]
> In conclusion, the association module/file should NOT be specified in
> the language. It's up to the implementation to provide a mechanism for
> deciding the association. For a clause such as (require FOO) an implementation
> could decide that the module is located in the file FOO.scm, FOO.your-prefix,
> your-directory/FOO.your-prefix, ... It has nothing to do with the definition
> of the language itself.

This is fine with me, as long as a side name->file is *not* part of the
standard. Meanwhile, I suggest that we name modules with strings rather
than symbols.

(This is what I proposed in my revised strawman in September. When
libraries are distributed, we need to commit to a stream/file
representation of modules, but that's a distinct issue from the
mechanism for finding installed modules.)

> 4- change the semantics of the evaluation of the top level forms.
> [...]
> One step in this directory is to change a little bit the evaluation of
> the top-level forms. I would suggest that in the process of
> initializing modules, we specify that all the DEFINE forms are
> executed, in sequence, before the other top-level forms.

If this is an issue, I would rather just say that all definitions must
precede non-definitions.

> 5- add type exportations.

I still believe that this should be put into a library, but my opinion
relies on being able to write macros that expand to `provide'.


Matthew