[erlang-questions] guard expression restriction

[Ulf Wiger]

Think of guards as an extension of the pattern matching, i.e.
a purely declarative, and quite pervasive, part of the language.

Looking at it this way, it could be argued that the problem is that 
some parts of the patterns look like normal expressions. ;-)

BR,
Ulf W

On 1 Dec 2010, at 16:51, Andy Kriger wrote:

> I understand about preventing side effects, but the approach seems to
> be saying that the language will make sure there are none, rather than
> letting the programmer make that mistake and learn from it. So, I was
> wondering if there was a deeper design decision behind that, a reason
> why, in guards, it's really really important that side effects don't
> happen.
> 
> On Wed, Dec 1, 2010 at 10:21 AM, Attila Rajmund Nohl
> <attila.r.nohl@REDACTED> 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
>> 
>> 
> 
> 
> 
> -- 
> Be well,
> andy
> 
> Welcome to http://householder-yogi.net
> On family, NYC, and practicing yoga.
> 
> ________________________________________________________________
> 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