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 perl5.git.perl.org. 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 test.pl
- 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.
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.
[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/Dreams.pm in @INC (@INC contains: ...)
With Paul's patch, the message now reads:
Can't locate Stuff/Of/Dreams.pm 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.
Auto-chomp
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.
Refactoring t/op/lex_assign.t to use test.pl
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
test.pl. 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!
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.
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
languages.
[...]
[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
precedent.
[...]
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 "features.pm" 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 version.pm], 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
version.pm issue is that there are two code-bases. One *compiled-in*
in universal.c and the other a copy in the version.pm 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.
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
- 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 CPAN.pm client.
Weekly p5p summaries