[R6RS] Modules

[Manuel Serrano]

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.

Yes.

> > 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. 

-- 
Manuel