inaka

Latest blog entries

/
Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
See all Inaka's blog posts >>

/
Metaprogramming in Erlang: Writing a partial application function

Hernán Rivas Acosta wrote this on October 14, 2014 under erlang, inaka .

Wouldn't it be beautiful if this worked?

> Atomize = lists:map(fun(X)->
                        list_to_atom(X)
                      end).
> Atomize(["this", "is", "fantastic"]).
[this, is, fantastic]

Unfortunately it doesn't (and for some very good reasons), and even if you fix it and remove the ambiguity specifying the arity of the function (since that is the reason the syntax could not allow it in the first place):

Atomize = lists:map/2(fun(X) ->
                        list_to_atom(X)
                      end).

Still won't work.

So there surely is an erlang:partial_application or similar function that allows such a thing? Well, the answer is no and though you can simulate this with a lambda, it's nowhere near as elegant.

Now, I stumbled with this problem for quite a while because it seems that either the things I do at Inaka tend to call for partial application or I simply had been thinking about this shortcoming so much it affected my programming fu.

So it was time to put the issue to rest. First of all, creating a function with an arbitrary number of parameters is a no-no but I can write whatever string I feel like and (in theory) parse it as Erlang code.

So lets start with that, go to the erl_scan documentation and take a look, I'll wait.

Done? Excellent, you might have noticed that you can tokenize strings with it using the aptly named string/1 function. But what are this tokens I hear you asking? Well, that's just the first step, what we really are after is something called abstract format, that is, the parse tree of an Erlang program represented in Erlang terms (which is a rather long way of saying it's your code represented as tuples). You might recognize this abstract format if you ever played around with parse transforms or if you looked at Elvis's code.

So how do we go from tokens to this? Well, using another module most of us ignore, erl_parse. Don't worry, I won't ask you to read the docs this time, there is a single function we want: parse_exprs/1. This function receives the tokens we were discussing before and turns them into an abstract form.

Now, let's see an example of this:

> {ok, Scan, _} = erl_scan:string(
  "MultiplyByTwo = fun(X) -> X * 2 end.").
{ok,[{var,1,'MultiplyByTwo'},
     {'=',1},
     {'fun',1},
     {'(',1},
     {var,1,'X'},
     {')',1},
     {'->',1},
     {var,1,'X'},
     {'*',1},
     {integer,1,2},
     {'end',1},
     {dot,1}],
    1}
> {ok, AbstForm} = erl_parse:parse_exprs(Scan).
{ok,[{match,1,
      {var,1,'MultiplyByTwo'},
      {'fun',1,
       {clauses,[{clause,1,
                  [{var,1,'X'}],
                  [],
                  [{op,
                    1,
                    '*',
                    {var,1,'X'},
                    {integer,1,2}}]}]}}}]}

Interesting! Also, from this we can get a pretty good idea of how to write a function in abstract format directly, saving a costly parsing step.

So what do we do with this abstract format? We evaluate it of course! erl_eval:exprs/2 does this and also allows us to bind certain variables meaning we will be able to pass the parameters we want to "fix" to the function we want the partial application from.

This is the code to do so, note how we are calling erl_parse:abstract/1 on each of the parameters, converting a 1 into {integer, 0, 1} and so on, this is required to make a proper abstract format expression:

partial(F, FixedArgs) ->
  {arity, Arity} = erlang:fun_info(F, arity),
  case length(FixedArgs) of
    L when L < Arity ->
      Args = [{var, 1, N} ||
              N <- lists:seq(1, Arity - L)],
      Parsed = [{'fun', 1,
                 {clauses,
                  [{clause, 1,
                    Args,
                    [],
                    [{call, 1,
                      {var, 1, 'F'},
                      [erl_parse:abstract(A)
                       || A <- FixedArgs] ++
                      Args}]}]}}],
      {_, R, _} = erl_eval:exprs(Parsed,
                                 [{'F', F}]),
      R
  end.

Basically we are creating a function with N parameters (where N is the number of parameters of the original function minus the length of the fixed parameters) that calls a single function 'F' that we later bind with the fixed parameters plus whatever the outer function receives. Also if you read carefully, we are using integers as parameter names on the function, this is a clever way to save space in the source but might not be supported in future versions, who cares? You are not going to use this in production code anyway... Right?

Still, there is a caveat here, erl_parse:abstract/1 can't handle funs (the reason for this is left as an excercise for the reader), so we need to add another trick for it. This does make the code less readable and is the reason I wanted to show the straightforward example first.

partial(F, FixedArgs) ->
  {arity, Arity} = erlang:fun_info(F, arity),
  case length(FixedArgs) of
    L when L < Arity ->
      Args = [{var, 1, N} ||
              N <- lists:seq(1, Arity - L)],
      FArgs = [case is_function(A) of
                false -> erl_parse:abstract(A);
                true -> {var,
                         1,
                         erlang:fun_to_list(A)}
              end || A <- FixedArgs],
      Parsed = [{'fun', 1,
                 {clauses,
                  [{clause, 1, Args, [],
                    [{call, 1,
                      {var, 1, 'F'},
                      FArgs ++ Args}]}]}}],
      Binds = [{erlang:fun_to_list(A), A} ||
               A <- FixedArgs, is_function(A)],
      {_, R, _} = erl_eval:exprs(Parsed,
                                 [{'F', F}] ++
                                 Binds),
      R
  end.

What are we doing here? Well, remember when I said you can use whatever you want as a parameter name? For every fun we receive as an argument we use the fun name (or whatever it is that erlang:fun_to_list/1 returns) as the parameter name, and then pass the funs as binds when calling erl_eval:exprs/2.

Et voilà!

> Atomizer =
    partial(fun lists:map/2,
            [fun erlang:list_to_atom/1]).
#Fun<erl_eval.6.90072148>
> Atomizer(["erlang", "is", "da", "bomb"]).
[erlang,is,da,bomb]

So why not using this beauty in production? Well, it's hacky, we have no guarantees on the support this is going to get and usually there are other alternatives, still, it's always fun to play around with the limits of the language.

Happy hacking!