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