Three wishes

[Thomas Lindgren]

--- Roger Price <rprice@REDACTED> wrote:

> I would
> like an option which supresses this scope extrusion,
> and makes the
> variables introduced within an if, case or receive
> unknown outside.  

It's easy enough to provide, e.g., transform each
SwitchExpr construct above into:

(fun() -> SwitchExpr end)()

Having this as an optional parse transform would be
okay with me, even though I probably wouldn't bother
to use it. (The warnings you get when you export
variables out of case/if/receive is enough, thanks :-)

> I
> would also like this option to be the default
> compiler behaviour.  

I suspect actually breaking code that uses the old
convention would be too radical though ...

> The
> current scope extrusion is counter-intuitive, and
> adds unwanted
> complexity.  Is there any case in which it is a
> "must have"?

That depends on your intuition, I guess.

I'll agree that the current scoping rules add some
complexity, at least for compilers and code
processors. On the other hand, the underlying problem
remains after you've made your restriction. You can
still write:

X = f(Y=g(A), Z=h(B))

and as a consequence have X, Y and Z bound after the
call. (Basically, an Erlang expression returns a value
and a new environment, not just a value.)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com