[R6RS] Re: strawman module syntax

[Matthew Flatt]

At Fri, 09 Jul 2004 17:59:19 +0200, Michael Sperber wrote:
> Yes, but I'm not trying to solve the component problem here.  In the
> same sense as ld, MzScheme modules aren't good enough to solve the
> component problem---in fact, they're worse because they tie each
> import to a specific implementation, which I can't really replace
> within the framework.

MzScheme modules are also very bad at solving the "object" problem, the
"procedure" problem, or the "number" problem. They are not intended to
address any of those.

> I don't want a fundamentally different module system from what you
> propose.  In MzScheme-style modules, you say "I want *that*
> implementation" (via REQUIRE).  I'm only suggesting to change the
> notation to "I want the (*only*) implementation of *that*
> interface."

My claim is that half a solution to the component problem is not
worthwhile.

> - I think the program source code is the wrong place to tie the
>   modules of an application together.  This belongs to some loading
>   script or call to the compiler/linker frontend or whatever. 

You're not suggesting that every library needs a different script to
load it into different implementations, right?

In any case, I am very much opposed to this....

>   (I have
>   no fundamental argument here, but in my experience, such systems
>   just work better than the Java-style infrastructure.)

... based on the opposite experience.

I consider makefiles and project files to be the root of all evil when
it comes to sharing code. For example, I cringe whenever I have to add
a source file to MrEd, because I know that it's going to be very
painful to update the Visual Studio project files in a way that leaves
them usable by others.

Projects files, etc. really are languages --- stupid, ad hoc languages
that create no end of trouble for me. A *good* language will be
extensible. And so on.

In contrast, my experience is that Java works extremely well for
sharing code. I put a .jar file in the right place, and the library
always works, because the package system tells the run-time system how
to find the parts of the program.

(Again, Java's package system and class system are no substitute for a
component system, though people play games with the class loader to try
to make them work as components.)

> Now, units allow my to solve this problem, but they require me to
> answer the question "Will I ever want to use the piece of code I'm
> writing as a component?" NOW.  And in most cases, the answer is
> "maybe" aka "possibly yes."  Which requires me to write the code in a
> different way.

As we've discussed, I think that we can work toward a component
language that everyone will use by default, much as PLT Scheme
programmers use the `mzscheme' language by default.

I don't think we have it now, but I don't think we should wait for it,
either.

> I notice quite a few modules in the PLT distribution
> are written in this form, but it's hard to see how the decision was
> made in each case.

With rare exceptions, it's one of the following:

 - it was written before `module', and `unit' wasn't so painful, so we
   left the code in a `unit' while moving it into a `module';

 - it was written after `module', or `unit' was so painful that we
   removed the `unit' wrapper;

 - we want to put some mutually dependent code in separate compilation
   units.

(It turns out that "because we need it parameterized over its imports"
is the rare exception. Of course, when that does happen, we usually
discover it late, which points back to where we agree: that code should
be put into a component by default. But we don't yet have a good enough
component language to provide that default.)

> But aren't there two pieces to a component language:
> 
> 1. a language to define what a component is
> 2. a language to define how several components are assembled into a
>    collection/application whatever
> 
> For #2, I completely agree with you.  For #1, I have yet to see a
> language that fundamentally differs from:
> 
> - write down the names of the imported things
> - write down the names of the exported things
> - write down the implementation

ML. The ML component system is far more sophisticated about #1 than
anything else.

I believe that we can find a generalization to arbitrary first-order
data that will be perfect for Scheme --- but that takes us into
research, and far afield of a standard module system.

> Therefore, I'm advocating doing #1 for R6RS, but not #2.

I think I missed something here. It makes no sense to let people define
components in a portable way, but not define how they're assembled
portably. (Surely not every user of library X should manually assemble
the 173 private components of the library?)

> I guess I'm expecting, as a response to my argument, some argument
> why the pragmatic problem I described isn't so serious, or why it's
> solvable with MzScheme-style modules.

I agree that the problem is serious, even if it seems to happen less in
practice that I believed in 1998.

But, of course it can be solved with MzScheme-style modules, because
you can define any language through a module. In particular, if there
exists a component language for everyone to use, then you can define it
as a module-based language.

Matthew