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

[Robert Virding]

If you are implementing a 'cond' then there is one extension which is quite practical though it breaks the purity of cond. It is to add the possibility of having an explicit match in the test, not just whether it returns 'true' of 'false'. Also having any variables in the match accessible in the body. I don't really have a good suggestion for a syntax except perhaps to extend 'cond' tests with a "<pattern> = <expr>" option, or perhaps "<pattern> ?= <expr>". If the match fails then no error is generated and the next test is tried.

I added this to LFE and it is quite useful.

Something like this was discussed a while back as a general extension to guards but I can't remember the syntax. It would only allow approved guard expressions.

Robert


----- Original Message -----
> From: "Anthony Ramine" <n.oxyde@REDACTED>
> To: "Richard A. O'Keefe" <ok@REDACTED>
> Cc: erlang-questions@REDACTED
> Sent: Monday, 8 July, 2013 10:35:25 AM
> Subject: Re: [erlang-questions] style question - best way to test multiple	non-guard conditions sequentially
> 
> No this example was just confusing, what I meant is that if you need
> a warning "no clause will ever match" in the case of an explicit
> "case foobar of true -> ok; false -> ok end" and a warning "this
> clause will crash" in the case of "cond foobar -> ok; true -> ok
> end". There is no rewording that makes the warning fit in both
> situations, they need to be handled separately.
> 
> In my implementation I decided to annotate the Core Erlang cases to
> which a cond is compiled with the atom "cond_case".
> 
> --
> Anthony Ramine
> 
> Le 8 juil. 2013 à 08:22, "Richard A. O'Keefe" <ok@REDACTED> a
> écrit :
> 
> > 
> > On 8/07/2013, at 6:04 PM, Anthony Ramine wrote:
> > 
> >> With that logic, I see no reason to make if G -> B end different
> >> from case {} of {} when G -> B end.
> > 
> > Neither do I.  It is excess complexity that we really don't need,
> > and it inhibits a range of source-to-source transformations that
> > ought not to be inhibited.
> > 
> > If I am told which *function clause* a selection failure is in,
> > better still, if I am told which *line* it is in, no distinction
> > between if/case/cond in exceptions is of any real help.  The
> > *only* time it is helpful is when you have one 'if' and one 'case'.
> > Have *two* 'if's or *two* 'case's, and it's useless.
> > 
> >> 
> >> 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".
> > 
> > You have presented a good argument for rewording the error message.
> > 
> > That's all.
> > 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>