[erlang-questions] guard expression restriction

[Ulf Wiger]

True, but there are related discussions, e.g. about a real 
syntax for match specifications, parameterised selective receive,
abstract patterns, etc. - merely implementing user-defined guards
with some clever code rewrites in the compiler would not do much
to address the Bigger Picture (™).

IOW, lack of user-defined guards is a minor nuisance, but solving one
or all of the above could enable new approaches and/or significantly
improve analysis of the code*.

BR,
Ulf W

* Dialyzer, for example, knows little of match specifications, as they 
are often indistinguishable from data.

On 1 Dec 2010, at 16:21, Attila Rajmund Nohl wrote:

> It's not about mistakes, it's about avoiding side effects. Don't
> forget that the guards that eventually don't match are also executed.
> This is something that would lead to hugely surprising things.
> 
> 2010/12/1, Andy Kriger <andy.kriger@REDACTED>:
>> As a newcomer to Erlang, I'm curious about the reason for the
>> restriction on guard expressions to a subset of valid Erlang
>> expressions
>> 
>> From
>> http://www.erlang.org/doc/reference_manual/expressions.html#id75235
>> " The reason for restricting the set of valid expressions is that
>> evaluation of a guard expression must be guaranteed to be free of side
>> effects."
>> 
>> That's nice, but basically says 'this is so important that the
>> programmer cannot be trusted to get it right.' Many other parts of the
>> language don't make this statement - fail early and often is
>> encouraged, from what I understand.  So, I'm wondering about the
>> history behind that decision and if there's been any talk of removing
>> that restriction now that Erlang has expanded far beyond the telecom
>> world. There's a definite benefit to be had in clarity in allowing
>> user-defined boolean functions that are specific to the application.
>> Yes, this would leave more room for mistakes and, I'm guessing, cut
>> off some compiler optimizations, but the decision would be left to the
>> programmer to make rather than disallowed by the language.
>> 
>> Not looking to start a fight if this is well hashed ground. As I said,
>> curious about the history and whether it's been debated as an EEP.
>> 
>> thx
>> 
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>> 
>> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com