[erlang-questions] guard expression restriction

[Kenny Stone]

This has surprised me a few times as well when I tried to do it (I forget
things...)

One pattern you can do is something like this:

% call foo
foo(Obj, check_my_obj(Obj1)).

%% foo
foo( Obj, {error, Reason}) -> handle_error(Reason);
foo( Obj, ok ) ->
  % business logic.

It's not a custom guard, but you are getting much the same thing with
pattern matching.

On Wed, Dec 1, 2010 at 10:22 AM, Andy Kriger <andy.kriger@REDACTED> wrote:

> 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.
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>