Thu Nov 4 10:38:54 EST 2004
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"))
> <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:
(define-macro (module . -) #f)
(define (foo 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
> > 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?
More information about the R6RS