Guards and side effects
Thomas Johnsson XA (LN/EAB)
Fri Mar 11 10:35:27 CET 2005
(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