Welcome to Perl 5 Porters Weekly, a summary of the traffic on the perl core mailing list. There were quite a few interesting emails sent last week, so let’s get to them! But first, check out this week’s perl history tidbit:
pack features added to
#perl for the Magellan probe – perl5.git.perl.org/perl.git/blobd… – ain’t history awesome!— Matt S Trout (@shadowcat_mst) August 23, 2012
Reminds me of this week’s P5P quote of the week from Aristotle Pagaltzis who wrote:
One day we shall be able to boast that “Perl 5 has *dropped*
support for more platforms than your language has ever *had*”. 
Topics this week include:
- RFC: pack()ing long words
- jemalloc
- fixing smartmatch just hard enough (and when, too)
- deprecate and remove microperl
- UTS dispatched to the glue factory
- Seeking guidance on Benchmarking and potentially removing swash caching
RFC: pack()ing long words
David Cantrell asked for feedback about a proposal to extend pack/unpack to permit arbitrary length words (16 byte words, or 3 byte words or what have you.) To that end, he proposed an extension to the pack format string. People thought that was a good idea, but proposed some alternate formatting strings.
jemalloc
Nicholas Clark wrote about an experimental replacement of perl’s current malloc implementation with jemalloc, a BSD licensed high performance malloc routine used by Facebook and FreeBSD. More research is warranted but Nicholas doesn’t feel he has the time to do so right now – anyone want to play around with this idea?
fixing smartmatch just hard enough (and when, too)
As you may already know, Ricardo Signes posted a longish email about fixing smartmatch by eliminating a bunch of corner and edge use cases and adding Perl 6 style junctions into Perl 5. Specifically, the number of legal smartmatches goes from 31 cases down to 7 and Rik proposes using junctions to replace the array and hash membership smartmatch use cases.
You probably won’t be surprised to learn that this thread was extremely popular and overall sentiment seems to be largely favorable. I wanted to highlight a few of the email responses to Rik’s original mail.
Abigail wrote:
For me, one of the few advantages I saw in using ~~ is not having to
wonder when to use == vs eq vs =~. The above table suggests that
"0.0" ~~ 0
is false, while it's currently true. That bothers me. IMO, a "smart match"
should be able to say, "hmmm, both my operands look like numbers, you know
what, I'll use '==' to compare them!"
Damian Conway wrote (in part):
My point is that if even the original proponent of smartmatching can't
use it without RTFM-ing, how can we consider the current arrangement
anything but broken? And how can reducing the current table+special cases
from 31 to 7 be anything but a vast improvement?
My one point of disagreement with Rick's current proposal is that,
like Abigail, I feel it's essential for smartmatching (and hence 'when')
to handle matching numbers sensibly. And by sensibly, I mean "not with eq".
Father Chrysostomos took the opportunity to find and fix a JAPH:
Damian Conway probably regrets writing:
> In contrast, a set of curlys is *never* a block when it's the only thing in a
> set of parens...it's always a hash constructor).
Heeheehee.
I just fixed this in bleadperl:
format =
@*
({ "Just another Perl hacker, " })
.
write
deprecate and remove microperl
In response to a bug report about microperl from an embedded Linux project, Nicholas Clark proposed deprecating and removing “microperl” from perl core. As Nicholas explains in the email, microperl has nothing to do with “small” sized perl (as one might want in an embedded project), and everything to do with an experiment with perl’s build tool chain that didn’t work out.
UTS dispatched to the glue factory
UTS was a mainframe OS created by Amdahl and hasn’t been touched since perl 5.8.0. Nicholas Clark committed a patch set which removed all of the UTS support from the code base.
Seeking guidance on Benchmarking and potentially removing swash caching
Karl Williamson explained that Perl stores Unicode properties and bracketed character classes in a data structure called swashes. A swash is a hash with a few keys, but one of the problems using a hash is that it may grow very large, so Karl proposed using a binary search instead. His experimental implementation shows a slight performance improvement on an already fast operation because it’s a C based binary search on a C array. He asked if anyone had ideas for further testing or guidance on implementation.