Guards and side effects

[Richard A. O'Keefe]

David Hopwood <david.nospam.hopwood@REDACTED> claimed that
osxroolz@REDACTED's
	... 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>
	
There are two replies to that.

The first is that while the slippery slope argument is not deductively
sound, it is *empirically* amazingly reliable.  It so happens, for
example, that there have been proposals to add mutable data structures
to Erlang.  Right now there is a proposal to add traditional assignment
statements to Prolog.  I kid you not.  Give people a taste of something
familiar and pretty soon they *do* want the whole thing.  Not deductively
conclusive, but empirically pretty reliable.

The second is that that's *not* how the implied argument worked, or at
least not how I read it.  The way I read it was "disproof by analogy",
that is, showing that an argument has an unsound form.

That is,
    "if this FORM of argument is invalid when X='pointer manipulation'
     then you can't rely on this form of argument when X='unrestricted guards'.,
     The burden of substantive proof that the argument *is* sound in this
     case rests with the proposer."
In short, not a slippery slope argument at all.

	No-one is suggesting adding unrestricted pointers.

I *will* make a slippery slope argument here, but it's an inductive
generalisation.  Time after time after time, I have seen a demand that
this or that programming language be extended to allow C pointers to
be passed around.  I have no proof that it _must_ happen, only the
observation that it _does_ happen.  (See manual(i-3-9) and
manual(i-3-15-5) in Quintus Prolog 3.4 for a fairly benign version.
For a rather less benign example, see the "structs" package in Quintus
Prolog 3.4, manual(k-10), manual(g-8-3-2), manual(l-3-22), which basically
gives you C-in-Prolog.  I could provide similar examples for other languages.)

Given that Erlang is not a lazy language like Haskell or Clean,
it is far from clear to me that there is any advantage in adopting
an aspect of their syntax.