[R6RS] Re: strawman module syntax

[Matthew Flatt]

At Thu, 08 Jul 2004 18:11:22 +0200, Michael Sperber wrote:
> >>>>> "Matthew" == Matthew Flatt <mflatt at cs.utah.edu> writes:
> 
> Matthew> Meanwhile, a programmer writing completely unportable code (in the
> Matthew> sense of "doesn't port to any other filesystem, much less OS") might
> Matthew> want to break away from the Unix conventions --- maybe to specify a
> Matthew> drive in Windows, or a file whose name contains "/" in old Mac OS.
> 
> OK.  Do we have to provide for this possibility in the standard then?

Ah, probably not. Good point.

> >> - In MzScheme, I really hate the restriction that, in the language
> >>   designation, I can only put a <require> and not a <require-spec>.
> >>   Matthew---could you expand on why this is so?
> 
> Matthew> http://list.cs.brown.edu/pipermail/plt-scheme/2003-
> December/004375.html
> 
> OK, that ties in with your position below, i.e., that you
> can't macro-expand into the language designation, right?

Yes, I suppose it does.

> >>   To make a long story short: I think that module *interfaces*, not
> >>   definitions should have globally unique meanings, and that the
> >>   implementation for any given interface should be determined at
> >>   compile/link time.  This would mirror the way cc/ld works, and I
> >>   think it's the way to go.
> 
> Matthew> In case there's any doubt that I still disagree, I stand by
> Matthew> my previous claims:
> 
> Matthew>    http://www.cs.utah.edu/flux/papers/knit-osdi00.pdf
> Matthew>    http://www.ccs.neu.edu/scheme/pubs/pldi98-ff.ps.gz
> Matthew>    http://www.ccs.neu.edu/scheme/pubs/thesis-flatt.ps.gz
> 
> I think I understand what you're saying in these papers, but I don't
> understand where exactly the disagreement is (as far as I can see, I'm
> pretty firmly in your camp, but you're saying that impression is
> wrong)---there's something I'm missing.  Could you elaborate?

The Knit paper is specifically about how ld isn't good enough, and the
main problem is having only one implementation of a given interface.

For truly reusable components, a program must be able to include
multiple implementations of a given interface, so that different
components can be linked to different implementations. A programmer
therefore has to choose explicitly how things are linked. So it gets a
bit complicated, right from the start.

In principle, I would be happy with a language where components and are
the only top-level entities. The problem is that components are too
complex; it's not obvious what the syntax should be, and different
tasks may well need variations. In other words, we do not have the One
True Language for components, and I suspect that it doesn't exist.

Schemers know the way around the One True Language problem, of course.
Components systems should be defined within a macro-extensible context.

> Matthew> In general, this points to the reason that I advocate only
> Matthew> `module' at the top level. The top level isn't extensible (no
> Matthew> macros can expand to top-level `module')
> 
> I see why this is so in MzScheme

Actually, it isn't --- but I'm happy that you think that macros can't
expand to `module'. When a programmer does anything outside of `module'
in PLT Scheme, things stop working in a reasonable way. (It's
well-defined, of course, just very difficult to reasonable about.)

The `module' I had in mind was the top-level `module' in a
specification of portable Scheme.

> but I don't see why it *has* to be so. [...] Wouldn't it be better to
> leave this degree of freedom to the implementor?

As you say, if an implementor wants to support a kind of top-level
outside modules, that's fine. Or if `module' is implemented by macro
expansion to something else, so be it.

The only question is how programmers write and distribute portable
code. If the top-level language is so complex that programmers need to
write macros to generate top-level forms, then we haven't gotten
anywhere.


Marc's message from a few weeks ago was more the way to think about
MzScheme's `module' than anything to do with components. Marc wanted
something outside Chez-style `module' to manage things at the file
level --- and that's exactly what MzScheme's `module' is for. It's not
supposed to do any more, and it's certainly not rich enough for
expressing components. But it provides a framework for writing
components (as many as you like! with whatever interface specification
you like!) within a file.

Perhaps Scheme needs a standard component system, just like it needs a
standard "procedure system". But, like the already-established
procedure system, I think it's something that belongs inside `module'
instead of outside, and it's otherwise orthogonal to the module system.

Matthew