=head1 NAME
todo - Perl TO-DO list
=head1 DESCRIPTION
This is a list of wishes for Perl. The most up to date version of this file
is at L
The tasks we think are smaller or easier are listed first. Anyone is welcome
to work on any of these, but it's a good idea to first contact
I to avoid duplication of effort, and to learn from
any previous attempts. By all means contact a pumpking privately first if you
prefer.
Whilst patches to make the list shorter are most welcome, ideas to add to
the list are also encouraged. Check the perl5-porters archives for past
ideas, and any discussion about them. One set of archives may be found at
L
What can we offer you in return? Fame, fortune, and everlasting glory? Maybe
not, but if your patch is incorporated, then we'll add your name to the
F file, which ships in the official distribution. How many other
programming languages offer you 1 line of immortality?
=head1 Tasks that need only a little Perl knowledge
=head2 Fix POD errors in Perl documentation
Perl documentation is furnished in POD (Plain Old Documentation); see
L. We also have a utility that checks for various errors in
this documentation: F. Unfortunately many files
have errors in them, and there is a database of known problems, kept in
F. The most prevalent errors are lines
too wide to fit in a standard terminal window, but there are more
serious problems as well; and there are items listed there that are not
in fact errors. The task would be to go through and clean up the
documentation. This would be a good way to learn more about Perl.
=head1 Tasks that only need Perl knowledge
=head2 Classify bug tickets by type
Known bugs in Perl are tracked by L (which also
includes Perl 6). A summary can be found at
L.
It shows bugs classified by "type". However, the type of many of the
bugs is "unknown". This greatly lowers the chances of them getting
fixed, as the number of open bugs is overwhelming -- too many to wade
through for someone to try to find the bugs in the parts of
Perl that s/he knows well enough to try to fix. This task involves
going through these bugs and classifying them into one or more types.
=head2 Ongoing: investigate new bug reports
When a bug report is filed, it would be very helpful to have someone do
a quick investigation to see if it is a real problem, and to reply to
the poster about it, asking for example code that reproduces the
problem. Such code should be added to the test suite as TODO tests, and
the ticket should be classified by type. To get started on this task,
look at the tickets that are marked as "New Issues" in
L.
=head2 Migrate t/ from custom TAP generation
Many tests below F still generate TAP by "hand", rather than using library
functions. As explained in L, tests in F are
written in a particular way to test that more complex constructions actually
work before using them routinely. Hence they don't use C, but
instead there is an intentionally simpler library, F. However,
quite a few tests in F have not been refactored to use it. Refactoring
any of these tests, one at a time, is a useful thing TODO.
The subdirectories F, F and F, that contain the most
basic tests, should be excluded from this task.
=head2 Automate perldelta generation
The perldelta file accompanying each release summaries the major changes.
It's mostly manually generated currently, but some of that could be
automated with a bit of perl, specifically the generation of
=over
=item Modules and Pragmata
=item New Documentation
=item New Tests
=back
See F for details.
=head2 Make Schwern poorer
We should have tests for everything. When all the core's modules are tested,
Schwern has promised to donate to $500 to TPF. We may need volunteers to
hold him upside down and shake vigorously in order to actually extract the
cash.
=head2 Write descriptions for all tests
Many individual tests in the test suite lack descriptions (or names, or labels
-- call them what you will). Many files completely lack descriptions, meaning
that the only output you get is the test numbers. If all tests had
descriptions, understanding what the tests are testing and why they sometimes
fail would both get a whole lot easier.
=head2 Improve the coverage of the core tests
Use Devel::Cover to ascertain the core modules' test coverage, then add
tests that are currently missing.
=head2 test B
A full test suite for the B module would be nice.
=head2 A decent benchmark
C seems impervious to any recent changes made to the perl core. It
would be useful to have a reasonable general benchmarking suite that roughly
represented what current perl programs do, and measurably reported whether
tweaks to the core improve, degrade or don't really affect performance, to
guide people attempting to optimise the guts of perl. Gisle would welcome
new tests for perlbench. Steffen Schwingon would welcome help with
L
=head2 fix tainting bugs
Fix the bugs revealed by running the test suite with the C switch (via
C).
=head2 Dual life everything
As part of the "dists" plan, anything that doesn't belong in the smallest perl
distribution needs to be dual lifed. Anything else can be too. Figure out what
changes would be needed to package that module and its tests up for CPAN, and
do so. Test it with older perl releases, and fix the problems you find.
To make a minimal perl distribution, it's useful to look at
F.
=head2 POSIX memory footprint
Ilya observed that use POSIX; eats memory like there's no tomorrow, and at
various times worked to cut it down. There is probably still fat to cut out -
for example POSIX passes Exporter some very memory hungry data structures.
=head2 makedef.pl and conditional compilation
The script F that generates the list of exported symbols on
platforms which need this. Functions are declared in F, variables
in F. Quite a few of the functions and variables are conditionally
declared there, using C. However, F doesn't understand the
C macros, so the rules about which symbols are present when is duplicated in
the Perl code. Writing things twice is bad, m'kay. It would be good to teach
F to understand the conditional compilation, and hence remove the
duplication, and the mistakes it has caused.
=head2 use strict; and AutoLoad
Currently if you write
package Whack;
use AutoLoader 'AUTOLOAD';
use strict;
1;
__END__
sub bloop {
print join (' ', No, strict, here), "!\n";
}
then C isn't in force within the autoloaded subroutines. It would
be more consistent (and less surprising) to arrange for all lexical pragmas
in force at the __END__ block to be in force within each autoloaded subroutine.
There's a similar problem with SelfLoader.
=head2 profile installman
The F script is slow. All it is doing text processing, which we're
told is something Perl is good at. So it would be nice to know what it is doing
that is taking so much CPU, and where possible address it.
=head2 enable lexical enabling/disabling of individual warnings
Currently, warnings can only be enabled or disabled by category. There
are times when it would be useful to quash a single warning, not a
whole category.
=head2 document diagnostics
Many diagnostic messages are not currently documented. The list is at the end
of t/porting/diag.t.
=head2 Write TODO tests for open bugs
Sometimes bugs get fixed as a side effect of something else, and
the bug remains open because no one realizes that it has been fixed.
Ideally, every open bug should have a TODO test in the core test suite.
=head1 Tasks that need a little sysadmin-type knowledge
Or if you prefer, tasks that you would learn from, and broaden your skills
base...
=head2 make HTML install work
There is an C target in the Makefile. It's marked as
"experimental". It would be good to get this tested, make it work reliably, and
remove the "experimental" tag. This would include
=over 4
=item 1
Checking that cross linking between various parts of the documentation works.
In particular that links work between the modules (files with POD in F)
and the core documentation (files in F)
=item 2
Improving the code that split C into chunks, preferably with
general case code added to L that could be used elsewhere.
Challenges here are correctly identifying the groups of functions that go
together, and making the right named external cross-links point to the right
page. Currently this works reasonably well in the general case, and correctly
parses two or more C<=items> giving the different parameter lists for the
same function, such used by C. However it fails completely where
I functions are listed as a sequence of C<=items> but share the
same description. All the functions from C to C have
individual stub pages, with only the page for C holding the
description common to all. Likewise C, C and C have stub pages,
instead of sharing the body of C.
Note also the current code isn't ideal with the two forms of C

