Skip Menu |

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 66269
Status: rejected
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: volodymyr.velyky [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: prototype on mesh ill-advised
Date: Mon, 28 Feb 2011 20:47:11 -0700
To: bug-List-MoreUtils [...] rt.cpan.org
From: Nathan Rasmussen <volodymyr.velyky [...] gmail.com>
List::MoreUtils 0.30 All versions of Perl All operating systems The prototype of mesh (a.k.a. zip) reads as follows: (\@\@;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@) It would be better removed entirely. I propose two advantages to doing so: First, its sham variadicity violates the principle of 'no arbitrary limits', setting up a nasty surprise for the unfortunate user who wishes to zip more than 32 arrays together. With no prototype, it is truly variadic and contains no secret threshold of failure. Second, its backslashed prototype entries disable the dynamicity of Perl by requiring literal arguments with the @ sigil. If the user does not know in advance exactly how many lists will need to be zipped, the only option is to privately reimplement mesh() without the sigil (which I have just done for exactly that reason). Costs of removing the prototype are as follows: Addition of a backslash before each argument to mesh() in existing code. Breaks cross-version code compatibility. Loss of compile-time verification that each argument is an array. Rebuttals to cost statements: Addition of backslashes to mesh arguments is trivially easy. Persevering in an error does not rectify anything. Shall we perhaps wait fearfully to fix it until *more* code depends on the current behavior? Or shall we trust that our audience, the sort of Perl hackers who use an enhanced list processing module, are already adequate to face the change? To ensure that a function or operator receives the correct type of value is not a novel challenge. It is the common labor of design in Perl or any other value-typed language. Responsibility for correctness lies with a clear design, not with a mechanistic type-checking ritual. Even a poor design, one that might supply a mixture of arrayrefs and other scalars, can be kept from breaking unprototyped mesh() by putting the argument list through grep {ref eq 'ARRAY'} first. Making hard things easy is a higher value among Perl hackers than making stupid things difficult, and so simplicity and flexibility, which we stand to gain from a true list-of-lists argument structure, outweigh the superficial comfort that we stand to lose with compile-time checking. Concluding unscientific postscript: The precedence of mesh() will also be unchanged, since it parses as a list operator either way.
Hi, proving all RT's is scheduled after I finished Proc::ProcessTable rewrite. Please understand that I will try to fix as many issues as possible with one real developing action.
Removing the prototype will cause code like @foo = mesh @a, @b, @c; fail. Regardless how right you're entire arguements are - changing behavior is _bad_. I'm an asshole, but no bad asshole ;) Thanks for reporting and sorry for being an asshole. Cheers, Jens
Subject: Re: [rt.cpan.org #66269] prototype on mesh ill-advised
Date: Wed, 20 Apr 2016 13:44:14 -0400
To: bug-List-MoreUtils [...] rt.cpan.org
From: Nathan Rasmussen <volodymyr.velyky [...] gmail.com>
You are correct about changing behavior. We need assholes when they're correct. OTOH, maybe we also need a mesh utility that really is variadic. It would have to take arrayref arguments, so it could be called ref_mesh() perhaps. Best wishes!
Sure, but I'd like to see a nice proposal (maybe with a patch) in another ticket ;) mash can then call mesh_ref (a really suitable name would be nice, either :D)