[R6RS] Re: strawman module syntax

[Matthew Flatt]

At Sat, 10 Jul 2004 12:43:35 +0200, Michael Sperber wrote:
> Matthew> You're not suggesting that every library needs a different script to
> Matthew> load it into different implementations, right?
> 
> While, like you, I would like the "script" to be the same, I don't
> think this is very realistic. 

So a Scheme program can never really be portable?

> There's just too much variety in the way Scheme systems work---an
> interactive environment, to-C compilers, incremental compilers, what
> have you.

In my view, this is precisely *the* problem for R6RS. Nothing else
matters in comparison.

PLT Scheme is a microcosm of the problem. MzScheme, DrScheme, mzc, mzc
--exe, and Check Syntax all manipulate a program in very different
ways, and prior to `module', we were not able to make these tools work
consistently. But `module' was specifically designed to solve this
problem, and it has.

Indeed, the success of `module' within PLT Scheme --- to make all of
our tools work consistently --- is the only reason that I [used to]
think I have anything to offer R6RS.

But you already know all that. Can you be more specific about what
could go wrong --- maybe a specific scenario?

> Matthew> But, of course it can be solved with MzScheme-style modules,
> Matthew> because you can define any language through a module. In
> Matthew> particular, if there exists a component language for everyone
> Matthew> to use, then you can define it as a module-based language.
> 
> Would you think we could formulate that as a goal for R6RS?  (Even if
> that requires a novel design.)

I worry about trying to standardize a novel design, because standards
are not meant for novelty. Someone needs experience with an
implementation, first.

Meanwhile, I'm not opposed to standardize something that is only a
partial solution for components. As long as it's inside `module', then
it can be replaced portably, at any time, as we find more complete
solutions.

> Matthew> I believe that we can find a generalization to arbitrary
> Matthew> first-order data that will be perfect for Scheme --- but that
> Matthew> takes us into research, and far afield of a standard module
> Matthew> system.
> 
> Side issue: Does this mean the component system you envision will be
> about data only, not syntax?

I count macros as "first-order data". The expansion half goes in the
signature, and the run-time half (free variables in the template) go in
the implementation. (This is like Alan's "First-Class Macros have
Type", though I think he muddied terminology with the phrase
"first-class macros".)

> Also, there are other aspects about the proposal I posted---could you
> comment on those?

I've commented on the places where I strongly disagree, I think, so
other things seem fine.

Matthew