DEV Community: Brujo Benavides

Aaargh!! - Macros, Parse Transforms and others @ Erlang Battleground

Brujo Benavides — Mon, 10 Apr 2017 17:33:41 +0000

Not so long ago, John Hughes presented a module called Aaargh!! to the erlang-questions mailing list. He showed how parse transforms, macros and the Erlang compiler all worked together to mess up with us a bit. I’ll just present that very same story here. If you have read it already, you can safely skip the rest of the article.

The Weird Module

This is basically the module that John sent to the mailing list (I changed its name just so it’s easier to avoid the apostrophes)…

    -module(weird).

    -define(PLEASE_DONT).

    -ifdnef(PLEASE_DONT).
    -compile({parse_transform, undefined_parse_transform}).
    -endif.

The idea is that we first define the PLEASE_DONT macro in a line that we can later comment out if needed (or rather remove and define the macro at compile time).

Then, if the macro is not defined, we run the code through a parse transformation called undefined_parse_transform. The key point here is that this parse transformation module doesn’t exist, so this line should not compile.

But the macro is defined, so the parse transform should not be used, right?

    $ erlc weird.erl
    src/weird.erl: undefined parse transform 'undefined_parse_transform'

And My Macro?

Turns out that macro is not defined. As Alex points out in the mailing list…

there’s no one-argument define()

As you can see in the docs:

A macro is defined as follows:
-define(Const, Replacement).
-define(Func(Var1,...,VarN), Replacement).

If we change the define line in our code…

    -module(weird).

    -define(PLEASE_DONT, true).

    -ifndef(PLEASE_DONT).
    -compile({parse_transform, undefined_parse_transform}).
    -endif.

…it compiles perfectly:

    $ erlc weird.erl
    $ ls weird.beam
    weird.beam

Why didn’t you tell me so?

That’s it, right? Well… not so easy. If there is no one-argument define(), then why did the compiler/parser not warned us about it. Check this out:

    -module(weird).

    -define(PLEASE_DONT).

If we try to compile that module…

    $ erlc weird.erl
    src/weird.erl:3: badly formed 'define'

What’s going on here?

What we have here are two different kinds of compilation errors:

badly formed ‘define’ attributes
inexistent parse transformations

We only see one of them because they are found in different stages of the compilation process. To understand this a little bit better you’ll find a video of a talk by Richard Carlsson that deals with the compiler and its friends in a lot of detail below. But in a nutshell: For the parser, one-argument defines (or any other attribute declarations, for what is worth) are perfectly valid even when it does recognize macro definitions, but missing parse transformation modules are not. The compiler is the one that detects one-argument defines as errors. The parser is executed before the compiler and between those two, only the first one that finds an error, gets to shout about it ;)

That’s why when the define is broken, the parser ignores it and proceeds until it finds a missing parse transformation module and then it emits the error and stops the process. But when the parser finds no problems (i.e. there is no missing parse transformation module, in our case), then the compiler is executed, it finds the one-argument define and fails.

Bonus Track

After this whole conversation in erlang-question there was just one extra question in my mind:

If there’s no one-argument define(), what happens if I define a macro in the command line, then?

To test that, I created this module:

    -module(weird).

    -export([macro/0]).

    macro() -> ?THE_MACRO.

I can totally compile the module and specify a value for the macro on command line, like this:

    $ erlc -DTHE_MACRO=hello weird.erl
    $

If I try to use it in an Erlang shell, I get the following expected result:

    1> weird:macro().
    hello
    2>

Now, what happens if I don’t specify a value for the macro? The docs are a little vague in this area

-D
Defines a macro.

Let’s try ourselves, shall we?

    $ erlc -DTHE_MACRO weird.erl
    $

Since the module did compile, the Erlang compiler should’ve assigned a value to the macro, right? Let’s see what that value is…

    1> weird:macro().
    true
    2>

This article was originally published in Medium

Unbalanced Parentheses

Brujo Benavides — Wed, 05 Apr 2017 02:38:34 +0000

…or another reason not to use macros

This is an article about something I showed live at the Erlang & Elixir Factory San Francisco 2017. It’s about what you can and can not do if you are fancy with your module attributes in Erlang.

Notes

First of all, Federico: sorry for stealing your name. It was just too cool not to ;)
That said, here is the video of the whole talk, in case you want to watch it…

And if you prefer Spanish…

Ok, enough with the links! Let’s get down to business…

The Usual Suspects

This is a perfectly valid Erlang module:

    -module(my_mod).
    -export([whoami/0]).

    -spec whoami() -> atom().
    whoami() -> my_mod.

You can compile it and execute its function…

    1> c(my_mod).
    {ok,my_mod}
    2> my_mod:whoami().
    my_mod
    3>

This is also a perfectly valid Erlang module (now using a macro):

    -module(my_mod).
    -export([whoami/0]).

    -spec whoami() -> atom().
    whoami() -> ?MODULE.

As expected, same results…

    1> c(my_mod).
    {ok,my_mod}
    2> my_mod:whoami().
    my_mod
    3>

The Cool Guy

But… that spec attribute there has no parentheses around it. Can we also remove the parentheses around the other attributes? The docs are not very clear about that. They show the following general syntax for attributes:

-Tag(Value).

But then there are attributes like spec, type or callback that are shown without parentheses. So, why not give it a try? How much nicer would that export be without the parentheses around the brackets, right?

    -module my_mod.
    -export [whoami/0].

    -spec whoami() -> atom().
    whoami() -> my_mod.

It actually works!! Look at that…

    1> c(my_mod).
    {ok,my_mod}
    2> my_mod:whoami().
    my_mod
    3>

I’m not writing a parentheses there anymore!

Not so Fast, Cowboy!

Well… I’m not a fan of macros, but sometimes I end up using the predefined ones, like I did with ?MODULE *above…*

    -module my_mod.
    -export [whoami/0].

    -spec whoami() -> atom().
    whoami() -> ?MODULE.

Now if you try to compile that module, you’ll find quite an unexpected result…

    1> c(my_mod).
    my_mod.erl:5: 
    my_mod.erl:2: function whoami/0 undefined
    my_mod.erl:4: spec for undefined function whoami/0
    error

What’s going on here?

This time I literally have no clue. I can see that, in order to use the macro ?MODULE you have to use parentheses around your module name. But I haven’t done any research to find the root cause of it. That’s mostly because I have a very distinctive feeling that it will take me to the land of parsers, compilers, etc. and that’s a place I like to stay away from.

So, for this article, dear reader, if you are brave enough to go deep into the realm of the Erlang compiler and its friends and find out what’s going on, please let me know in the comments below.

And of course, if you can go ahead and fix this by sending a Pull Request to erlang/otp…

This article was first published in Erlang Battleground as Unbalanced Parentheses.

Hi, I'm Brujo Benavides

Brujo Benavides — Tue, 28 Mar 2017 16:24:29 +0000

I have been coding for 25 years.

You can find me everywhere (e.g. Twitter, Github, etc.) as @elbrujohalcon

I live in Buenos Aires, Argentina.

I'm Inaka's CTO and Erlang Solutions' Tech Lead and Erlang Trainer.

I mostly program in Erlang, but I am currently learning more about Elixir.

Nice to meet you.