Guards and side effects

[Robert Virding]

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.

Robert


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
>
>  
>