[erlang-questions] guard expression restriction

[Kostis Sagonas]

Andy Kriger wrote:
> 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.

As others have already mentioned, the rationale for this decision is 
that in Erlang guards are seen as an extension of pattern matching.
Therefore it's desirable that they are pure functions -- although 
strictly speaking most but not all current guards are pure -- and also 
terminating.

Throughout the years there have been various discussions debating the 
pros and cons of allowing user-defined guards, mostly on this mailing 
list, but very little action in doing something concrete about it.

To me (and perhaps to many others), it was always clear that allowing 
user-defined guards has clear expressiveness benefits in some 
applications and there is no fundamental issue in disallowing them. 
However, it was equally clear that their introduction would need to 
happen cautiously based on program analysis that is able to guarantee 
the side-effect freeness and termination of functions used as guards. 
(On top of that, there are some engineering issues in extending the 
compiler to handle their presence and extending the loader to refuse the 
re-loading of modules that invalidate the analyses' results.) 
Bottomline: this is a far from trivial but probably worthwhile addition 
to the language.

For about a year now, Mihalis Pitidis and I have been working on many of 
the ingredients needed for this change and we already have the necessary 
static analyses and a prototype implementation of changes to the 
compiler that allows for the introduction of user-defined guards. But 
often the devil is in the details. We currently have discussions with 
the OTP team about making a proper extension of the compiler to support 
user-defined guards. (But changes to the loader are still pending.)

Anyway, our idea is to eventually allow for user-defined guards only 
functions which static analysis can determine as side-effect free and 
terminating. But our analyses are actually quite effective.

So, stay tuned and user-defined guards may find their place in an 
Erlang/OTP release near you.


Kostis


PS. For those interested, a related paper titled "Purity in Erlang",
     with more information on this topic can be found at:

	http://user.it.uu.se/~kostis/Papers/purity.pdf

     Comments on the paper are welcome -- preferably off list, directly
     to the authors.