Perl 5 Porters Weekly: August 20-August 26, 2012
[ Cross posted from its home blog ]
Welcome to Perl 5 Porters Weekly, a summary of the email traffic on the perl-5-porters email list. Sorry I'm running a bit behind this week; there was really a tremendous volume of email this week, mostly about Ricardo's changes to smartmatch and the given/when syntax. Since that's the case, I'm going to put all of the non-smartmatch mail first, and a good sampling of the discussion around smartmatch at the end.
Topics this week include:
- Perl 5.17.3 is now available!
- Parrot 4.7.0 "Hispaniolan" Released
- Slowdown in longer hash keys
- changing Devel::Peek so it doesn't unconditionally print to STDERR
- The latest Unicode 6.2 beta is now in blead
- The great smartmatch summary
Perl 5.17.3 is now available!
Steve Hay announced that Perl 5.17.3 is now available on a CPAN mirror near you.
Read the announcement
Read perldelta for 5.17.3
Parrot 4.7.0 "Hispaniolan" Released
Andrew Whitworth announced that Parrot 4.7.0 was now available.
Slowdown in longer hash keys
Karl Williamson reported that he was surprised to discover that a long hash key name significantly impacted performance of his hash lookups. (This was part of profiling work being done as part of Karl's research into replacing perl's current Unicode data structures with one that is potentially faster for lookups in the common cases. See this thread for more details.)
Later Yves Orton experimented with replacing the Perl hash bucket generator with a new algorithm and was puzzled by unrelated test failures downstream. But he also thinks there is a big opportunity to simply call the C code that generates hashes much less frequently than currently is done.
changing Devel::Peek so it doesn't unconditionally print to STDERR
Rocky Bernstein writes that he's been working on a new debugger for Perl code and would like to submit patches for Devel::Peek that make its STDERR printing behavior optional. (For example, if a Devel::Peek session were attached to a socket, writing to STDERR would be quite silly.)
Later Rocky submitted the patches to implement this behavior.
The latest Unicode 6.2 beta is now in blead
Karl Williamson also announced that the latest Unicode 6.2 beta is in blead.
The great smartmatch summary
Unsurprisingly, this topic remains a very popular one. In particular there were a number of thoughts about how smartmatching ought to resolve potentially ambiguous situations involving overloaded objects on the right-hand side or the left-hand side, as well as the ever popular "stringy" comparison using "eq" and the "numberish" comparison using "==". By midweek, Damian Conway had summarized his preferences in a neat table incorporating suggestions from various posters including David Golden, Jesse Luehrs and others.
Smartmatch (~~) table
=====================
$a $b Meaning
===== =================== ========================
~~-ol Any [1] $a->ol_method($b)
Any ~~-ol [1] $b->ol_method($a, 'rev')
Any undef ! defined $a
Any CodeRef, &{}-ol $b->($a)
Any Regexp, qr-ol $a =~ $b
Any Num, 0+-ol [2] $a == $b
Any Str, ""-ol [3] $a eq $b
Any Any undef (with fatalizable warning)
[1] Includes junctions, whose overloading distributes the
smartmatch over their elements in their several ways.
[2] $b is smartmatched as a Num only if it is unambiguously numeric.
That is, if and only if at least one of the following is true:
a. $b contains an object with overloaded numerification,
but no overloaded stringification;
b. $b has an internal numeric representation
but no internal string representation;
c. some (as-yet theoretical) internal flag indicates that
$b originally had only an internal numeric representation.
[3] $b is smartmatched as a Str only if it is unambiguously stringy.
That is, if and only if at least one of the following is true:
a. $b contains an object with overloaded stringification,
but no overloaded numerification;
b. $b has an internal string representation
but no internal numeric representation;
c. some (as-yet theoretical) internal flag indicates that
$b originally had only an internal string representation.
______________________________________________________________________
The when construct
==================
Form Meaning
================== ==================================
when (EXPR) {...} if ($_ ~~ (EXPR)) {...; break}
when {BLOCK} {...} if ($_ ~~ sub{BLOCK}) {...; break}
No exceptions.
No special cases.
On Friday, David Golden posted his thoughts about why an improved smartmatch and when construct are useful parts of Perl.
Just to step back, I thought I'd mention why I think smartmatch is a useful
feature given all the ambiguity we're discussing.
(1) It's a generic "test" operator
It's effectively $rhs->test($lhs). It makes it easier to work with a
collection of test "objects" without having to interrogate each one to know
how to resolve the test.
[...]
(2) It allows less verbose "switch" constructs with "when"
Instead of a long chain like this:
if ( $lhs == 0 ) { ... }
elsif ( $lhs == 1 ) { ... }
elsif ( $lhs == 2 ) { ... }
...
else { ... }
We get to avoid writing "$lhs ==" in every clause by using the generic
match instead:
when (0) { ... }
when (1) { ... }
when (2) { ... }
default { ... }
That's less verbose, so easier to read.
There were still comments to the effect that even an improved smartmatch really isn't all that much better (and may even be worse than) a standard if .. elsif .. else block.
On Sunday night, Father Chrysostomos posted a proposal to deprecate smartmatch entirely and put a small layer of syntactic sugar around the when construct:
Do we really need smart match at all?
The three advantages to smart match I’ve seen are:
• Junctive operations: ~~ @foo
• Accepting qr// or sub{} from the caller and using it on the rhs
• when(3) which is nice and short.
(I don’t consider ‘we need a generic way of asking whether two objects
match’ to be valid, because ‘match’ on its own is meaningless.)
The first one we’ve solved with Perl6::Junction.
The second one I don’t feel comfortable with at all. It is a very specific
use case. Wrapping qr//s in sub{} I would consider the correct approach.
The problem with any interface that accepts qr//-or-sub{} is that classes
implementing one type of overloading can’t add the other without potentially
breaking things. So it makes module authors’ lives harder. I’m simply not
convinced that this feature is a pressing need. We already have generic
matchers. They are called subs.
The third one actually has nothing to do with smart match at all. It’s a
‘when’ problem. If we really really don’t want to have to write when($_==3),
then we could copy the precedent set by flipflop and split.
if (1..2) means if ($.==1 .. $.==2)
split ' ' is special
$x = ' '; split $x does something different
and implement two syntactic special cases:
# literal numbers
when(0)
when(1)
when(0xff)
when(0b101110)
when(023476)
# literal strings
when('foo')
when("foo")
when(q "foo")
when(qq "foo")
and *nothing* else. Everything else would be a boolean, including
when($foo). Anything else is madness; it really is.
Then we can just deprecate ~~.
Those who say they want
when(num(3))
can write
sub num { $_ == $_[0] }
instead of
sub num { my $arg = shift; sub { $_[0] == $arg } }
which I think is an improvement.
But that doesn’t work with lexical $_, so let’s deprecate that, too.
(And make when do a simple next, and make given respond to next.)
Ricardo's response to this proposal was posted on August 28, so you'll just have to read next week's summary to see it! (How's that for a cliff hanger? :))
Weekly p5p summaries
lotta thanks for putting that together
Welcome! Sort of :)