On Sun, Feb 13, 2005 at 09:53:36AM +1100, Damian Conway wrote: > Jonathan Scott Duff wrote: > >The down side is that programmers need to be more aware of > >subroutine/method side effects and write their programs accordingly. > > This is a *down*-side??? ;-)
Indeed ;-) I'm using "programmer" in the broadest possible sense here. Joe the dairy-farmer who wrote his first program ever (and it happened to be in perl) yesterday is still a programmer. > >Because of this, I'd suggest that autothreading of user-defined routines > >not be the default, but rather enabled via a pragma of some sort (or, of > >course, via an "autothreaded" trait). For the built-in routines this > >isn't a worry as we get to design them appropriately. > > This seems to be needlessly optimizing for the rare case. And needlessly > restrictive. Perhaps. I'm not so sure it's the rare case that programmers aren't prepared to deal with implicit parallelization. :-) Part of the appeal of perl is that people of all skill/knowledge levels can jump in and start doing useful work. Autothreading by default has the potential to force people to be aware of junctions before they are ready to understand them. > I'd suggest that it would suffice to have a(n optional) warning emitted > when a subroutine with side-effects is autothreaded: > > use warnings 'autothreading'; This works for me but I'd make it one of the default set of enabled warnings from a plain "use warnings;" though. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
