On Tue, 2009-10-13 at 12:37 -0400, John Cowan wrote:
> 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.
> 1) Imports only at the top of a module, but anywhere in the top level.
> My current conservative proposal.
> 2) Imports anywhere in a module or at the top level, but not embedded
> inside other forms, with the usual exception for begin.
All three of these proposals require that modules have no flexibility
as to their requirements. It is necessary at times to write modules
that do things in different ways depending on what resources they have
available. If some module is unavailable, they load some other module
and do it a different way instead. If module imports are defined this
way then there is no way to specify importing one of several different
modules depending on what's available;
Therefore I don't think I could support any of these three proposals
as a viable mechanism for doing what we want to do.
> 3) Imports or macros that expand into them only at the top of a module,
> but anywhere in the top level (but not embedded).
I do not understand this. "macros that expand into imports" seems
like a good idea; such a macro could expand into one of several
different imports depending on availability. But "only at the top
but anywhere in the top level" seems like a contradiction to me, and
"not embedded" seems redundant with "top level". It makes me confused.
That said, if macros that expand into imports are allowed at
top level in a module, with a "reasonable" scope, that seems
like the minimum functionality required to have modules be
even a little bit flexible w/r/t their requirements. I would
expect no less than this from WG2 Scheme.
> 4) Imports or macros that expand into them anywhere, but not embedded.
Again, how is "not embedded" different in your terminology from "at top
level only?" When I read "anywhere but not embedded," I cannot imagine
how to avoid embedding an import in another form without putting it at
top level.
> 5) Imports or macros that expand into them anywhere, including embedded
> in other forms.
I think that this was what I proposed; import as a binding form with
lexical scope, usable anywhere a binding form may be used. Obviously,
I've already said I think it's the Right Thing. I would expect no
less than this from WG1 scheme.
> 3CE, 4CE, 5CE) Only cond-expand macros are allowed to expand into imports,
> not arbitrary user-written macros.
That is ... distasteful at best. The point being that you have to
process imports so that you will know what macros are in scope while
doing the rest of the macroexpansion, so you elevate cond-expand to
have an all-new before-macro-expansion expansion phase? I really
hate unnecessary phase distinctions and I don't think this one's
necessary.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
