Wed Nov 3 07:57:03 EST 2004
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
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:
> (module very-interesting-r4rs-implementation (require r4rs)
> (provide ...))
> <your very interesting r4rs code>
Or, if you have `include':
(module very-interesting-r4rs-implementation r4rs+provide+include
<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
(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
> 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'.
More information about the R6RS