|
These are ideas that have been regularly tossed around, that most people believe should be
done maybe during 5.8.x
Because the regular expression engine is recursive, badly designed expressions can lead to
lots of recursion filling up the stack. Ilya claims that it is easy to convert the engine to
being iterative, but this has still not yet been done. There may be a regular expression
engine hit squad meeting at TPC5.
Perl will leak memory if you eval "hlagh hlagh hlagh hlagh". This is
partially because it attempts to build up an op tree for that code and doesn't properly free
it. The same goes for non-syntactically-correct regular expressions. Hugo looked into this,
but decided it needed a mark-and-sweep GC implementation.
Alan notes that: The basic idea was to extend the parser token stack (YYSTYPE)
to include a type field so we knew what sort of thing each element of the stack was. The perly.c
code would then have to be postprocessed to record the type of each entry on the stack as it
was created, and the parser patched so that it could unroll the stack properly on error.
This is possible to do, but would be pretty messy to implement, as it would rely on even
more sed hackery in perly.fixer.
Make Perl buildable with a cross-compiler. This will play havoc with Configure, which needs
to know how the target system will respond to its tests; maybe microperl will be
a good starting point here. (Indeed, Bart Schuller reports that he compiled up microperl
for the Agenda PDA and it works fine.) A really big spanner in the works is the bootstrapping
build process of Perl: if the filesystem the target systems sees is not the same what the
build host sees, various input, output, and (Perl) library files need to be copied back and
forth.
As of 5.8.0 Configure mostly works for cross-compilation (used successfully for iPAQ
Linux), miniperl gets built, but then building DynaLoader (and other extensions) fails since
MakeMaker knows nothing of cross-compilation. (See INSTALL/Cross-compilation for the state of
things.)
Source filters help with this, but do not get us all the way. For instance, it should be
possible to implement the ?? operator somehow; source filters don't (quite) cut
it.
Damian Conway is planning to work on this, but it hasn't happened yet.
When faced with a BSD vs. SysV -style interface to some library or system function, perl's
roots show in that it typically prefers the BSD interface (but falls back to the SysV one).
One example is getpgrp(). Other examples include memcpy vs. bcopy.
There are others, mostly in pp_sys.c.
Mostly, this item is a suggestion for which way to start a journey into an #ifdef
forest. It is not primarily a suggestion to eliminate any of the #ifdef forests.
POSIX calls are perhaps more likely to be portable to unexpected architectures. They are
also perhaps more likely to be actively maintained by a current vendor. They are also perhaps
more likely to be available in thread-safe versions, if appropriate.
It's only necessary to rename a file when inplace editing when the file has changed.
Detecting a change is perhaps the difficult bit.
eg read(ARGV, ...) doesn't currently read across multiple files.
There should be a way of restarting the debugger on demand.
The debugger is a complex piece of software and fixing something here may inadvertently
break something else over there. To tame this chaotic behaviour, a test suite is necessary.
The basic principle is sound, but there are problems with the semantics of self-referential
and mutually referential lexical subs: how to declare the subs?
Sweeping away all the allocated memory in one go is a laudable goal, but it's difficult and
in most cases, it's easier to let the memory get freed by exiting.
There has been talk recently of rewriting the regular expression parser to produce an
optree instead of a chain of opcodes; it's unclear whether or not this would be a win.
This is to speed up
for my $re (@regexps) {
$matched++ if /$re/
}
|
|
qr// already gives us a way of saving compiled regexps, but it should be done
automatically.
Bart Schuller reports that using microperl and a cross-compiler, he got Perl
working on the Agenda PDA. However, one cannot build a full Perl because Configure needs to
get the results for the target platform, for the host.
Given:
One should be able to do
and have the 999'th bit set.
Currently if you try with shift bitvectors you shift the NV/UV, instead of the bits in the
PV. Not very logical.
The debugger is implemented in Perl in perl5db.pl; turning it into a pragma should
be easy, but making it work lexically might be more difficult. Fiddling with $^P
would be necessary.
Identify areas where speed/memory tradeoffs can be made and have a hint to switch between
them.
Although we have Switch.pm in core, Larry points to the dormant nswitch
and cswitch ops in pp.c; using these opcodes would be much faster.
Look at the "reification" code in av.c
Currently, indirect object syntax bypasses prototype checks.
HTML versions of the documentation need to be installed by default; a call to installhtml
from installperl may be all that's necessary.
There have been persistent mumblings about putting a mark-and-sweep garbage detector into
Perl; Alan Burlison has some ideas about this.
Mark-Jason Dominus has the beginnings of one of these.
There are a few suggestions for what to do with perldoc: maybe a full-text
search, an index function, locating pages on a particular high-level subject, and so on.
This is a bone of contention; we can create .3p manpages for each built-in
function, but should we install them by default? Tcl does this, and it clutters up apropos.
Simon Cozens promises to do this before he gets old.
Allow @INC to be changed after Perl is built.
Make POSIX.pm behave as POSIXly as possible everywhere, meaning we have to
implement POSIX equivalents for some functions if necessary.
They don't work in the debugger, and they don't work for list or hash slices.
Hugo van der Sanden plans to look at this.
This has been done in places, but needs a thorough code review. Also fchdir is available in
some platforms.
Instead of having to guess whether a string is a v-string and thus needs to be displayed
with %vd, make v-strings (readonly) objects (class "vstring"?) with a stringify
overload.
Currently you're not allowed to assign to a restricted hash at all, even with the same
keys.
%restricted = (foo => 42); # error
|
|
This should be allowed if the new keyset is a subset of the old keyset. May require more
extra code than we'd like in pp_aassign.
Should overload be 'contagious' through @ISA so that derived classes would inherit their
base classes' overload definitions? What to do in case of overload conflicts?
Should taint be stopped from affecting control flow, if ($tainted)? Should tainted symbolic
method calls and subref calls be stopped? (Look at Ruby's $SAFE levels for inspiration?)
|
