[R6RS] Modules

[Manuel Serrano]

On Wed, 3 Nov 2004 05:56:36 -0700
Matthew Flatt <mflatt at cs.utah.edu> wrote:

> 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'.
There is something that I still don't understand. You suppose that
your interpreter/compiler knows enough about modules so that it knows
that a module is a list whose third element is a symbol representing a
module identifier that is actually required. You not going a step
further and state that your interpreter/compiler knows about r6rs modules!
I'm probably missing something here...


> > 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>
This is a solution, I agree. It is more or less equivalent to the Mike's 
(CODE ...) form. I don't like it very much it supposes that two files
are required for every modules. Unless one is allowed to right:

foo.scm:

-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
(module a-module
  (provide foo)
  (define-macro (module . -) #f)
  (include "foo.scm"))

(define (foo x)
   x)
-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----

Would this be correct? (provided that we allow non-r5rs macros, of course).
I'm just kidding, this is rather ugly.

I don't like very much the INCLUDE of CODE solution because it forces you
to right in FILENAME in your code. As I have said, I think that we should
avoid that.

> > 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.
I agree, name->file should not be in the standard. Hence I think that we can 
even keep 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.
That's fine with me.

> > 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'.
Being able to right macros that expand to PROVIDE is in contradiction 
with the Mike's proposal. However, I don't see how it is related to
exporting types. Could you elaborate on that?

-- 
Manuel