This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
add regmust() to re.pm/re.xs
[perl5.git] / pod / perltodo.pod
1 =head1 NAME
2
3 perltodo - Perl TO-DO List
4
5 =head1 DESCRIPTION
6
7 This is a list of wishes for Perl. The tasks we think are smaller or easier
8 are listed first. Anyone is welcome to work on any of these, but it's a good
9 idea to first contact I<perl5-porters@perl.org> to avoid duplication of
10 effort. By all means contact a pumpking privately first if you prefer.
11
12 Whilst patches to make the list shorter are most welcome, ideas to add to
13 the list are also encouraged. Check the perl5-porters archives for past
14 ideas, and any discussion about them. One set of archives may be found at:
15
16     http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/
17
18 What can we offer you in return? Fame, fortune, and everlasting glory? Maybe
19 not, but if your patch is incorporated, then we'll add your name to the
20 F<AUTHORS> file, which ships in the official distribution. How many other
21 programming languages offer you 1 line of immortality?
22
23 =head1 The roadmap to 5.10
24
25 The roadmap to 5.10 envisages feature based releases, as various items in this
26 TODO are completed.
27
28 =head2 Needed for a 5.9.5 release
29
30 =over
31
32 =item *
33
34 Review assertions. Review syntax to combine assertions. Assertions could take
35 advantage of the lexical pragmas work. L</What hooks would assertions need?>
36
37 =back
38
39 =head2 Needed for a 5.9.6 release
40
41 Stabilisation. If all goes well, this will be the equivalent of a 5.10-beta.
42
43 =head2 Needed for the final 5.10.0 release
44
45 =over 4
46
47 =item *
48
49 Review perlguts. Significant changes have occured since 5.8, and we can't
50 release a new version without making sure these are covered.
51
52 =back
53
54 =head1 Tasks that only need Perl knowledge
55
56 =head2 common test code for timed bail out
57
58 Write portable self destruct code for tests to stop them burning CPU in
59 infinite loops. This needs to avoid using alarm, as some of the tests are
60 testing alarm/sleep or timers.
61
62 =head2 POD -> HTML conversion in the core still sucks
63
64 Which is crazy given just how simple POD purports to be, and how simple HTML
65 can be. It's not actually I<as> simple as it sounds, particularly with the
66 flexibility POD allows for C<=item>, but it would be good to improve the
67 visual appeal of the HTML generated, and to avoid it having any validation
68 errors. See also L</make HTML install work>, as the layout of installation tree
69 is needed to improve the cross-linking.
70
71 The addition of C<Pod::Simple> and its related modules may make this task
72 easier to complete.
73
74 =head2 Parallel testing
75
76 (This probably impacts much more than the core: also the Test::Harness
77 and TAP::* modules on CPAN.)
78
79 The core regression test suite is getting ever more comprehensive, which has
80 the side effect that it takes longer to run. This isn't so good. Investigate
81 whether it would be feasible to give the harness script the B<option> of
82 running sets of tests in parallel. This would be useful for tests in
83 F<t/op/*.t> and F<t/uni/*.t> and maybe some sets of tests in F<lib/>.
84
85 Questions to answer
86
87 =over 4
88
89 =item 1
90
91 How does screen layout work when you're running more than one test?
92
93 =item 2
94
95 How does the caller of test specify how many tests to run in parallel?
96
97 =item 3
98
99 How do setup/teardown tests identify themselves?
100
101 =back
102
103 Pugs already does parallel testing - can their approach be re-used?
104
105 =head2 Make Schwern poorer
106
107 We should have tests for everything. When all the core's modules are tested,
108 Schwern has promised to donate to $500 to TPF. We may need volunteers to
109 hold him upside down and shake vigorously in order to actually extract the
110 cash.
111
112 =head2 Improve the coverage of the core tests
113
114 Use Devel::Cover to ascertain the core modules's test coverage, then add
115 tests that are currently missing.
116
117 =head2 test B
118
119 A full test suite for the B module would be nice.
120
121 =head2 A decent benchmark
122
123 C<perlbench> seems impervious to any recent changes made to the perl core. It
124 would be useful to have a reasonable general benchmarking suite that roughly
125 represented what current perl programs do, and measurably reported whether
126 tweaks to the core improve, degrade or don't really affect performance, to
127 guide people attempting to optimise the guts of perl. Gisle would welcome
128 new tests for perlbench.
129
130 =head2 fix tainting bugs
131
132 Fix the bugs revealed by running the test suite with the C<-t> switch (via
133 C<make test.taintwarn>).
134
135 =head2 Dual life everything
136
137 As part of the "dists" plan, anything that doesn't belong in the smallest perl
138 distribution needs to be dual lifed. Anything else can be too. Figure out what
139 changes would be needed to package that module and its tests up for CPAN, and
140 do so. Test it with older perl releases, and fix the problems you find.
141
142 =head2 Improving C<threads::shared>
143
144 Investigate whether C<threads::shared> could share aggregates properly with
145 only Perl level changes to shared.pm
146
147 =head2 POSIX memory footprint
148
149 Ilya observed that use POSIX; eats memory like there's no tomorrow, and at
150 various times worked to cut it down. There is probably still fat to cut out -
151 for example POSIX passes Exporter some very memory hungry data structures.
152
153 =head2 embed.pl/makedef.pl
154
155 There is a script F<embed.pl> that generates several header files to prefix
156 all of Perl's symbols in a consistent way, to provide some semblance of
157 namespace support in C<C>. Functions are declared in F<embed.fnc>, variables
158 in F<interpvar.h> and F<thrdvar.h>. Quite a few of the functions and variables
159 are conditionally declared there, using C<#ifdef>. However, F<embed.pl>
160 doesn't understand the C macros, so the rules about which symbols are present
161 when is duplicated in F<makedef.pl>. Writing things twice is bad, m'kay.
162 It would be good to teach C<embed.pl> to understand the conditional
163 compilation, and hence remove the duplication, and the mistakes it has caused.
164
165 =head1 Tasks that need a little sysadmin-type knowledge
166
167 Or if you prefer, tasks that you would learn from, and broaden your skills
168 base...
169
170 =head2 make HTML install work
171
172 There is an C<installhtml> target in the Makefile. It's marked as
173 "experimental". It would be good to get this tested, make it work reliably, and
174 remove the "experimental" tag. This would include
175
176 =over 4
177
178 =item 1
179
180 Checking that cross linking between various parts of the documentation works.
181 In particular that links work between the modules (files with POD in F<lib/>)
182 and the core documentation (files in F<pod/>)
183
184 =item 2
185
186 Work out how to split C<perlfunc> into chunks, preferably one per function
187 group, preferably with general case code that could be used elsewhere.
188 Challenges here are correctly identifying the groups of functions that go
189 together, and making the right named external cross-links point to the right
190 page. Things to be aware of are C<-X>, groups such as C<getpwnam> to
191 C<endservent>, two or more C<=items> giving the different parameter lists, such
192 as
193
194     =item substr EXPR,OFFSET,LENGTH,REPLACEMENT
195     =item substr EXPR,OFFSET,LENGTH
196     =item substr EXPR,OFFSET
197
198 and different parameter lists having different meanings. (eg C<select>)
199
200 =back
201
202 =head2 compressed man pages
203
204 Be able to install them. This would probably need a configure test to see how
205 the system does compressed man pages (same directory/different directory?
206 same filename/different filename), as well as tweaking the F<installman> script
207 to compress as necessary.
208
209 =head2 Add a code coverage target to the Makefile
210
211 Make it easy for anyone to run Devel::Cover on the core's tests. The steps
212 to do this manually are roughly
213
214 =over 4
215
216 =item *
217
218 do a normal C<Configure>, but include Devel::Cover as a module to install
219 (see F<INSTALL> for how to do this)
220
221 =item *
222
223     make perl
224
225 =item *
226
227     cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
228
229 =item *
230
231 Process the resulting Devel::Cover database
232
233 =back
234
235 This just give you the coverage of the F<.pm>s. To also get the C level
236 coverage you need to
237
238 =over 4
239
240 =item *
241
242 Additionally tell C<Configure> to use the appropriate C compiler flags for
243 C<gcov>
244
245 =item *
246
247     make perl.gcov
248
249 (instead of C<make perl>)
250
251 =item *
252
253 After running the tests run C<gcov> to generate all the F<.gcov> files.
254 (Including down in the subdirectories of F<ext/>
255
256 =item *
257
258 (From the top level perl directory) run C<gcov2perl> on all the C<.gcov> files
259 to get their stats into the cover_db directory.
260
261 =item *
262
263 Then process the Devel::Cover database
264
265 =back
266
267 It would be good to add a single switch to C<Configure> to specify that you
268 wanted to perform perl level coverage, and another to specify C level
269 coverage, and have C<Configure> and the F<Makefile> do all the right things
270 automatically.
271
272 =head2 Make Config.pm cope with differences between built and installed perl
273
274 Quite often vendors ship a perl binary compiled with their (pay-for)
275 compilers.  People install a free compiler, such as gcc. To work out how to
276 build extensions, Perl interrogates C<%Config>, so in this situation
277 C<%Config> describes compilers that aren't there, and extension building
278 fails. This forces people into choosing between re-compiling perl themselves
279 using the compiler they have, or only using modules that the vendor ships.
280
281 It would be good to find a way teach C<Config.pm> about the installation setup,
282 possibly involving probing at install time or later, so that the C<%Config> in
283 a binary distribution better describes the installed machine, when the
284 installed machine differs from the build machine in some significant way.
285
286 =head2 linker specification files
287
288 Some platforms mandate that you provide a list of a shared library's external
289 symbols to the linker, so the core already has the infrastructure in place to
290 do this for generating shared perl libraries. My understanding is that the
291 GNU toolchain can accept an optional linker specification file, and restrict
292 visibility just to symbols declared in that file. It would be good to extend
293 F<makedef.pl> to support this format, and to provide a means within
294 C<Configure> to enable it. This would allow Unix users to test that the
295 export list is correct, and to build a perl that does not pollute the global
296 namespace with private symbols.
297
298 =head2 Cross-compile support
299
300 Currently C<Configure> understands C<-Dusecrosscompile> option. This option
301 arranges for building C<miniperl> for TARGET machine, so this C<miniperl> is
302 assumed then to be copied to TARGET machine and used as a replacement of full
303 C<perl> executable.
304
305 This could be done little differently. Namely C<miniperl> should be built for
306 HOST and then full C<perl> with extensions should be compiled for TARGET.
307 This, however, might require extra trickery for %Config: we have one config
308 first for HOST and then another for TARGET.
309
310 =head1 Tasks that need a little C knowledge
311
312 These tasks would need a little C knowledge, but don't need any specific
313 background or experience with XS, or how the Perl interpreter works
314
315 =head2 Make it clear from -v if this is the exact official release
316
317 Currently perl from C<p4>/C<rsync> ships with a F<patchlevel.h> file that
318 usually defines one local patch, of the form "MAINT12345" or "RC1". The output
319 of perl -v doesn't report that a perl isn't an official release, and this
320 information can get lost in bugs reports. Because of this, the minor version
321 isn't bumped up until RC time, to minimise the possibility of versions of perl
322 escaping that believe themselves to be newer than they actually are.
323
324 It would be useful to find an elegant way to have the "this is an interim
325 maintenance release" or "this is a release candidate" in the terse -v output,
326 and have it so that it's easy for the pumpking to remove this just as the
327 release tarball is rolled up. This way the version pulled out of rsync would
328 always say "I'm a development release" and it would be safe to bump the
329 reported minor version as soon as a release ships, which would aid perl
330 developers.
331
332 This task is really about thinking of an elegant way to arrange the C source
333 such that it's trivial for the Pumpking to flag "this is an official release"
334 when making a tarball, yet leave the default source saying "I'm not the
335 official release".
336
337 =head2 Ordering of "global" variables.
338
339 F<thrdvar.h> and F<intrpvarh> define the "global" variables that need to be
340 per-thread under ithreads, where the variables are actually elements in a
341 structure. As C dictates, the variables must be laid out in order of
342 declaration. There is a comment
343 C</* Important ones in the first cache line (if alignment is done right) */>
344 which implies that at some point in the past the ordering was carefully chosen
345 (at least in part). However, it's clear that the ordering is less than perfect,
346 as currently there are things such as 7 C<bool>s in a row, then something
347 typically requiring 4 byte alignment, and then an odd C<bool> later on.
348 (C<bool>s are typically defined as C<char>s). So it would be good for someone
349 to review the ordering of the variables, to see how much alignment padding can
350 be removed.
351
352 It's also worth checking that all variables are actually used. Perl 5.8.0
353 shipped with C<PL_nrs> still defined in F<thrdvar.h>, despite it being unused
354 since a change over a year earlier. Had this been spotted before release, it
355 could have been removed, but now it has to remain in the 5.8.x releases to
356 keep the structure the same size, to retain binary compatibility.
357
358 It's probably worth checking if all need to be the types they are. For example
359
360     PERLVAR(Ierror_count, I32)  /* how many errors so far, max 10 */
361
362 might work as well if stored in a signed (or unsigned) 8 bit value, if the
363 comment is accurate. C<PL_multi_open> and C<PL_multi_close> can probably
364 become C<char>s. Finding variables to downsize coupled with rearrangement
365 could shrink the interpreter structure; a size saving which is multiplied by
366 the number of threads running.
367
368 =head2 Profile Perl - am I hot or not?
369
370 The Perl source code is stable enough that it makes sense to profile it,
371 identify and optimise the hotspots. It would be good to measure the
372 performance of the Perl interpreter using free tools such as cachegrind,
373 gprof, and dtrace, and work to reduce the bottlenecks they reveal.
374
375 As part of this, the idea of F<pp_hot.c> is that it contains the I<hot> ops,
376 the ops that are most commonly used. The idea is that by grouping them, their
377 object code will be adjacent in the executable, so they have a greater chance
378 of already being in the CPU cache (or swapped in) due to being near another op
379 already in use.
380
381 Except that it's not clear if these really are the most commonly used ops. So
382 as part of exercising your skills with coverage and profiling tools you might
383 want to determine what ops I<really> are the most commonly used. And in turn
384 suggest evictions and promotions to achieve a better F<pp_hot.c>.
385
386 =head2 Allocate OPs from arenas
387
388 Currently all new OP structures are individually malloc()ed and free()d.
389 All C<malloc> implementations have space overheads, and are now as fast as
390 custom allocates so it would both use less memory and less CPU to allocate
391 the various OP structures from arenas. The SV arena code can probably be
392 re-used for this.
393
394 =head2 Improve win32/wince.c
395
396 Currently, numerous functions look virtually, if not completely,
397 identical in both C<win32/wince.c> and C<win32/win32.c> files, which can't
398 be good.
399
400 =head1 Tasks that need a knowledge of XS
401
402 These tasks would need C knowledge, and roughly the level of knowledge of
403 the perl API that comes from writing modules that use XS to interface to
404 C.
405
406 =head2 shrink C<PVBM>s
407
408 By removing unused elements and careful re-ordering, the structures for C<AV>s,
409 C<HV>s, C<CV>s and C<GV>s have recently been shrunk considerably. C<PVIO>s
410 probably aren't worth it, as typical programs don't use more than 8, and
411 (at least) C<Filter::Util::Call> uses C<SvPVX>/C<SvCUR>/C<SvLEN> on a C<PVIO>,
412 so it would mean code changes to modules on CPAN. C<PVBM>s might have some
413 savings to win.
414
415 =head2 autovivification
416
417 Make all autovivification consistent w.r.t LVALUE/RVALUE and strict/no strict;
418
419 This task is incremental - even a little bit of work on it will help.
420
421 =head2 Unicode in Filenames
422
423 chdir, chmod, chown, chroot, exec, glob, link, lstat, mkdir, open,
424 opendir, qx, readdir, readlink, rename, rmdir, stat, symlink, sysopen,
425 system, truncate, unlink, utime, -X.  All these could potentially accept
426 Unicode filenames either as input or output (and in the case of system
427 and qx Unicode in general, as input or output to/from the shell).
428 Whether a filesystem - an operating system pair understands Unicode in
429 filenames varies.
430
431 Known combinations that have some level of understanding include
432 Microsoft NTFS, Apple HFS+ (In Mac OS 9 and X) and Apple UFS (in Mac
433 OS X), NFS v4 is rumored to be Unicode, and of course Plan 9.  How to
434 create Unicode filenames, what forms of Unicode are accepted and used
435 (UCS-2, UTF-16, UTF-8), what (if any) is the normalization form used,
436 and so on, varies.  Finding the right level of interfacing to Perl
437 requires some thought.  Remember that an OS does not implicate a
438 filesystem.
439
440 (The Windows -C command flag "wide API support" has been at least
441 temporarily retired in 5.8.1, and the -C has been repurposed, see
442 L<perlrun>.)
443
444 =head2 Unicode in %ENV
445
446 Currently the %ENV entries are always byte strings.
447
448 =head2 use less 'memory'
449
450 Investigate trade offs to switch out perl's choices on memory usage.
451 Particularly perl should be able to give memory back.
452
453 This task is incremental - even a little bit of work on it will help.
454
455 =head2 Re-implement C<:unique> in a way that is actually thread-safe
456
457 The old implementation made bad assumptions on several levels. A good 90%
458 solution might be just to make C<:unique> work to share the string buffer
459 of SvPVs. That way large constant strings can be shared between ithreads,
460 such as the configuration information in F<Config>.
461
462 =head2 Make tainting consistent
463
464 Tainting would be easier to use if it didn't take documented shortcuts and
465 allow taint to "leak" everywhere within an expression.
466
467 =head2 readpipe(LIST)
468
469 system() accepts a LIST syntax (and a PROGRAM LIST syntax) to avoid
470 running a shell. readpipe() (the function behind qx//) could be similarly
471 extended.
472
473 =head2 strcat(), strcpy(), strncat(), strncpy(), sprintf(), vsprintf()
474
475 Maybe create a utility that checks after each libperl.a creation that
476 none of the above (nor sprintf(), vsprintf(), or *SHUDDER* gets())
477 ever creep back to libperl.a.
478
479   nm libperl.a | ./miniperl -alne '$o = $F[0] if /:$/; print "$o $F[1]" if $F[0] eq "U" && $F[1] =~ /^(?:strn?c(?:at|py)|v?sprintf|gets)$/'
480
481 Note, of course, that this will only tell whether B<your> platform
482 is using those naughty interfaces.
483
484 =head2 Audit the code for destruction ordering assumptions
485
486 Change 25773 notes
487
488     /* Need to check SvMAGICAL, as during global destruction it may be that
489        AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
490        is now part of the linked list of SV heads, rather than pointing to
491        the original body.  */
492     /* FIXME - audit the code for other bugs like this one.  */
493
494 adding the C<SvMAGICAL> check to
495
496     if (AvARYLEN(av) && SvMAGICAL(AvARYLEN(av))) {
497         MAGIC *mg = mg_find (AvARYLEN(av), PERL_MAGIC_arylen);
498
499 Go through the core and look for similar assumptions that SVs have particular
500 types, as all bets are off during global destruction.
501
502 =head1 Tasks that need a knowledge of the interpreter
503
504 These tasks would need C knowledge, and knowledge of how the interpreter works,
505 or a willingness to learn.
506
507 =head2 Implement $value ~~ 0 .. $range
508
509 It would be nice to extend the syntax of the C<~~> operator to also
510 understand numeric (and maybe alphanumeric) ranges.
511
512 =head2 Attach/detach debugger from running program
513
514 The old perltodo notes "With C<gdb>, you can attach the debugger to a running
515 program if you pass the process ID. It would be good to do this with the Perl
516 debugger on a running Perl program, although I'm not sure how it would be
517 done." ssh and screen do this with named pipes in /tmp. Maybe we can too.
518
519 =head2 LVALUE functions for lists
520
521 The old perltodo notes that lvalue functions don't work for list or hash
522 slices. This would be good to fix.
523
524 =head2 LVALUE functions in the debugger
525
526 The old perltodo notes that lvalue functions don't work in the debugger. This
527 would be good to fix.
528
529 =head2 regexp optimiser optional
530
531 The regexp optimiser is not optional. It should configurable to be, to allow
532 its performance to be measured, and its bugs to be easily demonstrated.
533
534 =head2 delete &function
535
536 Allow to delete functions. One can already undef them, but they're still
537 in the stash.
538
539 =head2 optional optimizer
540
541 Make the peephole optimizer optional. Currently it performs two tasks as
542 it walks the optree - genuine peephole optimisations, and necessary fixups of
543 ops. It would be good to find an efficient way to switch out the
544 optimisations whilst keeping the fixups.
545
546 =head2 You WANT *how* many
547
548 Currently contexts are void, scalar and list. split has a special mechanism in
549 place to pass in the number of return values wanted. It would be useful to
550 have a general mechanism for this, backwards compatible and little speed hit.
551 This would allow proposals such as short circuiting sort to be implemented
552 as a module on CPAN.
553
554 =head2 lexical aliases
555
556 Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>.
557
558 =head2 entersub XS vs Perl
559
560 At the moment pp_entersub is huge, and has code to deal with entering both
561 perl and XS subroutines. Subroutine implementations rarely change between 
562 perl and XS at run time, so investigate using 2 ops to enter subs (one for
563 XS, one for perl) and swap between if a sub is redefined.
564
565 =head2 Self ties
566
567 self ties are currently illegal because they caused too many segfaults. Maybe
568 the causes of these could be tracked down and self-ties on all types re-
569 instated.
570
571 =head2 Optimize away @_
572
573 The old perltodo notes "Look at the "reification" code in C<av.c>".
574
575 =head2 What hooks would assertions need?
576
577 Assertions are in the core, and work. However, assertions needed to be added
578 as a core patch, rather than an XS module in ext, or a CPAN module, because
579 the core has no hooks in the necessary places. It would be useful to
580 investigate what hooks would need to be added to make it possible to provide
581 the full assertion support from a CPAN module, so that we aren't constraining
582 the imagination of future CPAN authors.
583
584 =head2 Properly Unicode safe tokeniser and pads.
585
586 The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
587 variable names are stored in stashes as raw bytes, without the utf-8 flag
588 set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
589 tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
590 source filters.  All this could be fixed.
591
592 =head1 Big projects
593
594 Tasks that will get your name mentioned in the description of the "Highlights
595 of 5.10"
596
597 =head2 make ithreads more robust
598
599 Generally make ithreads more robust. See also L</iCOW>
600
601 This task is incremental - even a little bit of work on it will help, and
602 will be greatly appreciated.
603
604 One bit would be to write the missing code in sv.c:Perl_dirp_dup.
605
606 =head2 iCOW
607
608 Sarathy and Arthur have a proposal for an improved Copy On Write which
609 specifically will be able to COW new ithreads. If this can be implemented
610 it would be a good thing.
611
612 =head2 (?{...}) closures in regexps
613
614 Fix (or rewrite) the implementation of the C</(?{...})/> closures.
615
616 =head2 A re-entrant regexp engine
617
618 This will allow the use of a regex from inside (?{ }), (??{ }) and
619 (?(?{ })|) constructs.
620
621 =head2 Add class set operations to regexp engine
622
623 Apparently these are quite useful. Anyway, Jeffery Friedl wants them.
624
625 demerphq has this on his todo list, but right at the bottom.  
626
627