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

Reply via email to