Perl 5 Porters Weekly: September 24-September 30, 2012

[ cross posted from its original blog ]

Welcome to Perl 5 Porters Weekly, a summary of the email traffic on the perl5-porters email list. In case you missed hearing about it, don't forget to sign up for Gabor Szabo's Perl Maven programming contest.

This week's dusty thread is from the week of July 30, 2012. Pumpking Ricardo Signes was looking for volunteer(s) to do some hacking on a gitalist installation hosted on Read about the details here. Are you interested? Contact Rik.

Topics this week include:

  • Perl 5.14.3 RC1
  • JROBINSON grant report #10, #11
  • [PATCH] Suggest cause of error requiring .pm file
  • Auto-chomp
  • Refactoring t/op/lex_assign.t to use
  • Why is Filter::Simple in core distribution?
  • Features and keywords versus namespaces and functions
  • Taking CPANPLUS out of core

Perl 5.14.3 RC1

Dominic Hargreaves announced that the first release candidate of Perl 5.14.3 has been posted to a CPAN mirror near you.

Read the announcement

Read perldelta

JROBINSON grant report #10, #11

Jess Robinson has been working on a grant project to get Perl crosscompiling on the Android platform. She reported that she was able to get perl-5.17.4 into an Android package file (.apk) Hopefully she will be ready to start running the Perl test harness in future work.

Read the announcement

[PATCH] Suggest cause of error requiring .pm file

Paul Johnson submitted a patch to implement the discussed changes to the error Perl emits when a module can't be loaded. The current message reads:

Can't locate Stuff/Of/ in @INC (@INC contains: ...)

With Paul's patch, the message now reads:

Can't locate Stuff/Of/ in @INC (did you install the
Stuff::Of::Dreams module?) (@INC contains: ...)

He tested this patch by installing Task::Kensho, Catalyst, Dancer and some other modules without problems.

Read the thread


David Golden mused that he'd likely want a PerlIO layer that auto-chomped newlines from input. Leon Timmermans wrote:

Given the current PerlIO, that is effectively impossible. It would be
a useful datapoint for a readline rewrite though.

There was some further discussion about given/when and smartmatch utility (or lack thereof.) Using a new thread, David Golden wrote:

Overall, I find it sort of ugly that we have three things that are all
effectively the same:

    foreach ( $foo ) { ... }
    given ( $foo ) { ... }
    for ( $foo ) { ... }

The remaining benefit of given() is that it doesn't have any loop
setup overhead and it has a return value (though it needs to be
wrapped in do {...}):

    my $value = do { given ( $foo ) { ... } };

Is that really worth having another keyword?  Could for/foreach return
a value similarly (without overhead in void context)?  Could
for(SCALAR) be optimized to avoid the loop setup?  If we could do away
with given(), I'd prefer to see it removed.

when() feels more generally useful and I'm starting to question if we
need to keep given().  And I'm neutral to negative about smartmatch
now, so when() as an "if with implicit next" is the remaining thing
that interests me.

Read the thread

Refactoring t/op/lex_assign.t to use

As I noted back on June 17, Colin Kuskie has been refactoring various pieces of the Perl test harness over the past several months. He wrote:

I'm about done with the original list of files targeted for migration to  It's probably time to review that list, and do a second sweep to 
cover any newly added tests.

And Ricardo Signes added:

Thanks very much for this work, which is neither glamorous nor (I imagine) a
boatload of fun.  It *is* appreciated!

Read the thread

Why is Filter::Simple in core distribution?

James Keenan asked why Filter::Simple is still in Perl's core distribution. The general consensus seems to be that it should be moved to CPAN-only status.

Read the thread

Features and keywords versus namespaces and functions

Yves Orton started an interesting thread about adding new functionality via keywords or via functions in a special purpose namespace (i.e., scalar::weaken) because Yves has some contributions he'd like to put into a specialized namespace, rather than as some kind of new language keyword.

[A]s I understand the feature/keyword approach is required when
the change involves modifying how Perl code is parsed. For example
adding a new infix operator has the potential of breaking code that
uses the same token as a function name or worse cause it to be
interpreted in entirely new ways without breaking.

Namespaces on the other hand exist to work around the problem of
function name collisions. They are the standard way to add library
code to an application in Perl and virtually all other modern


[W]e currently *do* have a number of built in routines in specialized
namespaces, and indeed some of those were not even put in reserved
namespaces, so they could quite easily have broken code when they were
added yet if they did it was seen as a minor issue. This is not a new


So to repeat for clarity: Under what circumstances should the Perl
language be extended via new keywords and features and under what
circumstances should it be extended via functions and namespaces?

David Golden replied:

I think you left out an important distinction:  "Which are available by
default and how?"

My hypothesis is that the desire for "features" is linked to the
desire for sticking it in "" which means that "use v5.NN"
gives a better set of defaults.


I don't want to then add a whole bunch more imports for things that I
think should be available by default.

Jesse Luehrs added:

I think this is slightly missing the point. The question is, do we want
functions added to the language to be more like 'say', or more like
'utf8::encode'? utf8::encode is available by default (doesn't require a
use statement), and doesn't require a feature because it's not in the
main namespace.

Yves agreed that was his point exactly. He also clarified that the Perl 'use 5.0xx' pragmata should import a sensible set of default features regardless of their implementation. He feels that using namespaces addresses backwards compatibility in a much better way than a new keyword.

David Golden wrote that he disagreed the namespace approach addresses backwards compatibility "better" than any other:

I respect that you feel what I'm saying is FUD, but I hope you
understand that I've personally suffered the pains of attempted
back-emulation [in], so at least I speak from experience and
we can agree to disagree over the probability that it will happen again.

But let me step back a second.  We have *plenty* of dual-life modules
and we live with the compatibility issues already.  I think the issue is that there are two code-bases.  One *compiled-in*
in universal.c and the other a copy in the source (plus
some PP/XS trickery).  That does have a maintenance burden as John
Peacock and I and others working on it have seen.


I think these debates are much more about what should be available by
default and not so much about the implementations.

Read the thread

Taking CPANPLUS out of core

Sawyer X wrote that he wanted to tackle an item on Rik's perltodo document, deprecating CPANPLUS and its module dependencies. He did a good bit of research to find what CPANPLUS dependencies can be safely removed and came up with this list:

  • File::Fetch
  • Term::UI
  • Module::Pluggable
  • Object::Accessor
  • Log::Message
  • Log::Message::Simple
  • Module::Loaded
  • Locale::Maketext::Simple
  • Archive::Extract
  • Params::Check
  • Module::Load::Conditional
  • IPC::Cmd
  • CPANPLUS::Dist::Build

The primary objections seemed to boil down to wanting to keep certain dependencies in core anyway (such as File::Fetch and IPC::Cmd) and that CPANPLUS seemed to be more reliable on certain platforms (e.g., VMS) than the client.

Read the original thread

Read the followup thread

About Perl 5 Porters Summaries

user-pic Weekly p5p summaries