It's time to resurrect the weekly mailing list digest tradition. And because good traditions evolve, the perl5-porters mailing list digest will now be published here, at use Perl, on Mondays.
This was a quiet week, as all weeks since the code freeze and the release candidate cycle.
Elizabeth Mattijsen suggested to consistently replace the term "discipline" by "PerlIO layer" in the docs, the two being rather equivalent (as implied by the perliol manpage, section "Layers vs Disciplines"). Nick Ing-Simmons (who wrote the largest part of the PerlIO docs) supported that, but pointed out that the Third Camel uses the term "discipline" in some places, so it should not be removed completely from the PODs.
Also from the PerlIO department : there was a longish thread (continued from the previous week) about the PerlIO::Via interface.
This module allows to define and load pure-perl PerlIO layers,
defined as classes that provide some simple tie-like interface.
(For example,
in perl 5.8.0 RC 2,
MIME::QuotedPrint provides such an interface,
allowing to read and write quoted-printable data transparently via a normal filehandle.)
The conclusion,
as summarized by Elizabeth,
was to encourage people to define such PerlIO/Via layers in the PerlIO::Via::* namespace.
I submitted a patch to make PerlIO::Via assume this default namespace prefix : thus,
when you write
open $fh, <:Via(Foo), $file
the module Foo is first searched, and if not found, perl tries to use PerlIO::Via::Foo. Elizabeth and I then moved our relevant CPAN modules from the short-lived IOLayer::* namespace to PerlIO::Via::*.
Elizabeth (again) found also a bug related to the encoding pragma. encoding allows to write perl scripts in non-ascii (or utf8) encodings. Apparently, under the effect of encoding 'utf8', when the perl tokenizer sees a string literal containing malformed utf8 data (e.g. iso-latin1), it fails silently, replacing the value of the string constant by undef (instead of, say, warning or throwing a fatal error). This apparently may lead to weird parser problems, which makes me think that this bug will not be fixed in 5.8.0.
Arthur Bergman, who has taken over Simon Cozens' optimizer module, made some statistics about the most common opcode combinations produced by the perl parser. The idea behind this is to introduce new combined opcodes during the optimization phase : for example, replacing two chained gvsv ops (i.e. scalar variable access) by a single double-gvsv op. It appears, from the first benchmark he ran, that the performance gain may be slightly noticeable.
optimizer.pm : http://search.cpan.org/search?mode=dist&query=optimizer
The statistics : http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-07/msg00084.html
Jarkko was still on the road this week, but found the time to release a snapshot while doing laundry.