[erlang-questions] guard expression restriction

[James Churchman]

I'm not sure this argument holds.. guards should fail silently because they are a simple test, nothing else. Custom guards are a piece of procedural code that could potentially span many modules and hundreds of lines of code. Silently failing all this code goes agents erlang let it crash and will lead to errors going unexposed. There is a difference between the try catch example below and the mythical "custom guard" in that in the code below i have the CHOICE to add a try catch or not and let it crash.. 


@Richard O'Keefe i was unaware of that subtly to list comprehensions. I was surprised that a match that fails does not throw, but make use of that when choosing list comprehension vs other looping mechanisms as it makes handling user supplied data easier.

On 2 Dec 2010, at 11:51, Kostis Sagonas wrote:

> Hynek Vychodil wrote:
>> On Thu, Dec 2, 2010 at 9:37 AM, Kostis Sagonas <kostis@REDACTED> 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? Sorry, but I do not
>>> see this.
>>> 
>> Anyway, this rewritten version doesn't behaves like guards because it
>> should be more like:
>>        f(Arguments) ->
>>            case catch Expression
>>              of true -> Body
>>               ; _ -> f'(Arguments)
>>            end;
>>        f(Vars) -> f'(Vars).
>> or even worse
>>        f(Arguments) ->
>>            try Expression
>>              of true -> Body
>>               ; _ -> f'(Arguments)
>>              catch
>>                 _:_ -> f'(Arguments)
>>            end;
>>        f(Vars) -> f'(Vars).
>> because soon or late one would write throw(true) inside Expression.
> 
> Very good point...  Thanks for the support Hynek!
> 
> Kostis
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>