On Mon, 2009-10-12 at 00:31 -1000, Shiro Kawai wrote:
> If we want to import modules conditionally, we should either
> (1) make import form recognized after macro expansion, or
> (2) lift cond-expand to the module-level syntax. There are
> implementations that does (1)---e.g. Gauche does so. The
> drawback is that any meta program that wants to process
> module dependencies needs to do macro expansion.
> Choice (2) is technically possible, but I'm afraid that it
> makes module syntax spec bloated.
I think that the decision of making the import form a "meta"
form as you call it was an example of the Wrong Thing. Here
is why.
The fundamental form that binds identifiers is lambda. Even
top-level 'defines' are specified as having the semantics of
letrec*, which in turn is defined in terms of lambda.
Lambda is an expression, legal in any context where a general
expression can appear. It binds variables in a lexical scope
and can be used in any lexical scope, and this is a very
important part of scheme's consistent structure.
"import" as currently specc'ed is a binding construct that
can appear at top-level only and respects no lexical scope
other than that of the file. It cannot be used to bind
variables within a surrounding lexical scope. It cannot
be evaluated in places where other binding forms are legal
and therefore cannot be controlled by the conditionality
mechanisms (if, cond) already present in scheme.
And it therefore constitutes a binding mechanism that is
limited, restricted, and structurally inconsistent with the
way scheme otherwise handles binding mechanisms.
The current difficulty about conditional import of modules is
a consequence (and only the first of many consequences) of
this inconsistency. The two choices outlined above, and I'll
quote 'em here again for clarity:
> (1) make import form recognized after macro expansion, or
> (2) lift cond-expand to the module-level syntax.
can be restated as a case of
(1) Removing a restriction or limitation that has made
additional features appear necessary, or
(2) Piling feature upon feature to overcome a restriction
or limitation.
In the spirit of scheme, I would propose "import" as a binding
form that is fully part of the language, which can be used
wherever binding forms are legal and which establishes bindings
that respect the lexical scope in which the "import" form is
evaluated. And, yes, which is not limited or restricted by
requiring a "before macroexpansion" or "after macroexpansion"
condition.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss