Generalised "how many in list context" would be useful

[perl5.git] / pod / perltodo.pod

diff --git a/pod/perltodo.pod b/pod/perltodo.pod
index ec92a56..6698b8d 100644 (file)
--- a/pod/perltodo.pod
+++ b/pod/perltodo.pod
@@ -137,6 +137,14 @@ O.pm/B.pm backend framework depends on it.
 
 Make the peephole optimizer optional.
 
+=head2 You WANT *how* many
+
+Currently contexts are void, scalar and list. sort 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<my \$alias = \$foo>.
@@ -211,6 +219,23 @@ with Config.pm. We could use a syntax of ... for location of current binary?
 
 =head2 make HTML install work
 
+=head2 put patchlevel in -v
+
+Currently perl from p4/rsync ships with a patchlevel.h file that usually
+defines one local patch, of the form "MAINT12345" or "RC1". The output of
+perl -v doesn't report that a perl isn't an official release, and this
+information can get lost in bugs reports. Because of this, the minor version
+isn't bumped up util RC time, to minimise the possibility of versions of perl
+escaping that believe themselves to be newer than they actually are.
+
+It would be useful to find an elegant way to have the "this is an interim
+maintenance release" or "this is a release candidate" in the terse -v output,
+and have it so that it's easy for the pumpking to remove this just as the
+release tarball is rolled up. This way the version pulled out of rsync would
+always say "I'm a development release" and it would be safe to bump the
+reported minor version as soon as a release ships, which would aid perl
+developers.
+
 =head1 Incremental things
 
 Some tasks that don't need to get done in one big hit.
@@ -258,10 +283,17 @@ The old perltodo notes "Although we have C<Switch.pm> in core, Larry points to
 the dormant C<nswitch> and C<cswitch> ops in F<pp.c>; using these opcodes would
 be much faster."
 
-** Attach/detach debugger from running program
+=head2 Attach/detach debugger from running program
 
 The old perltodo notes "With C<gdb>, you can attach the debugger to a running
 program if you pass the process ID. It would be good to do this with the Perl
 debugger on a running Perl program, although I'm not sure how it would be done."
 ssh and screen do this with named pipes in tmp. Maybe we can too.
 
+=head2 A decent benchmark
+
+perlbench 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.