http://www.perlmonks.org?node_id=1020308


in reply to Re^8: Is there any difference between prototype % and @ ?
in thread Is there any difference between prototype % and @ ?

This can't be chained at least not easily w/o more transformations in the middle.

Show me an example of one of these mythical chains over a listified hash? (One that makes some sense!)

and your code is quite obfuscated...

Hm. You find that "obfuscated"? I always rated you as one of the more adept perlers.

Besides, isn't a big part of the purpose of subroutines to hide the "difficult stuff", in order to simplify the code that calls it?

though ++ for creative use of each within map.

Thanks. The same method works with hsort to make sorting hashes a breeze:

sub hsort (&\%) { my( $code, $href ) = @_; sort( $code map[ each %$href ], 1 .. keys %$href ); } my %orig = ( cat => 22, dog => 23, category => 66, catalyst => 77, cataclysm => 88, dogma => 89, dogstar => 92, ); ## Oh look! A chain :) print 'sorted by key: ', map "$_->[0]=>$_->[1] ", hsort{ $a->[0] cmp $ +b->[0] } %orig; print 'sorted by val: ', map "$_->[0]=>$_->[1] ", hsort{ $a->[1] <=> $ +b->[1] } %orig; C:\test>hFP.pl sorted by key: cat=>22 cataclysm=>88 catalyst=>77 category=>66 dog=>23 + dogma=>89 dogstar=>92 sorted by val: cat=>22 dog=>23 category=>66 catalyst=>77 cataclysm=>88 + dogma=>89 dogstar=>92

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.

Replies are listed 'Best First'.
Re^10: Is there any difference between prototype % and @ ?
by LanX (Saint) on Feb 23, 2013 at 15:09 UTC
    > Show me an example of one of these mythical chains over a listified hash?

    it's a common idiom to use map to create listified hashes map { $_ => 0 } LIST

    > (One that makes some sense!)

    orthogonality always makes sense!

    (at least in the long run ... have a look into the python world)

    > Hm. You find that "obfuscated"?

    local @_ ? are you serious?

    > I always rated you as one of the more adept perlers.

    can we have a technical discussion w/o talking about persons?

    And cause you rated me, you'll maybe believe if I say that I already spend hours and days meditating about the problem to distinguish between arguments which are given as a plain list and a "list sigil" like %H or @A.

    Prototypes are just not mature enough!!!

    The optimal solution would ideally do lazy calculations. I did a talk about such constructs in Riga and GPW. But this is too much of a thread drift now.

    Cheers Rolf

      it's a common idiom to use map to create listified hashes map { $_ => 0 } LIST

      A hash is commonly initialized from a list, e.g.
          my %hash = qw(a 1  b 2  c 3);
      Does the quoted idiom do anything other than generate another list with which to initialize a hash? Can a hash so initialized be considered in any way distinct from a hash created in any other way; in particular, can it usefully be distinguished as 'listified'?

      orthogonality always makes sense!

      A hash is commonly initialized from a list as in the example given above, and a hash is seamlessly 'listified' in list context as in a statement like
          print %hash;
      or
          my @array = %hash;
      but are lists (and, by extension, arrays) really orthogonal with hashes? Despite certain conceptual similarities, my inclination would be to say no: there are just too many differences:

      • A hash can be assigned to an array and all the information inherent in the hash can be accessed and manipulated using standard array and list operators, but this is rarely anything other than an exercise in masochism;
      • An array can be assigned to a hash, but the information inherent in the array is largely destroyed thereby.

      Prototypes are just not mature enough!!!

      Amen to that, brother! Or rather, they are just not well-named enough. Had they been better named, people like myself who come from C/C++land and adjacent regions would not know instantly what they are – and be instantly wrong!

        simple test, try to chain my and BUKs implementation of hgrep, 2 in a row!

        I'll try to propose a solution for all of this including lazy lists after GPW in March.

        Cheers Rolf

      local @_ ? are you serious?

      Yes.


      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.
      it's a common idiom to use map to create listified hashes map { $_ => 0 } LIST
      1. That's not a chain.
      2. You're starting with a list and ending with a hash.

        The point being, map is being used to manipulate a list to produce another list which only becomes a hash on assignment.

        hgrep (my version at least) is starting with an existing hash; which it manipulates as pairs; and produces a list which might get assigned to construct another hash; or perhaps joined into a string; or chained into map or sort; or any other construct that takes a list.

        Your version destroys the 'hashiness' of the hash by converting it to a list before your function gets its hands on it. Which means you have to accumulate the list into an array internally in order to reconstruct the pairs; before you can manipulate it in a 'hashy' kind of way.

        So you've deconstructed the hash to a list; constructed an array from it; then destructively decomposed that array (with splice) to obtain the pairs for passing to the callback.

        My version skips all that and obtains the pairs directly from the hash using each.


      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.
        So how do you chain your implementations of hgrep and hmap?

        hgrep {...} hmap {...} %h

        ???

        Your trying to convince me that breaking the established interface is OK because there "is no use case".

        (or to be precise that I have to show a use case while you don't try to prove that there is none)

        I'm saying it's safer to respect symmetry because nobody can anticipate all use cases, not even you.

        I don't say your code doesn't make sense from a performance analysis, BUT then

        1. it should be named in a way making evident that it can't be mixed with map, grep and sort
        2. corresponding versions of map, grep and sort should be available

        A good design avoids traps and misunderstandings w/o overloading the language with edge cases!

        Cheers Rolf

        UPDATE:

        Since I thought that uneven lists should be disallowed anyway, I think it's not too dirty to consider a single argument to be a hashref.

        Like this both  hgrep \%h and hgrep %h would work and could be chained.