[erlang-questions] Guards on assignment (i.e. assertions)

[Richard O'Keefe]

On Mar 2, 2010, at 9:44 AM, Garrett Smith wrote:

> Right, that's fine. It's even pretty readable. Though when it fails,
> you just get an ambiguous "exception error: no true branch found when
> evaluating an if expression", which is why I prefer the case
> statement.
>
> Both case and if are  a bit verbose. A simpler syntax would, I think,
> encourage this practice.

Is it a practice we _want_ to encourage?

In the absence of a realistic concrete example,
it seems to me as though the check may be in the wrong place.

Suppose for example I found that I often wanted

     if A =< B, B =< C -> X = B end

What I'd do would be to write a *function*

     ranged(X, L, U) when L =< X, X =< U ->
	X.

and then call it

     X = ranged_(B,  A, C)

This gives a much more informative error message than 'case'.
Such checking functions can be inlined, so there's no need to
worry about performance issues.

I use assertions a lot in imperative code, but in functional
code, it doesn't seem to fit very well.  If I'm binding a
value to some new variable, there ought to be a reason
*in the computation of the value* why it is a good value.