[erlang-questions] Must and May convention

Richard Bowker erlang@REDACTED
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.

--- zxq9@REDACTED wrote:

From: zxq9 <zxq9@REDACTED>
To: Erlang <erlang-questions@REDACTED>
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),
        process_important_value(Scrubbed).

If I see instead:

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

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.

-Craig
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list