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.