[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

Robert Virding robert.virding@REDACTED
Mon Jul 15 13:39:56 CEST 2013


Sorry for getting in this discussion late, on holidays.

Just an historical curiosity. Before we had 'if' and we needed something if-ish this is exactly what we would do. We would use a case with a trivial expression and clause patterns which would always match and all the work was done in the guards. It looked so horrific that we added 'if'.

Robert

----- Original Message -----
> From: "Anthony Ramine" <n.oxyde@REDACTED>
> To: ok@REDACTED
> Cc: erlang-questions@REDACTED
> Sent: Monday, 8 July, 2013 8:04:34 AM
> Subject: Re: [erlang-questions] style question - best way to test multiple	non-guard conditions sequentially
> 
> With that logic, I see no reason to make if G -> B end different from
> case {} of {} when G -> B end.
> 
> Expanding cond to nested cases earlier in the compilation would mean
> confusing and misguided warning, e.g. "cond foobar -> ok end" would
> trigger the warning "no clause will ever match"; instead of the
> clearer "this clause will crash".
> 
> --
> Anthony Ramine
> 
> Le 8 juil. 2013 à 00:04, ok@REDACTED a écrit :
> 
> > 
> >> I couldn't decide which error should be thrown when the cond test
> >> doesn't
> >> return a boolean but I have found some references to cond
> >> expressions in
> >> an old paper [2] (page 37) and decided to stick to their choices.
> > 
> > To be honest, I couldn't see any good reason to make
> >    cond E1 -> B1 ; ... ; En -> Bn end
> > any different from
> >    case E1 of true -> B1 ; false ->
> >    ...
> >    case En of true -> Bn
> >    end
> >    ...
> >    end
> > I see great virtue in there being *no* difference whatsoever
> > in the semantics of the two, so that the choice is *solely*
> > stylistic and rewriting one into the other (either way) *cannot*
> > break a working program.
> > 
> > Having looked at that reference, I do not see any advantage for
> > the more complicated version.  As long as you can find out
> > *where* the error was, it just isn't _useful_ to know 'it was a
> > cond' rather than 'it was a case'; a program catching errors
> > would never want to treat them differently, and a human who has
> > been told _where_ can instantly see _what_.
> > 
> > 
> > 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 



More information about the erlang-questions mailing list