[erlang-questions] Why doesn't Erlang has return statement?

[Jared Kofron]

On Tue Dec 16 2014 at 5:07:22 PM Alex Wilson <alex@REDACTED> wrote:

>
> > On 17 Dec 2014, at 10:31 am, aman mangal <mangalaman93@REDACTED> wrote:
> >
> > > Moreover, is there a good alternate to avoid nested case statements?
>

I think everybody would agree that there is a smell that comes from nested
case expressions, which shows up in the fact that idiomatic Erlang tends
toward lots of short functions.  It's kind of a non-answer, but I would say
replace a nested case with a function call.

I personally find that unlike in a language like C where having a ton of
functions can sometimes make things a little muddled, after working with
Erlang for a while matching inside a case and calling functions (which
generally means having a lot of functions) on the result is very natural,
and actually makes your code easier to follow, debug, and test.


> >
>
> You could consider something like a monad, perhaps. I know "monad" is a
> horrible functional programming word that makes people go "OMG THAT'S TOO
> HARD", but it's a pretty clean way to deal with errors sometimes.
>
> https://github.com/rabbitmq/erlando#do has an example of implementing
> do-notation for monads in Erlang using a parse-transform. The error monad
> example is kind of interesting.
>
> You can do the same thing without the parse-transform by having a function
> like this one:
>
> threaduntil([], Acc) -> Acc;
> threaduntil([Fun | Rest], Acc) ->
>         case Fun(Acc) of
>                 {error, E} -> {error, E};
>                 Acc1 -> threaduntil(Rest, Acc1)
>         end.
>
> So you call this with a list of funs, and whatever the output from one fun
> is, becomes the argument to the next one on the list, until either it
> reaches the end of the list (and returns the last return value), or one of
> the funs returns {error, _} -- then it short-circuits and returns the error
> straight away.
>
> It's not the lowest-overhead thing ever (making all those funs and
> executing them), but usually you see this kind of thing when dealing with
> i/o or high-level control logic that doesn't have to be the
> fastest-executing thing ever.
>
> I've used this pattern (and the erlando do-transform specifically) quite a
> lot to avoid chains of Thing1 = blah(Thing), Thing2 = foo(Thing1), Thing3 =
> bar(Thing2)... etc etc, and also to deal with situations where deeply
> nested errors need to produce a well-defined return value. I have a
> personal distaste for try/catch, so I prefer to choose between either
> crashing the process, or using this kind of approach.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141217/844f7ee3/attachment.htm>