Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Experimental features: autoderef vs postfix deref

by stevieb (Canon)
on Jul 12, 2015 at 13:26 UTC ( [id://1134372]=perlquestion: print w/replies, xml ) Need Help??

stevieb has asked for the wisdom of the Perl Monks concerning the following question:

In Re: Parsing output from Nmap::Scanner with varying hash address., kcott makes a very strong case for not using experimental::autoderef in production code (same as any experimental features). Essentially, what this does, is it allows you to use a (unblessed) reference as a parameter to the array and hash container functions (keys(), values() and each()) instead of putting the ref inside of the circumfix operator (@{}, %{}).

I read a detailed RT discussion kcott posted, which led me to research postfix dereferencing, which I really like the reasoning behind (although I need to play with it to see if the new syntax 'sticks').

For now, I'll continue to use the dereference blocks and recommend everyone else do too, but my question is whether anyone has an inside track as to which one of these new experimental features will win out in the long run, and if there are any alternative experiments in this area coming down the pipe that might compete with these two?

-stevieb

Replies are listed 'Best First'.
Re: Experimental features: autoderef vs postfix deref
by BrowserUk (Patriarch) on Jul 12, 2015 at 14:04 UTC

    This made me wonder what if any "new syntax" added to Perl5 since 5.8 has actually become a useful, usable part of the language and not been backed out or hidden behind some obscure set of enablement requirements that mean its too much bother to be bothered with.

    Given/when: been and gone; smart matching: decree absolute; autoderef: living on the edge; state:barely used, and flawed; say: a pain to enable; /r: never seen the need.

    From my perspective, the only new feature that has earned its place is defined-OR (//).

    So, when I read about new ego-driven fads like postfix deref I look back at the recent history and think: Meh! Why bother. It'll probably disappear up its own bum once the ego trip wears off anyway.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
      state:barely used, and flawed; say: a pain to enable; /r: never seen the need.
      • say is enabled together with strict in use v5.12;, that replaces use strict;.
      • s///r is useful in map: @out=map { s/foo/bar/r } @in. Without /r, you need a helper variable: @out=map { my $x=$_; $x=~s/foo/bar/; $x } @in
      • I don't get it. What's wrong with state?

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        I don't get it. What's wrong with state?

        Using normal closures, I can do:

        { my $closure; sub x1{ $closure = shift if @_; $closure } sub x2{ $closure = shift if @_; $closure } };; print x1( 123 ); print x2(); print x2(456); print x1();; 123 123 456 456

        Or I can do:

        { local our $closure; sub x1{ $closure = shift if @_; $closure } sub x2{ $closure = shift if @_; $closure } };; print x1( 123 ); print x2(); print x2(456); print x1();; 123 123 456 456

        Or:

        sub x1{ our $closure = shift if @_; $closure } sub x2{ our $closure = +shift if @_; $closure };; print x1( 123 ); print x2(); print x2(456); print x1();; 123 123 456 456

        Try that with state:

        sub x1{ state $closure = shift if @_; $closure } sub x2{ state $closure = shift if @_; $closure };; print x1( 123 ); print x2(); print x2(456); print x1();; 123 Use of uninitialized value in print at (eval 22) line 1, <STDIN> line +14. 456 123

        Or:

        sub x1{ state our $closure = shift if @_; $closure } sub x2{ state our + $closure = shift if @_; $closure };; No such class our at (eval 23) line 1, near "{ state our" No such class our at (eval 23) line 1, near "{ state our"

        So, three different ways to do something that works; and a new mechanism specifically designed to replace them that doesn't.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

      I agree with all you've said here. I've played with all the new features you stated, but none ever provided me with enough benefit over what existed and I was used to, so I gave them up quickly. However, I'm sure some people do find value in them, it's just that I don't so much.

      I'm going to try postderef, but in any real code I'll stick to the old fashioned way as it's guaranteed backward compatible (CPANTesters) and I just can't see it being removed any time in the even non-forseeable future.

      -stevieb

      Why is use 5.024 'a pain to enable'? And yes, people - for example, I - do use say, /r and unicode_strings, and __SUB__, and fc. I'm going to use posfix deref too, when the current bothersome incantations to enable it will go away. And also signatures.
        Why is use 5.024 'a pain to enable'?

        Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.

        Because I'd have to remember which client's behalf I'm programming on; which version that client uses; which 'feeechers' that version supports; which 'mis-feechers' that version has dropped.

        And then go through the whole damn game again when they decide to upgrade; and have to back out and replace the stuff that's 'gone away'.

        Life's too short to ripple in the wind of every vanity project p5p allows through.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
Re: Experimental features: autoderef vs postfix deref
by Anonymous Monk on Jul 12, 2015 at 13:36 UTC

    See here and here: it seems that postfix deref is on track to become non-experimental and autoderef to be removed.

      ... and apparently postderef is already non-experimental in blead, see 2ad792cd4e96.

        Very helpful posts by both AnonyMonks, thanks. Does it go without saying that if it's been deemed non-experimental in blead that it's safe to use in prod code now, and ok to use in PerlMonks replies without applying the 'careful, experimental' blurb?

Re: Experimental features: autoderef vs postfix deref
by stevieb (Canon) on Jul 13, 2015 at 19:28 UTC

    For anyone interested, I've been doing some basic benching. Two of the tests are self-explanitory. The "no_braces" test is the same as "circumfix", except that it has all but the mandatory bracing removed. Over the next couple days, I'll do more elaborate testing that can be repeated easily. In this case, after numerous runs, I can only suspect that the 'no_braces' is slower consistently because perhaps perl has to do extra work to decide how to proceed. This is only a guess though. I don't know nearly enough about the guts to know for sure.

    Result:

    Rate no_braces circumfix postderef no_braces 2.59/s -- -2% -7% circumfix 2.64/s 2% -- -5% postderef 2.78/s 7% 5% --

    Benchmark code:

    #!/usr/bin/perl use warnings; use strict; use feature 'postderef'; no warnings 'experimental::postderef'; use Benchmark qw(cmpthese timethese); my $count = 100000; cmpthese(1000, { 'circumfix' => \&circumfix, 'postderef' => \&postderef, 'no_braces' => \&no_braces, }); sub circumfix { my ($h, $a, @a); for (1..$count){ push @{$h->{$_}}, [$_]; } for my $k (keys %{$h}){ for (@{$h->{$k}}){ push @{$a}, $_ for @{$_}; } } push @a, $_ for @{$a}; } sub postderef { my ($h, $a, @a); for (1..$count){ push $h->{$_}->@*, [$_]; } for my $k (keys $h->%*){ for ($h->{$k}->@*){ push $a->@*, $_ for $_->@*; } } push @a, $_ for $a->@*; } sub no_braces { my ($h, $a, @a); for (1..$count){ push @{$h->{$_}}, [$_]; } for my $k (keys %$h){ for (@{$h->{$k}}){ push @$a, $_ for @$_; } } push @a, $_ for @$a; }

      Did you run the benchmark several times? Such small differences are suspicious. It might be more enlightening to use a perl binary with -DDEBUGGING and dump the parse tree. For well implemented variations of syntactic sugar of the same thing I'd expect the the compiler to produce the same tree.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
        I did run numerous times and the results were pretty consistent. I'll definitely do as you suggested to get a better idea, and will post back here with results.

      Interesting, but probably not very significant.

      A more interesting figure, that is probably impossible to measure, is what performance affect has this 'feature' had upon code that doesn't use it?


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
        I thought that if you don't request the code, it isn't loaded. Can you explain what you mean? Would it be that even though the feature isn't use'd, it's still intertwined enough to have effects?
Re: Experimental features: autoderef vs postfix deref
by anonymized user 468275 (Curate) on Jul 14, 2015 at 11:26 UTC
    All this chinese makes me jump in my goalseeking time machine, set the goal for "why did we ever want $, @, %?" and press the start button.

    As the smoke clears from the TARDIS console, I find myself somewhere in Bell labs in the late sixties, when, along with hard rock, the unix shell was invented and variable names had to have a different syntax to filenames (a note to myself:nothing to do with reserved words after all).

    Pressing the next button jumps me forward twenty years or so, when suddenly Perl is invented and needs to have a syntax for arrays and hashes.

    But where is postfix? Not in this causality chain, so I reset the console and land somewhere in Palo Alto instead , where in a parallel Universe, a postfix addict invents Java ('.' instead of '->').

    Suddenly, time and space collapse in causality violation and I am left asking myself whether the $ # % was a good idea in the first place.

    Given that & is enough to distinguish function calls from variable references, and that the shell doesn't get its hands on the Perl code, it seems to me that maybe Perl could have borrowed this part of the syntax from C instead of shell in the first place? But trying to make Perl look like Java won't help that, in my opinion.

    One world, one people

Re: Experimental features: autoderef vs postfix deref
by sundialsvc4 (Abbot) on Jul 13, 2015 at 17:22 UTC

    I will frankly agree with you, BrowserUK.   (Upvoted.)

    The big problem that I have with most of these “fee-churs” is that they add a new “M” to “DWIM,” apparently just to save a few keystrokes.   Most of the time, a programming language doesn’t really need another way to say the same thing.   All that this really does, is to introduce yet-another element of functional ambiguity into the syntax ... which is especially a problem when the “correct” interpretation depends on (even for the moment ...) some obscure use clause.

    Given that programmers have to maintain source-code libraries consisting of maybe hundreds of thousands of lines, it really isn’t a good thing for there to be more-than-one way to say one-thing.   There probably will be no at-runtime difference, as the compiler might well translate both constructs into the same underlying perlguts.   But, there is a pragmatic difference, caused both by the ambiguity and by the co-existence of “old” and “new,” within the same voluminous code-base.   Only a very few, like “immediate-OR,” are both clean-enough and isolated-enough to be (IMHO) a genuine, relatively risk-averse, win.

    Language features, however well-intentioned they may be, must be judged in a very long view.   We do every day deal with vast code-bases that were constructed over the period of many years, even as the [Perl...] language itself evolved, as it were, “beneath their feet.”   That source-code is worth many millions of currency-units.   [Perl], itself, is not.

      s/DWIM/TIMTOWTDI/

        I totally agree...

        To put it another way, though not very well:   “TMTOWTDI ... now, pick one.”.   It’s okay to have more than one approach to a problem, but not to have two or more syntactically-ambiguous ways to do the same thing.

        Every language has its “crufts.”   Perl, maybe, has more than a few.   But you smile to yourself and say, “that’s just the way it is.”   Speaking now purely from a software asset-management point of view, the one thing that I most do not want to see is:   “That’s just the way it is, only maybe it isn’t.”   Yeah, maybe in retrospect “that way” might not have been aesthetically best, but let’s all just live with it, for the sake of millions of lines already written.   Don’t gratuitously tweak the compiler and then add an on/off switch to your tweak.   Well-intentioned though your efforts might be, that just adds headache without aspirin.   Now, within a massive block of source-code, we now have two different ways being done to accomplish the same thing in not quite the same way.   Uh uh.   Don’t do that to me...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1134372]
Approved by shmem
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2024-03-29 01:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found