Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Trinary Operator Semantics

by chromatic (Archbishop)
on May 26, 2005 at 21:25 UTC ( [id://460881]=note: print w/replies, xml ) Need Help??


in reply to Trinary Operator Semantics

It isn't so much that Perl's designers ignored good semantics, but that the language wasn't really designed at all.

I think that misses a much more interesting issue (and is potentially insulting as well). Perl is a very different type of language from C. The fact that it may not do the same types of optimizations as C compilers can do to the same degree that C compilers can do doesn't necessarily mean that Perl had no design stage nor that the Perl developers are lazy or ignorant.

By giving up the "compile once and for all and that's that" step, Perl has traded some potential optimizations for additional flexibility. I don't think that's an accident.

Replies are listed 'Best First'.
Re^2: Trinary Operator Semantics
by hardburn (Abbot) on May 27, 2005 at 14:01 UTC

    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.

      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 think you mean goto ⊂

      #!perl use strict; use Benchmark; sub normal { return 0 unless $_[0]; @_ = ($_[0] - 1); return normal(@_); } sub tail { return 0 unless $_[0]; @_ = ($_[0] - 1); goto &tail; } timethese( 10, { "normal" => sub { normal(500000) }, "tail" => sub { tail(500000) }, } );
      Output:
      normal: 25 wallclock secs (23.19 usr + 0.59 sys = 23.78 CPU) @ 0 +.42/s (n=10) tail: 18 wallclock secs (17.44 usr + 0.03 sys = 17.47 CPU) @ 0 +.57/s (n=10
      Not very impressive, but there is a clear improvement in speed. The improvement in wallclock seconds becomes far larger if you start swapping with the normal recursive call (at my machine at 1_000_000 levels of recursion). I tried this only with 1 iteration because I got impatient:
      #!perl use strict; use Benchmark; sub normal { return 0 unless $_[0]; @_ = ($_[0] - 1); return normal(@_); } sub tail { return 0 unless $_[0]; @_ = ($_[0] - 1); goto &tail; } timethese( 1, { "normal" => sub { normal(1000000) }, "tail" => sub { tail(1000000) }, } );
      output:
      Benchmark: timing 1 iterations of normal, tail... normal: 123 wallclock secs ( 6.58 usr + 1.13 sys = 7.71 CPU) @ +0.13/s (n=1) (warning: too few iterations for a reliable count) tail: 3 wallclock secs ( 3.50 usr + 0.01 sys = 3.51 CPU) @ 0 +.28/s (n=1) (warning: too few iterations for a reliable count)
        Oddly enough, "optimized" tail recursion is significantly slower than recursing the same way without the goto:
        sub faster { return 0 unless $_[0]; @_ = ($_[0] - 1); &faster; }
        Using this test:
        cmpthese( -10, { "normal" => sub { normal(50000) }, "tail" => sub { tail(50000) }, "faster" => sub { faster(50000) }, } );
        I got these results:
        Rate normal tail faster normal 2.34/s -- -0% -41% tail 2.35/s 0% -- -41% faster 3.96/s 69% 68% --

        Caution: Contents may have been coded under pressure.
      I don't think there's any support for the idea that until the Perl6 effort, Perl was anything but ad hoc design.

      Compare it to a real example of ad hoc language design: PHP.

      The fact that you can't get a context-free grammar for Perl should be proof of that.

      I wouldn't jump to that conclusion so fast. Human languages are not context-free. Giving a language a CFG certainly makes it easier for computers to understand it; it's less clear that it makes it easier for the human programmer.

        I don't know of any human languages that were consciously designed (at least, ones that are actually used by a significant precentage of the population, which discounts Esperonto and Klingon). They're always ad hoc. So is Perl, and that's what that statement was trying to prove.

        "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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://460881]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2024-03-28 19:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found