[R6RS] modules

[Michael Sperber]

"But, but, but, ... what about ME!?"

I guess I'm a bit disappointed that you didn't take up any (that I
could see) of my arguments in the thread between Matthew and myself.

Before I get into more long-winded arguments, I'd like to suggest at
least one ground rule in the discussion, namely that features or
specific properties of any proposal have some kind of rationale as
well as some examples of their specific use.

Now, assuming this ground rule, here are the most important highlights
I'm still in the dark as to rationale and specific use:

- I still fail to see why the top-level module system and the
  local-scope one should be the same.

- In fact, nobody has introduced a specific rationale for a
  local-scope module system at all---Matthew asked for examples ages
  ago, but never got any.

[Personally, I think I believe that a local-scope module system is
useful, but I think it shouldn't be the same as the top-level one.]

Now, I believe Richard, Manuel and I have presented rationales for:

- separate interfaces

- a module language that isn't conflated with the regular language

- allowing several module definitions in one file

Could you guys respond to these?

Let me re-iterate that I think it's a bad idea procedurally to merge
the top-level and the local-scope module system first, and immediately
try hammer out a common proposal.  I think it would be much better to
design them independently and then see if the commonalities justify
conflating them.

The same issue holds for a component system: I understand Matthew's
arguments as to why the top-level module system shouldn't be a
component system, and (I believe) Matthew understands my desire for
the (possibly eventual) need of a component system.  This also seems
to suggest that it would be good to make separate designs first, and
look for commonalities after.

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