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