[erlang-questions] guard expression restriction
Wed Dec 1 17:22:40 CET 2010
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
On Wed, Dec 1, 2010 at 11:00 AM, 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. ;-)
> 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
>> On Wed, Dec 1, 2010 at 10:21 AM, 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 <>:
>>>> As a newcomer to Erlang, I'm curious about the reason for the
>>>> restriction on guard expressions to a subset of valid Erlang
>>>> " The reason for restricting the set of valid expressions is that
>>>> evaluation of a guard expression must be guaranteed to be free of side
>>>> 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.
>>>> erlang-questions (at) erlang.org mailing list.
>>>> See http://www.erlang.org/faq.html
>>>> To unsubscribe; mailto:
>>> erlang-questions (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:
>> Be well,
>> 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:
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
Welcome to http://householder-yogi.net
On family, NYC, and practicing yoga.
More information about the erlang-questions