[R6RS] Re: strawman module syntax

[Michael Sperber]

>>>>> "Kent" == R Kent Dybvig <dyb at cs.indiana.edu> writes:

Kent> 2. Treat both module and require (import) forms as definitions and
Kent>    allow them to appear anywhere where other definitions can appear.
Kent>    As with top-level definitions, top-level module forms may allow one
Kent>    to do things that don't make sense for internal module forms.  I
Kent>    see no harm in this.  Experience has shown that disallowing
Kent>    internal define-syntax was a bad idea; let's not repeat the mistake
Kent>    with modules.

While this may be a nice language design aspect, it fails to take into
account separate compilation and how pieces of code residing in
different files refer to each other while avoiding name conflicts.
(Matthew is arguing why things shouldn't expand into top-level MODULE
from another angle.)

Could you elaborate on this issue?

This generally is the recurring conflict in designing in this kind of
system---your proposal may make it hard to deduce early the
information the reader of a program, or a multi-phased compilation
system might need.  This is why I favor a separate configuration
language for top-level modules.  I'll also quote Richard Kelsey from

http://srfi.schemers.org/srfi-0/mail-archive/msg00020.html

(This is in the context of the SRFI-0 discussion, but it also applies
here.)

> - Both people and programs need to read the entire source to see
>   which SRFI's might be needed.  In the revised SRFI 0, ambiguities
>   can arise if an identifier appears before the IMPORT-IMPLEMENTATION
>   form that defines it.  Does the entire source have to be read
>   before evaluating the first form?  Does it all have to be macro
>   expanded before evaluating the first form?

(Replace "SRFI" by "IMPORT" to see how this is relevant to the present
discussion.)

As I argued earlier, I also think that the MzScheme/Scheme-48-style
module system is something different from what you suggest, and I
think that we're not doing the discussion a favor by insisting early
that they be the same.  If, in the end, our designs for both do end up
being the same, we can still merge them.

Kent> Thank you for the clarifications.  Unfortunately, I strongly dislike
Kent> several aspects of the proposed design.  One of Scheme's charms is that
Kent> 3 is a program, and not just in the interactive environment.  There's no
Kent> barrier to entry, no boilerplate stuff to stick on the top of or wrap
Kent> around each file.

But neither the design Matthew proposes nor mine precludes that---and
the email you followed up to contains a note on that.  (Or you can
just fire up MzScheme or Scheme 48 to see how a system addressing this
issue works in practice.)

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