Guards and side effects

[David Hopwood]

osxroolz@REDACTED wrote:
> I see no compelling reason to prohibit pointer manipulation in Erlang. 
> Just imagine how many really useful things you could do if
> you could manipulate pointers. Communicate with other processes,
> re-examine garbage-collected data and cause behaviour in your program
> which you never imagined possible!!! This would be a real performance
> booster.
> 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.

Your implied argument (that allowing arbitrary function guards would
lead to adding bad features such as unrestricted pointer manipulation)
is a variant of the "slippery slope" fallacy:
<http://en.wikipedia.org/wiki/Slippery_slope>

No-one is suggesting adding unrestricted pointers. Unrestricted pointers
substantially change the semantic model of the language, creating the
possibility of undefined behaviour that can be manifested far away from
the construct that caused it. Function guards may have confusing effects
in some cases, but those effects occur immediately, and are equivalent
to similar code written using the 'case' construct. If guards are
specified to be evaluated as-if in order, then the behaviour is always
well-defined (and deterministic if the guard functions are). Please stick
to criticising the specific construct that is being proposed.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>