Correct syntax of a case clause

mats cronqvist masse@REDACTED
Mon Jun 15 19:02:55 CEST 2009


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}



More information about the erlang-questions mailing list