Front page | perl.perl5.porters |
Postings from August 2009
> This is by no means a complete solution. In fact I'm not even convinced > that a full solution is possible. But it is heading in the direction of > an improvement and, as such, it may merit further investigation. There > are at least the following problems: > > 1. You can't just stick a "not" in there and expect it to work. You > probably have to de De Morgan (to Morgan?) the condition. > Yes, as this optimization also turns "not($a) and not($b)" into "not($a or $b)". > My opinion is that it is nice if Deparse can get as close as possible to > to the original code but if it can't tell that certain optimisations > have been made then it's not the end of the world. I expect (and hope > for) this to happen more and more as we are able to optimise the optree, > possibly with the optimisations being controlled by a switch, if they > are expensive. > That's my opinion too. > 5. Anything else? > > What have I missed? Is this important? Is effort better directed > somewhere else? Do we have a champion? > I don't think it's important, but still nice to have if it doesn't cost too much effort. It does make a good introduction work and would definitely have its place in perltodo (hint, hint). > I'm CCing Gerard Goossen since I wonder whether his proposal "Changing > the Perl 5 optree build process into a Abstract Syntax Tree generation > and a code generation step" might be able to provide any benefits in > this area. Or perhaps it might make things more difficult? > That's a very long term plan that would cost almost an entire rewrite of the internals. I don't believe it has to be considered for this special problem. Vincent.Thread Previous | Thread Next