Tail recursion would be a great optimization to have, but Perl doesn't do it except through the clunky use of goto BLOCK;. And that doesn't appear to give any time optimization (admittedly, that p5p message could be long out of date).
I don't think there's any support for the idea that until the Perl6 effort, Perl was anything but ad hoc design. The difficulties in dis-ambiguizing the defined-or operator from an empty regex should be proof of that. The fact that you can't get a context-free grammar for Perl should be proof of that. The steps perl has to go through (and still ocasionally get it wrong) to figure out if map {. . .} @array should contain a block or a hashref should be proof of that.
I don't mean to insult the p5p people, as they make my work easy in many cases. Perl has simply been extended over the years from an awk/sed killer into a part imparative, part functional, part OO language, and that process would inevitably introduce some rather odd designs.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
In reply to Re^2: Trinary Operator Semantics
by hardburn
in thread Trinary Operator Semantics
by hardburn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |