Guards and side effects

[Thomas Johnsson XA (LN/EAB)]

The torch I threw in seems to have caught fire -- good! (:-)

The 'Erlang way' is to do run time checks instead of compile time / static checks --
my argument is merely drawing that to it's logical conclusion.

I wasn't advocating profligate use of side effects as a style of programming.
But in cleaning up the language and thus allowing general expressions including 
calls of user defined functions in guards, one must also potenitally allow
side effects there. With my examples 
I was also pointing out that here might be legitimate uses
of side effects even with a declarative/functional thinking & style.

Torbjorn Tornkvist:

> The hardest problem I find, when debugging
> code, are those that involves side-effects, i.e
> ets, process dict., message sending, etc
> To open up guards to be allowed to do this
> would be a nightmare.

I agree that these kinds of problems are often nightmarish,
but I don't see how generalising guards noticeably worsens
this nightmare.

> User defined guards which is guaranteed to
> be side-effect free may be ok, but then we
> have the termination problem of course.

A *runtime* check & crash when the expression evaluation is doing
something fishy in e.g. guard evaluation in receive!

-- Thomas