[erlang-questions] Must and May convention

Richard Bowker <>
Thu Sep 28 16:43:32 CEST 2017

As Fred already said above, most of these flows are forms of the "Railway Oriented Programming" interpretation of Monads. i.e. do next step if ok, else shortcut to the end. the "with" concept in Elixir may be useful for comparison.

---  wrote:

From: zxq9 <>
To: Erlang <>
Subject: Re: [erlang-questions] Must and May convention
Date: Thu, 28 Sep 2017 23:35:49 +0900

On 2017年09月28日 木曜日 16:14:39 Joe Armstrong wrote:
> >   test2(F) ->
> >       F = parse(tokenize(ok(file:read_file()))).
> My problem with the above is I almost never write like this
> In my head I'm thinking "first you read the file then you tokenize it
> then you parse it"
> So pipes or breaking the code line by line with temporary variables
> is fine by me. Adding temporary variables is also nice because you
> can print them when things go wrong.

I absolutely agree with that. The only time I find heavy composition
readable is when you are casting from one form to another just to get
some utility from a particular representation, like pushing a set or
map into a list and back again.

When we need pipes I prefer to go to full-blown pipeline functions
instead of sugary composition operators. What I nearly always really
need is an assertion at each step, and that is why I am so strongly
in favor of the form:

    foo(Resource) ->
        {ok, Data} = get_stuff(Resource),
        {ok, Scrubbed} = scrub(Data),

If I see instead:

    foo(Resource) ->
        {ok, Data} = get_stuff(Resource),
        Scrubbed = scrub(Data),

I know straight away that scrub/1 is a pure function that crashes on
bad input. This is, of course, assuming the idiom that I laid out before.

erlang-questions mailing list


More information about the erlang-questions mailing list