[e-lang] Scope restriction on Macros

Brandon Moore brandonm at yahoo-inc.com
Wed Sep 27 20:29:06 CDT 2006


Thinking about scoping, I reviewed the note on E macros at
http://www.erights.org/data/irrelevance.html

I don't see exactly what restriction is being proposed. I'm wondering 
whether desugaring
let x = exp in exp2
to
(fun x {exp2}) (exp)
is an error even if exp doesn't actually mention x. It's a mismatch if 
you compare the actual set of bindings in effect at each expression, but 
not if you only look at what binds the variables that actually appear in 
the code. I'd recommend the latter, if that isn't already what you 
meant. Perhaps you could improve on this a bit, by letting the macro 
explicitly declare that the binders from some pattern shouldn't be 
mentioned at all in a particular expression, and provide a more specific 
error message when things go wrong. This reminds me a bit of IF logic:
http://planetmath.org/encyclopedia/IFLogic.html

On to other things:

(I'd like to note that Haskell follows a left-to-right binding order in 
the case of lets, because it does let a name scope over its own 
definition, and relies on lazy evaluation to sort it out.)

The thinking about scoping I was doing concerned using lambdas and 
ordinary functions to emulate/provide simple scope-building sugar.
As a quick example, for loops could be used as:

 foreach [0..3] \x ->
   foreach [0..5] \y -> do
     ... stuff with x,y ...
 
("\var1 var2 .. varN -> body" is Haskell for lambda, and
 "do" introduces a block of statements)

In this style, scope introducing things are called like
scoper some arguments \ things getting bound ->
  body

I think Ruby has some similar notation around blocks.

Maybe it's worth including some syntax like this to make it easy to 
provide simple scope-handling things, and to provide a uniform 
appearance for those things.

(It does work especially nicely in Haskell because using monads to 
control side effects means ordinary can decide if, when, and how often 
the side effects of evaluating their arguments occur).

Brandon


More information about the e-lang mailing list