Guards and side effects

Robert Virding robert.virding@REDACTED
Sat Mar 26 22:30:00 CET 2005

Sorry for missing this but I have not been on for a while.

I think that Joe said it all in another thread:

It's not an ugly wart - it's deliberate.

Guards are merely extensions of pattern matching - they must be side 
effect free
and capably of efficient compilation.

Soon you hve the whole application in guards. Look at the Common Lisp 
format function.


Thomas Johnsson XA (LN/EAB) wrote:

>(Subduing the hardcore functional programmer in me for a bit ... :-)
>I see really no compelling reason to prohibit side effects in guards,
>in fact there may well be sensible uses, for instance, communicating 
>with another process to find out the value of the guard, consult ets tables 
>or other data bases, call a memo function ....
>The only tricky place, as far as I can see, is guard evaluation
>in a receive: to evaluate guards to select a message in the own process in-queue,
>it makes sense *not* to allow another 'recursive' receive to find the value of the guard,
>but to issue a run time error instead.
>( An aside: this is akin to black hole:ing in implementing a lazy functional language, where in 
>the process of evaluating a 'thunk' you need the value of the same thunk)
>There are many opportunities for the programmer to shoot him/herself in the foot,
>but to hold the programmer in strict harness in this particular corner of the
>language, and nowhere else, I find that misguided.
>-- Thomas

More information about the erlang-questions mailing list