[erlang-questions] guard expression restriction

[Robert Virding]

----- "Kostis Sagonas" <kostis@REDACTED> wrote:

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

Would you allow user guard functions to call code in other modules? If so how would ensure that they are side-effect free and terminating in the presence of dynamic code loading?

How are errors in user guard functions handled? Will they generate an exception or just cause the guard to fail as happens now?

Robert