would be roughly equivalent to:
do { local $"='|'; /\b(?:P)\b/ }
See
L
for the discussion.
=head2 optional optimizer
Make the peephole optimizer optional. Currently it performs two tasks as
it walks the optree - genuine peephole optimisations, and necessary fixups of
ops. It would be good to find an efficient way to switch out the
optimisations whilst keeping the fixups.
=head2 You WANT *how* many
Currently contexts are void, scalar and list. split has a special mechanism in
place to pass in the number of return values wanted. It would be useful to
have a general mechanism for this, backwards compatible and little speed hit.
This would allow proposals such as short circuiting sort to be implemented
as a module on CPAN.
=head2 lexical aliases
Allow lexical aliases (maybe via the syntax C).
=head2 Self-ties
Self-ties are currently illegal because they caused too many segfaults. Maybe
the causes of these could be tracked down and self-ties on all types
reinstated.
=head2 Optimize away @_
The old perltodo notes "Look at the "reification" code in C".
=head2 Virtualize operating system access
Implement a set of "vtables" that virtualizes operating system access
(open(), mkdir(), unlink(), readdir(), getenv(), etc.) At the very
least these interfaces should take SVs as "name" arguments instead of
bare char pointers; probably the most flexible and extensible way
would be for the Perl-facing interfaces to accept HVs. The system
needs to be per-operating-system and per-file-system
hookable/filterable, preferably both from XS and Perl level
(L is good reading at this point,
in fact, all of L is.)
This has actually already been implemented (but only for Win32),
take a look at F and F. While all Win32
variants go through a set of "vtables" for operating system access,
non-Win32 systems currently go straight for the POSIX/Unix-style
system/library call. Similar system as for Win32 should be
implemented for all platforms. The existing Win32 implementation
probably does not need to survive alongside this proposed new
implementation, the approaches could be merged.
What would this give us? One often-asked-for feature this would
enable is using Unicode for filenames, and other "names" like %ENV,
usernames, hostnames, and so forth.
(See L.)
But this kind of virtualization would also allow for things like
virtual filesystems, virtual networks, and "sandboxes" (though as long
as dynamic loading of random object code is allowed, not very safe
sandboxes since external code of course know not of Perl's vtables).
An example of a smaller "sandbox" is that this feature can be used to
implement per-thread working directories: Win32 already does this.
See also L"Extend PerlIO and PerlIO::Scalar">.
=head2 repack the optree
Repacking the optree after execution order is determined could allow
removal of NULL ops, and optimal ordering of OPs with respect to cache-line
filling. I think that
the best way to do this is to make it an optional step just before the
completed optree is attached to anything else, and to use the slab allocator
unchanged--but allocate a single slab the right size, avoiding partial
slabs--, so that freeing ops is identical whether or not this step runs.
Note that the slab allocator allocates ops downwards in memory, so one would
have to actually "allocate" the ops in reverse-execution order to get them
contiguous in memory in execution order.
See
L
Note that running this copy, and then freeing all the old location ops would
cause their slabs to be freed, which would eliminate possible memory wastage if
the previous suggestion is implemented, and we swap slabs more frequently.
=head2 eliminate incorrect line numbers in warnings
This code
use warnings;
my $undef;
if ($undef == 3) {
} elsif ($undef == 0) {
}
used to produce this output:
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
where the line of the second warning was misreported - it should be line 5.
Rafael fixed this - the problem arose because there was no nextstate OP
between the execution of the C and the C, hence C still
reports that the currently executing line is line 4. The solution was to inject
a nextstate OPs for each C, although it turned out that the nextstate
OP needed to be a nulled OP, rather than a live nextstate OP, else other line
numbers became misreported. (Jenga!)
The problem is more general than C (although the C case is the
most common and the most confusing). Ideally this code
use warnings;
my $undef;
my $a = $undef + 1;
my $b
= $undef
+ 1;
would produce this output
Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
(rather than lines 4 and 5), but this would seem to require every OP to carry
(at least) line number information.
What might work is to have an optional line number in memory just before the
BASEOP structure, with a flag bit in the op to say whether it's present.
Initially during compile every OP would carry its line number. Then add a late
pass to the optimiser (potentially combined with L) which
looks at the two ops on every edge of the graph of the execution path. If
the line number changes, flags the destination OP with this information.
Once all paths are traced, replace every op with the flag with a
nextstate-light op (that just updates C), which in turn then passes
control on to the true op. All ops would then be replaced by variants that
do not store the line number. (Which, logically, why it would work best in
conjunction with L, as that is already copying/reallocating
all the OPs)
(Although I should note that we're not certain that doing this for the general
case is worth it)
=head2 optimize tail-calls
Tail-calls present an opportunity for broadly applicable optimization;
anywhere that C<< return foo(...) >> is called, the outer return can
be replaced by a goto, and foo will return directly to the outer
caller, saving (conservatively) 25% of perl's call&return cost, which
is relatively higher than in C. The scheme language is known to do
this heavily. B::Concise provides good insight into where this
optimization is possible, ie anywhere entersub,leavesub op-sequence
occurs.
perl -MO=Concise,-exec,a,b,-main -e 'sub a{ 1 }; sub b {a()}; b(2)'
Bottom line on this is probably a new pp_tailcall function which
combines the code in pp_entersub, pp_leavesub. This should probably
be done 1st in XS, and using B::Generate to patch the new OP into the
optrees.
=head2 Add C<0odddd>
It has been proposed that octal constants be specifiable through the syntax
C<0oddddd>, parallel to the existing construct to specify hex constants
C<0xddddd>
=head2 Revisit the regex super-linear cache code
Perl executes regexes using the traditional backtracking algorithm, which
makes it possible to implement a variety of powerful pattern-matching
features (like embedded code blocks), at the cost of taking exponential time
to run on some pathological patterns. The exponential-time problem is
mitigated by the I, which detects when we're processing
such a pathological pattern, and does some additional bookkeeping to avoid
much of the work. However, that code has bit-rotted a little; some patterns
don't make as much use of it as they should. The proposal is to analyse
where the current cache code has problems, and extend it to cover those cases.
See also
L
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
of 5.18.2"
=head2 make ithreads more robust
Generally make ithreads more robust.
This task is incremental - even a little bit of work on it will help, and
will be greatly appreciated.
One bit would be to determine how to clone directory handles on systems
without a C function (in sv.c:Perl_dirp_dup).
Fix Perl_sv_dup, et al so that threads can return objects.
=head2 Add class set operations to regexp engine
Apparently these are quite useful. Anyway, Jeffery Friedl wants them.
demerphq has this on his todo list, but right at the bottom.
=head1 Tasks for microperl
[ Each and every one of these may be obsolete, but they were listed
in the old Todo.micro file]
=head2 do away with fork/exec/wait?
(system, popen should be enough?)
=head2 some of the uconfig.sh really needs to be probed (using cc) in buildtime:
(uConfigure? :-) native datatype widths and endianness come to mind