[erlang-questions] guard expression restriction

[Andy Kriger]

Pattern matching is one of the most powerful and attractive parts of
the language itself. I'm sure it's mostly my newness to the style of
programming, but I keep running into situations where I'd like to
write many fine-grained functions using pattern matching but end up
using case statements or if clauses within a function because I don't
see the pattern matching alternative (which is definitely not to say
that it's not there - the lightbulb is still dim, that's all). That's
what's driving my curiosity about opening pattern matching to greater
expressiveness. And, from a previous response, it sounds like that is
being discussed.

On Wed, Dec 1, 2010 at 11:00 AM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> 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
>
>
>
>



-- 
Be well,
andy

Welcome to http://householder-yogi.net
On family, NYC, and practicing yoga.