[R6RS] Modules

Manuel Serrano Manuel.Serrano
Wed Nov 10 05:52:54 EST 2004

First of all excuse me for my awful typing. I was probably too much
tired when I wrote this mail...

at Thu, 4 Nov 2004 08:51:06 -0700, Matthew wrote:
> At Thu, 4 Nov 2004 16:26:51 +0100, Manuel Serrano wrote:
> > 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.
> That's true.
> > You not going a step
> > further and state that your interpreter/compiler knows about r6rs modules!
> I'm not sure what you mean. I'm imaging that the interpreter/compiler
> knows about the `module' form, but it makes no assumption about the
> bindings in the `module' body after the language declaration.
What I mean here is that I find pretty artificial to suppose the 
compiler/interpreter knows a little bit about a module declaration but
not all of it. It knows that it is a list, it knows its shape, it knows
that a module is required, that its name is a symbol located at the third
position in the module declaration. It simply does about REQUIRE. I think
that this is artificial.

> > > 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.
> Well, I have in mind that `include' is a form that you can put in any
> expression or definition context, and it gets replaced with the content
> of the file. So you wouldn't have to use a separate file.
Hum, I don't understand here. If we assume that the module is located
in a file interesting.bgl, you hence have two files. No? Am I wrong?

> > 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.
> Ok, we fundamentally disagree on this one.
I'm afraid that we do.

> > 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?
> A library could provide a new `provide' form that supports type
> declarations. An implementation of the library might expand to the R6RS
> `provide' and simply drop the type information. The Bigloo
> implementation of the library would ensure that the type information
> gets to the compiler.
> This is probably a moot point, because I don't think we're going to
> agree on a system where a macro can expand to `provide'.
I see your point now but I'm a little bit concern with your argument. If we
think that a module feature X (such as providing type information in PROVIDE 
clause or any extra annotation) is good from a software engineering point
of view, I don't think that it is enough to say that a system S
can re-define PROVIDE or REQUIRE so that its implementation enables X. 
I think that we should go the other way around. That is, if we consider that 
X is good we should encourage people to use it. The best way to do this is 
to standardize a way to talk about it, and taking care to design something
that some implementations can ignore (imagine, for instance, an
"inline" annotation that could be safely ignored).

at Thu, 4 Nov 2004 12:26:34 -0500 Marc wrote:
> > Ok, we fundamentally disagree on this one.
> I agree with Manuel here.  When filenames are placed in the module,
> the module becomes dependent on the filesystem and where the modules
> are placed and also the filename syntax of the operating system.  This
> goes against the principle of modularity.  I would like people to
> share modules without having to change the filenames in the module to
> suit local filesystem structuring conventions or the structure of the
> system in which they want to use this module.
Yes, that's it. More prosaically I would also add that I would like to
be able to rename files, without changing the code.

> This is why in Snowbird I said we should only allow symbolic names for
> modules, and rely on some mechanism outside of the module to indicate
I definitively agree on that.

> how these symbolic names get mapped to files (or URLs, or ...).  There
> are several possibilities:
> 1) A standard search algorithm, e.g. look in the current directory for
>    a file with the same filename as the module name plus a standard
>    extension (you could use symbolic links to implement a more complex
>    mapping) and if that file does not exist then look in SPAN.
> 2) The mapping is specified to the compiler in a configuration file
>    (either specified explicitly on the compiler's command line or, if
>    none is specified, then in a file in the same directory with a
>    standard name, such as "config.scm").
> 3) A file of code implicitly starts with an (include "config.scm"),
>    if config.scm exists.  If we also have a module indirection
>    form like (module foo "/usr/share/scheme/foo.scm") which indicates
>    in which file the module foo resides, then the config.scm file could
>    contain a set of module indirection forms.
We should leave this out of the R6Rs. This is an implementation issue that
should only rely on implementations only. 


More information about the R6RS mailing list