[erlang-questions] guard expression restriction

[Richard O'Keefe]

On 2/12/2010, at 9:37 PM, Kostis Sagonas wrote:

> Richard O'Keefe wrote:
>> ...
>> There is of course a fairly elementary transformation by means of
>> which anyone who *really* needs a function call in a guard finds
>> out that they don't.
>> 	f(Arguments) when Expression -> Body;
>> 	<rest of f>
>> =>
>> 	f(Arguments) ->
>> 	    case Expression
>> 	      of true -> Body
>> 	       ; false -> f'(Arguments)
>> 	    end;
>> 	f(Vars) -> f'(Vars).
>> where f' is the rest of f with the name changed.
> 
> Yes, Erlang is Turing complete as it is (so you can express in it any algorithm you want to) and of course there is that transformation, but do you really claim that the bulky code with the case statement and having to factor the rest of f into a separate function is more expressive and programmer-friendly than the one liner with the guard?

Turing completeness is not at issue here.

I am not claiming that the currently legal code is MORE expressive or MORE friendly than
the currently illegal code.  What I claim for it is that as a workaround for what should
be a *RARE* problem, it's tolerable.  But what I also claim is that most often the best
thing to do is to redesign; that in Erlang, wanting a user-defined function in a guard
is often an indication that you are doing something wrong.

Overall, an little awkwardness occasionally is a small price to pay for keeping
unbounded complexity out of guards; things are better for the HUMAN reader if guards
can't do arbitrarily complex things.
> 
>> I'm not providing an example, because I've tried four and each of
>> them was immediately better without trying to do this in guards...
> 
> Hmmm... In any case, the paper I mentioned in my previous mail contains an example of more clear and succinct code when user-defined guards are allowed.

I didn't keep a copy of that; could you mention the paper again?

As a happy Haskeller (who would still be a Cleaner if the Clean team would condescend
to provide a release for modern Macs) I have nothing against arbitrary code in guards
in pure functional languages; where I am wary of this is in
 * concurrent languages (like Parlog and Strand and Erlang)
 * impure languages (like Erlang)