Guards and side effects
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
and capably of efficient compilation.
Soon you hve the whole application in guards. Look at the Common Lisp
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.
More information about the erlang-questions