=head1 DESCRIPTION
-This is a list of wishes for Perl. 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<perl5-porters@perl.org> to
-avoid duplication of effort, and to learn from any previous attempts.
-By all means contact a pumpking privately first if you prefer.
+This is a list of wishes for Perl. The most up to date version of this file
+is at http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/pod/perltodo.pod
+
+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<perl5-porters@perl.org> 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
=head1 Tasks that only need Perl knowledge
+=head2 Smartmatch design issues
+
+In 5.10.0 the smartmatch operator C<~~> isn't working quite "right". But
+before we can fix the implementation, we need to define what "right" is.
+The first problem is that Robin Houston implemented the Perl 6 smart match
+spec as of February 2006, when smart match was axiomatically symmetrical:
+L<http://groups.google.com/group/perl.perl6.language/msg/bf2b486f089ad021>
+
+Since then the Perl 6 target moved, but the Perl 5 implementation did not.
+
+So it would be useful for someone to compare the Perl 6 smartmatch table
+as of February 2006 L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?view=markup&pathrev=7615>
+and the current table L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?revision=14556&view=markup>
+and tabulate the differences in Perl 6. The annotated view of changes is
+L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?view=annotate> and the diff is
+C<svn diff -r7615:14556 http://svn.perl.org/perl6/doc/trunk/design/syn/S03.pod>
+-- search for C<=head1 Smart matching>. (In theory F<viewvc> can generate that,
+but in practice when I tried it hung forever, I assume "thinking")
+
+With that done and published, someone (else) can then map any changed Perl 6
+semantics back to Perl 5, based on how the existing semantics map to Perl 5:
+L<http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perlsyn.pod#Smart_matching_in_detail>
+
+
+There are also some questions that need answering:
+
+=over 4
+
+=item *
+
+How do you negate one? (documentation issue)
+http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-01/msg00071.html
+
+=item *
+
+Array behaviors
+http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00799.html
+
+* Should smart matches be symmetrical? (Perl 6 says no)
+
+* Other differences between Perl 5 and Perl 6 smart match?
+
+=item *
+
+Objects and smart match
+http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00865.html
+
+=back
+
=head2 Remove duplication of test setup.
Schwern notes, that there's duplication of code - lots and lots of tests have
The addition of C<Pod::Simple> and its related modules may make this task
easier to complete.
-=head2 merge checkpods and podchecker
+=head2 Make ExtUtils::ParseXS use strict;
+
+F<lib/ExtUtils/ParseXS.pm> contains this line
+
+ # use strict; # One of these days...
-F<pod/checkpods.PL> (and C<make check> in the F<pod/> subdirectory)
-implements a very basic check for pod files, but the errors it discovers
-aren't found by podchecker. Add this check to podchecker, get rid of
-checkpods and have C<make check> use podchecker.
+Simply uncomment it, and fix all the resulting issues :-)
+
+The more practical approach, to break the task down into manageable chunks, is
+to work your way though the code from bottom to top, or if necessary adding
+extra C<{ ... }> blocks, and turning on strict within them.
=head2 Parallel testing
A full test suite for the B module would be nice.
-=head2 Deparse inlined constants
-
-Code such as this
-
- use constant PI => 4;
- warn PI
-
-will currently deparse as
-
- use constant ('PI', 4);
- warn 4;
-
-because the tokenizer inlines the value of the constant subroutine C<PI>.
-This allows various compile time optimisations, such as constant folding
-and dead code elimination. Where these haven't happened (such as the example
-above) it ought be possible to make B::Deparse work out the name of the
-original constant, because just enough information survives in the symbol
-table to do this. Specifically, the same scalar is used for the constant in
-the optree as is used for the constant subroutine, so by iterating over all
-symbol tables and generating a mapping of SV address to constant name, it
-would be possible to provide B::Deparse with this functionality.
-
=head2 A decent benchmark
C<perlbench> seems impervious to any recent changes made to the perl core. It
=over 4
-=item * C<cc (cc.U)>
+=item * C<cc> (in F<cc.U>)
This variable holds the name of a command to execute a C compiler which
can resolve multiple global references that happen to have the same
name. Usual values are F<cc> and F<gcc>.
Fervent ANSI compilers may be called F<c89>. AIX has F<xlc>.
-=item * ld (dlsrc.U)
+=item * C<ld> (in F<dlsrc.U>)
This variable indicates the program to be used to link
libraries for dynamic loading. On some systems, it is F<ld>.
=back
-There is an implicit historical assumption, probably from Perl 1, that C<$cc>
-is also the correct command for linking object files together to make an
-executable. This may be true on Unix, but it's not true on other platforms,
-and there are a maze of work arounds in other places (such as F<Makefile.SH>)
-to cope with this.
+There is an implicit historical assumption from around Perl5.000alpha
+something, that C<$cc> is also the correct command for linking object files
+together to make an executable. This may be true on Unix, but it's not true
+on other platforms, and there are a maze of work arounds in other places (such
+as F<Makefile.SH>) to cope with this.
Ideally, we should create a new variable to hold the name of the executable
linker program, probe for it in F<Configure>, and centralise all the special
case logic there or in hints files.
A small bikeshed issue remains - what to call it, given that C<$ld> is already
-taken (arguably for the wrong thing) and C<$link> could be confused with the
-Unix command line executable of the same name, which does something completely
-different. Andy Dougherty makes the counter argument "In parrot, I tried to
-call the command used to link object files and libraries into an executable
-F<link>, since that's what my vaguely-remembered DOS and VMS experience
-suggested. I don't think any real confusion has ensued, so it's probably a
-reasonable name for perl5 to use."
+taken (arguably for the wrong thing now, but on SunOS 4.1 it is the command
+for creating dynamically-loadable modules) and C<$link> could be confused with
+the Unix command line executable of the same name, which does something
+completely different. Andy Dougherty makes the counter argument "In parrot, I
+tried to call the command used to link object files and libraries into an
+executable F<link>, since that's what my vaguely-remembered DOS and VMS
+experience suggested. I don't think any real confusion has ensued, so it's
+probably a reasonable name for perl5 to use."
"Alas, I've always worried that introducing it would make things worse,
since now the module building utilities would have to look for
C<$Config{link}> and institute a fall-back plan if it weren't found."
-
+Although I can see that as confusing, given that C<$Config{d_link}> is true
+when (hard) links are available.
+
+=head2 Configure Windows using PowerShell
+
+Currently, Windows uses hard-coded config files based to build the
+config.h for compiling Perl. Makefiles are also hard-coded and need to be
+hand edited prior to building Perl. While this makes it easy to create a perl.exe
+that works across multiple Windows versions, being able to accurately
+configure a perl.exe for a specific Windows versions and VS C++ would be
+a nice enhancement. With PowerShell available on Windows XP and up, this
+may now be possible. Step 1 might be to investigate whether this is possible
+and use this to clean up our current makefile situation. Step 2 would be to
+see if there would be a way to use our existing metaconfig units to configure a
+Windows Perl or whether we go in a separate direction and make it so. Of
+course, we all know what step 3 is.
=head1 Tasks that need a little C knowledge
Configure process will build a 32bit perl. Implementing -Duse32bit*
options would be nice for perl 5.12.
-=head2 Make it clear from -v if this is the exact official release
-
-Currently perl from C<p4>/C<rsync> ships with a F<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 until 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.
-
-This task is really about thinking of an elegant way to arrange the C source
-such that it's trivial for the Pumpking to flag "this is an official release"
-when making a tarball, yet leave the default source saying "I'm not the
-official release".
-
=head2 Profile Perl - am I hot or not?
The Perl source code is stable enough that it makes sense to profile it,
the perl API that comes from writing modules that use XS to interface to
C.
+=head2 Remove the use of SVs as temporaries in dump.c
+
+F<dump.c> contains debugging routines to dump out the contains of perl data
+structures, such as C<SV>s, C<AV>s and C<HV>s. Currently, the dumping code
+B<uses> C<SV>s for its temporary buffers, which was a logical initial
+implementation choice, as they provide ready made memory handling.
+
+However, they also lead to a lot of confusion when it happens that what you're
+trying to debug is seen by the code in F<dump.c>, correctly or incorrectly, as
+a temporary scalar it can use for a temporary buffer. It's also not possible
+to dump scalars before the interpreter is properly set up, such as during
+ithreads cloning. It would be good to progressively replace the use of scalars
+as string accumulation buffers with something much simpler, directly allocated
+by C<malloc>. The F<dump.c> code is (or should be) only producing 7 bit
+US-ASCII, so output character sets are not an issue.
+
+Producing and proving an internal simple buffer allocation would make it easier
+to re-write the internals of the PerlIO subsystem to avoid using C<SV>s for
+B<its> buffers, use of which can cause problems similar to those of F<dump.c>,
+at similar times.
+
=head2 safely supporting POSIX SA_SIGINFO
Some years ago Jarkko supplied patches to provide support for the POSIX
These tasks would need C knowledge, and knowledge of how the interpreter works,
or a willingness to learn.
+=head2 error reporting of [$a ; $b]
+
+Using C<;> inside brackets is a syntax error, and we don't propose to change
+that by giving it any meaning. However, it's not reported very helpfully:
+
+ $ perl -e '$a = [$b; $c];'
+ syntax error at -e line 1, near "$b;"
+ syntax error at -e line 1, near "$c]"
+ Execution of -e aborted due to compilation errors.
+
+It should be possible to hook into the tokeniser or the lexer, so that when a
+C<;> is parsed where it is not legal as a statement terminator (ie inside
+C<{}> used as a hashref, C<[]> or C<()>) it issues an error something like
+I<';' isn't legal inside an expression - if you need multiple statements use a
+do {...} block>. See the thread starting at
+http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-09/msg00573.html
+
=head2 lexicals used only once
This warns:
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 Optimize away empty destructors
-
-Defining an empty DESTROY method might be useful (notably in
-AUTOLOAD-enabled classes), but it's still a bit expensive to call. That
-could probably be optimized.
-
=head2 LVALUE functions for lists
The old perltodo notes that lvalue functions don't work for list or hash
slices. This would be good to fix.
-=head2 LVALUE functions in the debugger
-
-The old perltodo notes that lvalue functions don't work in the debugger. This
-would be good to fix.
-
=head2 regexp optimiser optional
The regexp optimiser is not optional. It should configurable to be, to allow
=head2 Investigate PADTMP hash pessimisation
-The peephole optimier converts constants used for hash key lookups to shared
+The peephole optimiser converts constants used for hash key lookups to shared
hash key scalars. Under ithreads, something is undoing this work.
See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html
projects / p5sagit/p5-mst-13.2.git / blobdiff