Re^11: Is there any difference between prototype % and @ ?

[BrowserUk]

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.

[LanX]

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!

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.

[BrowserUk]

So how do you chain your implementations of hgrep and hmap? hgrep {...} hmap {...} %h ???

You don't. It doesn't make sense to chain the output of a function producing a list to the input of a function taking a hash.

If you need to post-process the output from hmap with grep, use grep.

There is no way to have hmap return a hash, or a hash reference, because the user decides what is returned from the callback. And what tehy return may make no sense as a hash at all.

If you need to post process the output from hgrep with map; use map.

Whilst it would be possible to construct a new hash from those pairs for which the user callback returns true; if you do so, and the user wants to post process the output as a list with map; or print it as a list; or assign it to an array or hash; then they then have to deconstruct the hash(ref) to do so.

Ie. the h stands for head (of the chain) as well as hash.

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

And symmetry for its own sake is just pretty, pretty. Orthogonality where it makes sense ... makes sense; but otherwise it does not. And so far; neither you nor I have come up with a use case. But we are both aware of the many use cases for the output being a list.

In an ideal world, it would be a list of pairs. But you cannot initialise another hash from a list of pairs; and nothing else in Perl knows what to do with them either. I guess that hgrep hmap could output a list of pairs, and accept a list of pairs; and then have another function that flattens them (for assignment to a new hash. But it adds a 'final' function to the chain which is a cost; and as yet I see no benefit accruing from it.

That not to say that there isn't some potential use for using context (eg. wantarray) to decide whether to produce a normal list or (say) a hashref. Given a use case.

But I can see no point in building a hash(ref) for output if the next function in the chain is going to immediately deconstruct it to a list or list of pairs.

[LanX]

> And so far; neither you nor I have come up with a use case.

trivial example

%salary=(
     boss      => 1_000,
     secretary => 300,
     admin     => 600,
     janitor   => 150,
    );

print
  map {"$_ earns $salary{$_} \n" }
  sort { $salary{$a} <=> $salary{$b} }
  grep { $salary{$_} > 500 }
  keys %salary;

translating it to hmap, hsort and hgrep is left as an excercise.