[erlang-questions] guard expression restriction
Thu Dec 2 00:44:05 CET 2010
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
> " 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.
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
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.
PS. For those interested, a related paper titled "Purity in Erlang",
with more information on this topic can be found at:
Comments on the paper are welcome -- preferably off list, directly
to the authors.
More information about the erlang-questions