[R6RS] Re: strawman module syntax

[Michael Sperber]

>>>>> "Matthew" == Matthew Flatt <mflatt at cs.utah.edu> writes:

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

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.  (Unless I break your rules.)

This is where the continuing misunderstanding lies.  I'm obviously
not explaining myself well.  I'll try again.

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

There are two reasons:

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

- In the distant future, we may want to introduce a component system
  into Scheme (or an implementation might want to do that earlier),
  and then it will be desirable to use some of code written in module
  form written up to that point and convert it into components
  easily.  MzScheme-style modules don't really work for that scenario
  because they don't contain enough information.

I'm really just trying to solve the type of pragmatic problem
described earlier:  How do I link my program against a variant of
library X?

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.  (I.e. stuff everything into a unit first, then export
into a module.)  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.  If the answer is "maybe" most of the time, I might
as well write things down in that way all the time.

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

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

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

(I haven't conducted an exhaustive search.  Certainly, C works this
way, units work this way, and Richard-style modules work this way.)

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

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.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla