[erlang-questions] guard expression restriction

Wed Dec 1 19:22:51 CET 2010

Interestingly list comprehensions offer custom guards, if that it of use to you.

But i agree, custom guards that can not only cause side effects but can crash, throw exceptions, do send and receives, pause code etc.. etc.. would be a horrible thing that i would never want to see in erlang You would need a try catch for just function names etc... tho maybe there is a compromise that could somehow be worked out.

My personal very simple technique that fixes one type of need for custom guards is to name the variables the same.

eg :

> does_match("yes","no").

does_match(Var1,Var1)-> they_match;
does_match(_,_)-> no_match. 

i find myself always looping threw stuff and needing to match all of inputs to a variable (only known at run time, that may even change during the recursion etc.. ) and this stops this type of code everywhere : does_match(Var1,Var2) when Var1==Var2 -> etc.. all threw my code and can be used to put a lot more of the logic in the function definition & modularity complex things can be build up like this and still be quite readable 

On 1 Dec 2010, at 16:39, Kenny Stone wrote:

> 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
>> 
>> 