[erlang-questions] style question - best way to test multiple non-guard conditions sequentially
Thu Dec 26 03:57:27 CET 2013
One way around this problem is to handle '=' specially if it at the "top-level" in the test and not compile it naively. You would then say that variables occurring in the pattern would follow the same scoping rules as variables in if/case/receive clauses: if they are bound in all clauses then they are exported otherwise they are only bound in that clause. To do it that way also makes the translation simple. Your case could become:
case false of
X -> X;
case true of
X -> true
In this case there would be no badmatch and X would be exported. If the match fails the next clause tried.
If users explicitly use '=' deep in their expressions then they are on their own, cond only handles at the top-level. Even with this limitation cond would be useful.
----- Original Message -----
> From: "Anthony Ramine" <n.oxyde@REDACTED>
> To: "Richard Carlsson" <carlsson.richard@REDACTED>
> Cc: "Jonathan Leivent" <jleivent@REDACTED>, erlang-questions@REDACTED
> Sent: Monday, 16 December, 2013 12:00:35 PM
> Subject: Re: [erlang-questions] style question - best way to test multiple non-guard conditions sequentially
> That should have been « it’s not finished yet ».
> Anthony Ramine
> Le 16 déc. 2013 à 11:56, Anthony Ramine <n.oxyde@REDACTED> a écrit :
> > It’s done finished yet, but I’m on it:
> > https://github.com/nox/otp/tree/cond
> > --
> > Anthony Ramine
> > Le 16 déc. 2013 à 11:32, Richard Carlsson <carlsson.richard@REDACTED> a
> > écrit :
> >> On 2013-12-15 19:07 , Anthony Ramine wrote:
> >>> Hello,
> >>> I’ve thought about this again and realised that there is a technical
> >>> reason not to expand cond expressions to nested cases directly. That
> >>> reason is scoping rules.
> >>> Let’s assume we compile this expression naively to nested cases:
> >>> cond X = false -> X;
> >>> X = true -> X
> >>> end
> >>> =>
> >>> case X = false of
> >>> true -> X;
> >>> false ->
> >>> case X = true of
> >>> true -> X;
> >>> end
> >>> end.
> >>> I would be *extremely* surprised that such an expression would crash with
> >>> badmatch instead of returning true as it should.
> >>> Regards,
> >> Yes, these complications are the reasons why cond never got implemented
> >> beyond experimenting with the expansion you showed above. It needs
> >> clearly specified scoping rules, and support in all tools above the Core
> >> Erlang level. And nobody seemed to have the time to do that.
> >> /Richard
> erlang-questions mailing list
More information about the erlang-questions