--- TSa <[EMAIL PROTECTED]> wrote:

> Daniel Ruoso wrote:
> > In fact, I doubt that there's a way to completely avoid any
> possible
> > side effects on this closures. as the very first line of the
> closure
> > shows:
> >  
> >    $_.inside_of(...)
> > 
> > This is a plain method call, there's no way to tell if this method
> > will change anything inside the object or not.
> Well, we could use something to the effect of const methods in C++.
> That is we have a trait on a method that prevents changes of the
> object. And these could be the only ones allowed in where blocks.

The problem Daniel mentions is that in a dynamic language like Perl,
you just can't prevent side-effects.  Consider:

  eval $foo;

Does that have side effects or not?  There's no way to know and yet
there are plenty of examples one could potentially construct which
would have non-obvious side-effects.

I would love to be able to introspect the code to know whether or not
any operators or keywords with known side-effects are in a given block
of code, but even then that would depend on the context (of the code,
not Perl's "context").  For example, should the pre/postfix '++' be
listed as having a side-effect?

  sub side_effect    { return $_[0]++ }
  sub no_side_effect { my $x = shift; return $x++ }

In Perl 6, since arguments to subs would have to be specifically
written as 'is rw', we might be able to minimize this issue, but I
don't know if we can stop it.


Buy the book  - http://www.oreilly.com/catalog/perlhks/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog     - http://use.perl.org/~Ovid/journal/

Reply via email to