# [erlang-questions] chained functions

Jakob Praher <>
Wed Jan 25 14:29:20 CET 2012

```One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result.

apply_each([F|FS],X) ->
{S, V} = F(X),
if S = error  ->
{S, V}
S = ok ->
apply_each(FS, V);
end
.

{R, V} = apply_each([z,y,x], Arg).
if R = ok -> ...

I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct.

Cheers,
Jakob

Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong <> schrieb:

> I think you are asking the wrong question. If a function returns
> {ok,Val} | {error,Reason}
> then I think to myself "the caller of this function expects things to
> go wrong and is
> committed to handling *both* return values.
>
> So they would *never* write w(x(y(z(....))) because this does not cater for both
> return values.
>
> With the "let it crash" philosophy one would make w,x,y, .. return a
> value OR call exit(...).
> With this convention things do nest in the "happy" case without using
> a staircase.
>
> At the top level try or catch is used to catch the error.
>
> Alternatively you could say
>
>   ok({ok,X}) -> X;
>   ok{error,E}) -> exit(E).
>
> and then
>
>    w(ok(x(ok(y(ok(z(X))))))
>
> Not pretty but it does the job
>
> /Joe
>
>
> On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo
> <> wrote:
> >
> > A friend of mine asked:
> >
> > ##
> > If you have functions that return {ok, Result} | {error, Reason}
> > how do you chained them? So that you have:
> >
> > w(x(y(z(...))))
> >
> > without building a staircasing. Something that would be done in Haskell
> > ##
> >
> > I would probably go for:
> >
> > x({ok, Value}) ->
> >  NewValue = <do something with Value>,
> >  {ok, NewValue};
> > x({error, Reason}) ->
> >  {error, Reason}.
> >
> > in each function
> >
> > which brings me other question, when do you tag return values?
> >
> > I tend to only use tagged return values with impure functions, were an
> > error is more likely due to side effects.
> >
> > --
> > Reynaldo
> > _______________________________________________
> > erlang-questions mailing list
> >
> > http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
>
> http://erlang.org/mailman/listinfo/erlang-questions

```