Guards and side effects

[Thomas Johnsson XA (LN/EAB)]

(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