[erlang-questions] guard expression restriction

[Kostis Sagonas]

Robert Virding wrote:
> ----- "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?

Yes, as long as the analysis can determine the properties these 
functions need to satisfy.

> If so how would ensure that they are side-effect free and terminating in the presence of dynamic code loading?

I wrote this in my mail: "the loader needs to be extended to refuse the 
re-loading of modules that invalidate the analyses' results."

This means that code reloading that changes properties that the compiler 
relies upon needs to happen not on a module by module basis, but on a 
set of modules basis. By the way, to me at least, this seems a more sane 
thing to do, independently of whether user-guards are present or not. 
It's high time that something like this happens. Erlang's desing to 
allow re-loading of individual modules that differ in fundamental ways 
from their prior versions (e.g. adding arguments to existing functions 
or removing functions used in other modules of an application) always 
seemed quite arbitrary, weird, and dangerous to me. IMO, Erlang would be 
a better language if it provided a construct to reload atomically a 
*set* of modules.

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

There is no change in this respect.  This is an orthogonal issue.

Kostis