I’ve been struck by the emergent elegance of Elixir’s scoping rules.
In my native Ruby,
extend is a scattershot affair. You can do it within an individual method, but it applies to the entire module:
In Elixir, on the other hand, an
alias) inside a function only applies within that function. It actually goes further than that: if it happens inside a logic branch (in e.g. an
case) it only applies within that branch.
And it’s from this simple fact that the elegance emerges.
A few days ago, I saw this code example:
It would be nice to get rid of the noise of that repetition.
import will do it, within our current scope only, without spilling into other code:
with statement. We could very easily implement a
with-alike in Elixir:
In the macro, we create and then immediately call an anonymous function, to limit the scope of the
We could also limit the scope with a dummy conditional, but this comes with a higher WTF factor:
Note that the macro function definition and the
quote do … end block on their own would not limit the scope of the
import, because they are part of the macro infrastructure. They generate some code and then effectively disappear from the scoping hierarchy.
Also note that Elixir may be gaining something else called
with in the future, so if you start using the above, don’t get attached to the name…
instance_eval for a more civilized age
When I started out learning Elixir, I found myself wanting to understand how things like Ecto migrations work. So I painstakingly reimplemented the interesting parts of the syntax.
Let’s say we want to support this:
In my first implementation, I had an
add function that you could call inside that block… and anywhere else as well. I wanted to do better.
In Ruby, I would have used
instance_eval to evaluate a block of code in a context that has an
add method available.
By consulting the mailing list, the elegance of Elixir scoping was finally revealed to me.
Of course, the solution was simply to
import a module in a limited scope, just like
If you’re interested, you can see the implementation as a Gist.
Overriding operators locally
Another elegant effect is that you can override operators within a single function, or a single logic branch.
The Pipespect library replaces the regular
|> with one that inspects every intermediate value.
Its implementation is all about
imports, so the scoping rules are the same ones that we discussed above:
Out of scope
That’s it. Any other interesting implications of the Elixir scoping rules? Let me know in the comments or on Twitter!
For some related reading, also see “The Value of Explicitness” by Drew Olson.