The roadmap to 5.10 envisages feature based releases, as various items in this
TODO are completed.
-=head2 Needed for a 5.9.5 release
-
-=over
-
-=item *
-
-Review assertions. Review syntax to combine assertions. Assertions could take
-advantage of the lexical pragmas work. L</What hooks would assertions need?>
-
-=back
-
-=head2 Needed for a 5.9.6 release
-
-Stabilisation. If all goes well, this will be the equivalent of a 5.10-beta.
-
=head2 Needed for the final 5.10.0 release
-=over 4
-
-=item *
-
Review perlguts. Significant changes have occured since 5.8, and we can't
release a new version without making sure these are covered.
-=back
-
=head1 Tasks that only need Perl knowledge
=head2 common test code for timed bail out
infinite loops. This needs to avoid using alarm, as some of the tests are
testing alarm/sleep or timers.
-=head2 POD -> HTML conversion in the core still sucks
+=head2 POD -E<gt> HTML conversion in the core still sucks
Which is crazy given just how simple POD purports to be, and how simple HTML
can be. It's not actually I<as> simple as it sounds, particularly with the
There is a script F<embed.pl> that generates several header files to prefix
all of Perl's symbols in a consistent way, to provide some semblance of
namespace support in C<C>. Functions are declared in F<embed.fnc>, variables
-in F<interpvar.h> and F<thrdvar.h>. Quite a few of the functions and variables
+in F<interpvar.h>. Quite a few of the functions and variables
are conditionally declared there, using C<#ifdef>. However, F<embed.pl>
doesn't understand the C macros, so the rules about which symbols are present
when is duplicated in F<makedef.pl>. Writing things twice is bad, m'kay.
It would be good to teach C<embed.pl> 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<use strict;> 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.
+
=head1 Tasks that need a little sysadmin-type knowledge
Or if you prefer, tasks that you would learn from, and broaden your skills
This could be done little differently. Namely C<miniperl> should be built for
HOST and then full C<perl> with extensions should be compiled for TARGET.
This, however, might require extra trickery for %Config: we have one config
-first for HOST and then another for TARGET.
+first for HOST and then another for TARGET. Tools like MakeMaker will be
+mightily confused. Having around two different types of executables and
+libraries (HOST and TARGET) makes life interesting for Makefiles and
+shell (and Perl) scripts. There is $Config{run}, normally empty, which
+can be used as an execution wrapper. Also note that in some
+cross-compilation/execution environments the HOST and the TARGET do
+not see the same filesystem(s), the $Config{run} may need to do some
+file/directory copying back and forth.
=head1 Tasks that need a little C knowledge
when making a tarball, yet leave the default source saying "I'm not the
official release".
-=head2 Ordering of "global" variables.
-
-F<thrdvar.h> and F<intrpvarh> define the "global" variables that need to be
-per-thread under ithreads, where the variables are actually elements in a
-structure. As C dictates, the variables must be laid out in order of
-declaration. There is a comment
-C</* Important ones in the first cache line (if alignment is done right) */>
-which implies that at some point in the past the ordering was carefully chosen
-(at least in part). However, it's clear that the ordering is less than perfect,
-as currently there are things such as 7 C<bool>s in a row, then something
-typically requiring 4 byte alignment, and then an odd C<bool> later on.
-(C<bool>s are typically defined as C<char>s). So it would be good for someone
-to review the ordering of the variables, to see how much alignment padding can
-be removed.
-
-It's also worth checking that all variables are actually used. Perl 5.8.0
-shipped with C<PL_nrs> still defined in F<thrdvar.h>, despite it being unused
-since a change over a year earlier. Had this been spotted before release, it
-could have been removed, but now it has to remain in the 5.8.x releases to
-keep the structure the same size, to retain binary compatibility.
-
-It's probably worth checking if all need to be the types they are. For example
-
- PERLVAR(Ierror_count, I32) /* how many errors so far, max 10 */
-
-might work as well if stored in a signed (or unsigned) 8 bit value, if the
-comment is accurate. C<PL_multi_open> and C<PL_multi_close> can probably
-become C<char>s. Finding variables to downsize coupled with rearrangement
-could shrink the interpreter structure; a size saving which is multiplied by
-the number of threads running.
-
=head2 Profile Perl - am I hot or not?
The Perl source code is stable enough that it makes sense to profile it,
identical in both C<win32/wince.c> and C<win32/win32.c> files, which can't
be good.
+=head2 Use secure CRT functions when building with VC8 on Win32
+
+Visual C++ 2005 (VC++ 8.x) deprecated a number of CRT functions on the basis
+that they were "unsafe" and introduced differently named secure versions of
+them as replacements, e.g. instead of writing
+
+ FILE* f = fopen(__FILE__, "r");
+
+one should now write
+
+ FILE* f;
+ errno_t err = fopen_s(&f, __FILE__, "r");
+
+Currently, the warnings about these deprecations have been disabled by adding
+-D_CRT_SECURE_NO_DEPRECATE to the CFLAGS. It would be nice to remove that
+warning suppressant and actually make use of the new secure CRT functions.
+
+There is also a similar issue with POSIX CRT function names like fileno having
+been deprecated in favour of ISO C++ conformant names like _fileno. These
+warnings are also currently suppressed with the compiler option /wd4996. It
+might be nice to do as Microsoft suggest here too, although, unlike the secure
+functions issue, there is presumably little or no benefit in this case.
+
=head1 Tasks that need a knowledge of XS
These tasks would need C knowledge, and roughly the level of knowledge of
the perl API that comes from writing modules that use XS to interface to
C.
-=head2 shrink C<PVBM>s
-
-By removing unused elements and careful re-ordering, the structures for C<AV>s,
-C<HV>s, C<CV>s and C<GV>s have recently been shrunk considerably. C<PVIO>s
-probably aren't worth it, as typical programs don't use more than 8, and
-(at least) C<Filter::Util::Call> uses C<SvPVX>/C<SvCUR>/C<SvLEN> on a C<PVIO>,
-so it would mean code changes to modules on CPAN. C<PVBM>s might have some
-savings to win.
-
=head2 autovivification
Make all autovivification consistent w.r.t LVALUE/RVALUE and strict/no strict;
temporarily retired in 5.8.1, and the -C has been repurposed, see
L<perlrun>.)
+Most probably the right way to do this would be this:
+L</"Virtualize operating system access">.
+
=head2 Unicode in %ENV
Currently the %ENV entries are always byte strings.
+See L</"Virtualize operating system access">.
+
+=head2 Unicode and glob()
+
+Currently glob patterns and filenames returned from File::Glob::glob()
+are always byte strings. See L</"Virtualize operating system access">.
=head2 use less 'memory'
Go through the core and look for similar assumptions that SVs have particular
types, as all bets are off during global destruction.
+=head2 Extend PerlIO and PerlIO::Scalar
+
+PerlIO::Scalar doesn't know how to truncate(). Implementing this
+would require extending the PerlIO vtable.
+
+Similarly the PerlIO vtable doesn't know about formats (write()), or
+about stat(), or chmod()/chown(), utime(), or flock().
+
+(For PerlIO::Scalar it's hard to see what e.g. mode bits or ownership
+would mean.)
+
+PerlIO doesn't do directories or symlinks, either: mkdir(), rmdir(),
+opendir(), closedir(), seekdir(), rewinddir(), glob(); symlink(),
+readlink().
+
+=head2 -C on the #! line
+
+It should be possible to make -C work correctly if found on the #! line,
+given that all perl command line options are strict ASCII, and -C changes
+only the interpretation of non-ASCII characters, and not for the script file
+handle. To make it work needs some investigation of the ordering of function
+calls during startup, and (by implication) a bit of tweaking of that order.
+
+
=head1 Tasks that need a knowledge of the interpreter
These tasks would need C knowledge, and knowledge of how the interpreter works,
Allow to delete functions. One can already undef them, but they're still
in the stash.
+=head2 C</w> regex modifier
+
+That flag would enable to match whole words, and also to interpolate
+arrays as alternations. With it, C</P/w> would be roughly equivalent to:
+
+ do { local $"='|'; /\b(?:P)\b/ }
+
+See L<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-01/msg00400.html>
+for the discussion.
+
=head2 optional optimizer
Make the peephole optimizer optional. Currently it performs two tasks as
The old perltodo notes "Look at the "reification" code in C<av.c>".
-=head2 What hooks would assertions need?
-
-Assertions are in the core, and work. However, assertions needed to be added
-as a core patch, rather than an XS module in ext, or a CPAN module, because
-the core has no hooks in the necessary places. It would be useful to
-investigate what hooks would need to be added to make it possible to provide
-the full assertion support from a CPAN module, so that we aren't constraining
-the imagination of future CPAN authors.
-
=head2 Properly Unicode safe tokeniser and pads.
The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
source filters. All this could be fixed.
+=head2 The yada yada yada operators
+
+Perl 6's Synopsis 3 says:
+
+I<The ... operator is the "yada, yada, yada" list operator, which is used as
+the body in function prototypes. It complains bitterly (by calling fail)
+if it is ever executed. Variant ??? calls warn, and !!! calls die.>
+
+Those would be nice to add to Perl 5. That could be done without new ops.
+
+=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<perlport/"Files and Filesystems"> is good reading at this point,
+in fact, all of L<perlport> is.)
+
+This has actually already been implemented (but only for Win32),
+take a look at F<iperlsys.h> and F<win32/perlhost.h>. 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.) But this 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.
+
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
-of 5.10"
+of 5.12"
=head2 make ithreads more robust
One bit would be to write the missing code in sv.c:Perl_dirp_dup.
+Fix Perl_sv_dup, et al so that threads can return objects.
+
=head2 iCOW
Sarathy and Arthur have a proposal for an improved Copy On Write which
Apparently these are quite useful. Anyway, Jeffery Friedl wants them.
demerphq has this on his todo list, but right at the bottom.
-
-
projects / p5sagit/p5-mst-13.2.git / blobdiff