Larry Wall <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
[...]
> : How does one enforce the no side-effects rule, and how deeply does it
> : traverse?
>
> Dunno. Could warn or fail on assignment to any non-lexical or
> non-local lexical as a start. Maybe we could warn or fail on method
> calls known to modify an object. But I don't know how much
> technological enforcement we can achieve without an unnecessarily
> fascist declaration policy. I expect the most important thing would be
> to encourage people to think that way.
You cannot usefully tell if something has a "side effect". Well, you
can do stuff like warn if it obviously contains assignments, prints
and maybe gotos, or you can run it and die horribly if it tries to do
one of the above. But I doubt this would be useful.
Here's an example. Suppose f is a function "with no side effects".
Then I can write
POST {
f($x) == $y or die; # (die is the ultimate side effect, but
# it's somehow still OK, right?)
}
Now, since f is a function "with no side effects", I can Memoize it a
la MJD, right?
But I can't do both at once, because then my POST will call the
Memoize'd f, which has what is technically a side effect.
How about
POST {
%h{$x} == $y or die;
}
OK, right? And if %h is really tie'd to a file?
The point is that what counts as a real side effect depends on the
program, not on the language. (Well, maybe not if you're a functional
programmer). The definition is that an expression "has side effects"
if it can affect the (internal or external) state of the program. But
the *useful* definition is that an expression "has side effects" if it
can affect the state of the program in a manner which matters to the
program.
I'd say warn in the documentation that PRE and POST should not contain
side effects, maybe even add a switch to disable their execution, but
not attempt to enforce anything. It's just not useful, I think.
[...]
> : sub non_method {
> : loop {
> : PRE {
> : print "PRE\n"; # Is printing a side-effect?
>
> Gee, maybe warnings and failures are side effects, and should be also
> prohibited. :-)
print is OK (for a program running on the console STDOUT not usefully
redirected, etc.), because its side effect presumably doesn't matter
to the program. In a CGI application, print would not be side effect
free.
> Like I said earlier, I think the important thing is to make people
> think about it, not to continually frustrate them. I'd be inclined to
> let people choose their own level of pain by setting DbC strictness
> thresholds.
Please set my threshold of side effect pain to undef...
--
Ariel Scolnicov |http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]
72 Pinhas Rosen St. |Tel: +972-3-7658117 "fast, good, and cheap;
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 pick any two!"
