On Tue, 13 Oct 2009 12:37:49 -0400, John Cowan <[email protected]> wrote:
> My current proposal on modules has an import form as a fixed part of
> the module form: it appears at the top, just after the export form and
> before the body. There is also import as a syntax keyword, used only
> at the top level. People have rightly argued that this is asymmetric
> and inflexible (though it is a bit more flexible than R6RS, which allows
> imports only at the top of top-level programs).
>
> On the other hand, it is discoverable: one can tell, simply by reading in
> a file containing one or more modules, what other modules are required.
> There is a trade-off between flexibility and discoverability that makes
> The Right Thing hard to discern, and this time the problem cannot be
> swept under the rug, for the Steering Committee has insisted that small
> Scheme have modules.
I have thought about this problem a little more, because I believe this is
going to be a very important issue to Scheme. The existing R6RS solution
is inadequate, and I have been hard pressed to figure out a solution with
which I would be satisfied. However, I believe I have come close, and I
would like to propose a counter-proposal to your approach, that I believe
has important benefits over your module system, and takes a different
approach to the solution.
<http://my.opera.com/arcfide/blog/2009/10/14/a-philosophy-on-scheme-modules>
> Here are some possible standpoints in the discoverability/flexibility
> tradeoff:
>
> 0) Imports only at the top of a module or the beginning of the top level.
> R6RS, but probably impossible for REPL-based semantics.
This makes life difficult for the syntactic module crowd.
> 1) Imports only at the top of a module, but anywhere in the top level.
> My current conservative proposal.
This also isn't general enough for useful syntactic modules.
> 2) Imports anywhere in a module or at the top level, but not embedded
> inside other forms, with the usual exception for begin.
>3) Imports or macros that expand into them only at the top of a module,
> but anywhere in the top level (but not embedded).
>
> 4) Imports or macros that expand into them anywhere, but not embedded.
>
> 5) Imports or macros that expand into them anywhere, including embedded
> in other forms.
>
> 3CE, 4CE, 5CE) Only cond-expand macros are allowed to expand into
> imports,
> not arbitrary user-written macros.
>
> Comments? Other ideas?
Whatever happens, I don't think Cond-expand should go into the standard,
and certainly no module system should be tied to it. As you'll see in my
proposal, macros should be syntactic in my opinion, and not because I
don't want discoverability.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
