Guards and side effects
Thomas Johnsson XA (LN/EAB)
Fri Mar 11 13:14:31 CET 2005
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.
> 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
> 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!
More information about the erlang-questions