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

[LanX]

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

[AnomalousMonk]

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!

[LanX]

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.

[BrowserUk]

local @_ ? are you serious?

Yes.

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