[erlang-questions] Re: Correct syntax of a case clause

[info]

Hi All,

Hey that was my question .... and you wander from my subject !
I gave an example but don't try to solve this example !!

case Expr of
pattern1 -> do_1;
pattern2-> do_2;
pattern3 -> do_3;
...
end

The question was "is it possible to group two patterns in a case ?"

In another pseudo code:
if Expr = pattern1 OR Expr = pattern2 then do_1;
if Expr = pattern3 then ...
...

case Expr of
{pattern1,pattern2} -> do_1;
pattern3 -> do_3;
...
end
... doesnt work ... normal !
case Expr of
(pattern1,pattern2)-> do_1;
...
end
...doesn't work


Bryan Fink  <bryan.fink@REDACTED > writes:

> On Mon, Jun 15, 2009 at 9:49 AM, mats cronqvist <masse@REDACTED > wrote:
> > Sean Cribbs  <seancribbs@REDACTED > writes:
> >
> > > If you have only a,b,c as possible matches, I'd do it like this:
> > >
> > > case Expr of
> > >  c - > block2;
> > >  _ - > block1
> > > end
> >
> >  this has the huge disadvantage of breaking when you add 'd' to the
> >  possible values of Expr.
>
> Hi, Mats.  I'm struck by how many interpretations this statement can
> have when assumptions about context are altered.  I think rewording
> your statement illustrates the alternate assumptions I'm thinking of:

  Hi Bryan!

> "this has the huge disadvantage of *not* breaking when you add 'd' to
> the possible values of Expr."
>
> "this has the huge *advantage* of *not* breaking when you add 'd' to
> the possible values of Expr."

  I'm a "the glass is half-empty" kind of guy...

> Each of these rewordings takes issue with the fact that the case
> clause doesn't fail when Expr='d'; it matches, and block1 is
> evaluated.  The statements differ with each other over whether this is
> intended behavior.  Just a reconsideration of what "breaking" means in
> context (function failure or interface nonconformance).

  A good point. What do I mean by "break"? Perhaps I should have put it
  like this;

  If Expr is modified so it can be bound to values other than a, b or c,
  it will work (i.e. produce the correct result) only by accident. But
  it will not fail (i.e. throw an exception). This is what I consider
  the worst kind of broken.

  Given that the original problem statement considered itself with a, b
  and c, we must assume we have no idea what to do if we get a
  d. Otherwise the spec should have read; "all values except c should be
  treated the same." This is different from when we write a polymorphic
  function, when we know up front that some value should be ignored.

  It's kind of like this code I once encountered in a production system;

  {_,R} = mnesia:transaction(...),

  This beauty will never fail, but works only by accident(*). And when
  it doesn't work, you have an inconsistent data base.

  mats


(*)  For those unfamiliar with mnesia, the spec is something like this;
mnesia:transaction(...) - > {aborted, Reason} | {atomic, Result}


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org