develooper Front page | perl.bootstrap | Postings from July 2000

Re: perl 6 requirements

July 31, 2000 17:32
Re: perl 6 requirements
Message ID:
On Mon, Jul 31, 2000 at 11:53:00AM -0400, Chaim Frenkel wrote:
>Mr. Chairmen, I request a decision if it is sufficient that a document
>be recorded on the list via reference, or a full inclusion is required.
>(It might make it more useful for future searches of the archives.)

It's 32Kb of text, so I was loathe to post it without people asking

However, since you've asked...


Perl 6 Requirements Document

   Kirrily Robert

   The intent of this requirements document is to lay out as many
   perceived problems with Perl 5 as can be found, to discuss each one,
   and to rephrase each problem as a requirement which Perl 6 may attempt
   to address. While there are many items which fall into the "WIBNI"
   (Wouldn't It Be Nice If...) category, they are generally not included
   in this document.
   This document is a compilation of issues raised in the TPC 4.0 p5p
   meeting, on the Perl 6 bootstrap list and in other fora where Perl 6
   has been discussed. Any and all Perl 5 problems posted on the
   bootstrap list or otherwise communicated to me have been included in
   this list, although sometimes multiple related problems have been
   amalgamated into one larger one. If any issues are not addressed in
   this document, please contact the maintainer.
   This is intended as a "living document". It is hoped that bootstrap
   subscribers and other interested parties will contribute to it. In
   particular, I am seeking more detailed or more accurate discussion on
   many of the points.
   When this document becomes reasonably "slushy" (that's the state just
   before frozen) it can be passed on to Larry and/or the appropriate
   working group leaders and used as a basis for the design process.
Authorship, distribution and version information

   The maintainer of this document is Kirrily "Skud" Robert,
   <>. Major contributors (those who sent me prepared
   material for inclusion in this document) include:
     * Adam Turoff <>
     * Simon Cozens <>
     * Garrett Goebel <>
   The latest version of this document is available from The CVS Id tag of the
   document you're reading is:
   $Id: requirements.sgml,v 1.6 2000/07/31 14:50:34 skud Exp $

    1. PROBLEM: Perl 5's internals are overly complex
       Perl's internals are currently a barrier to entry for new
       developers. Heavy use of macros can make the source difficult to
       follow and to debug, and the monolithic and "self-aware" nature of
       the code have made Perl's internals, to put it politely, gestalt.
       A complete redesign of the internals will need to put emphasis on
       modularity, simplicity, extensibility and maintainability.
    2. PROBLEM: Perl 5 is bloated
       Perl 5.004 was 2,399Kb. Perl 5.005 was 3,352Kb. Perl 5.6.0 was
       5,316Kb. This must stop! To be fair, Unicode tables made up a lot
       of the additional bulk in 5.6.0, but the core has been growing and
       growing as more modules and documentation are added and more code
       Remove little-used features from the Perl core, perhaps leaving
       them accessible if they are required.
       Move as many built-in functions as possible out to dynamically
       loaded modules.
    3. PROBLEM: Implementing pseudohashes in Perl 5 was too hard. Perl
       should be able to accommodate new datatype implementations more
       Pseudohashes, loathe them or hate them, were very tricky to add to
       Perl. In fact, other areas which affect the user-space operation
       of Perl have mainly been evil hacks: threads and source filters
       also spring to mind. We will specifically look at data types in a
       later issue.
       Perl 6 needs to be designed with extensibility in mind.
    4. PROBLEM: Perl 5's garbage collection is not as efficient as it
       could be
       Perl disposes of allocated chunks of memory when nobody's using
       them. To keep track of who's using what, it stores a reference
       count along with the chunk. This seems sensible, but leads to
       problems with circular references. The alternative is to mark a
       piece of memory as dead, and periodically sweep up the garbage -
       mark-and-sweep GC. For reference, Python also uses reference
       counting. A longer discussion can be found at and a full academic survey of GC
       techniques at
       Perl should use the most efficient suitable garbage collection
       Mark-and-sweep garbage collection
    5. PROBLEM: Perl 5's signal handling is broken
       Perl theoretically allows you to trap signals by saying
            $SIG{INT} = sub {

       Unfortunately, the implementation is Perl 5 is unsafe - signal
       handlers are not re-entrant (that is, receiving a signal while in
       a signal handler can lead to confusion) and allocating memory
       inside a signal handler can lead to spectacular explosions. The
       traditional solution is to arrange for Perl to accept all signals
       and do little more than flag that a signal has received; a handler
       can be fired off when it is safe to do so.
       Make Perl 6's signal handling both safe and re-entrant.

Miscellaneous language issues

    1. PROBLEM: Perl 5's syntax is disliked by programmers familiar with
       other languages
       Perl is not like other programming languages. Ilya used to say
       that Perl isn't a programming language - Perl's grammar is much
       more like a natural language than a computer one. Think of some of
       the criticisms levelled at Perl: there isn't a standard for the
       language, it can't be parsed with existing tools, idiom and slang
       make it hard for foreigners to understand. These criticisms are
       equally valid for human languages.
       Perl 6 should provide as much approachability as possible for
       programmers who have not previously used Perl, without changing
       Perl so much that existing Perl programmers will run away.
    2. PROBLEM: Perl 5 does not provide an event model
       Perl is often used for network server applications where the data
       coming in from outside drives program execution - this is also an
       important design feature of graphical applications. Since Perl
       does not provide a main loop design for applications, each toolkit
       and server must provide its own. Modules such as Event and POE
       provide solutions to this problem.
       Perl 6 should add support for a main loop
          + Add POE or Event or similar to the core library
          + Build it in at the internals level
    3. PROBLEM: Perl 5 does not provide structured exception handling
       People want to do this:
        try {
        } catch {

       which you can probably do with the Exceptions module or similar.
       Perl 6 should support exceptions.
       Add such a module to core, or build it into the language syntax.
    4. PROBLEM: Perl 5 does not support stackable I/O filters (a la TCL)
       In order to add flexible data handling, Perl needs a good way of
       filtering the incoming and outgoing data before it hits userspace.
       This is more than just filtering after the data has been read -
       the filters need to control buffering and line endings as well as
       ordinary translation.
       Perl 6 should support stackable I/O filters.
       Roll our own portable stdio to support stackable filters. Look at
       sfio for examples of what's required.
    5. PROBLEM: Perl 5 does not adequately support threads and reentrancy
       We briefly mentioned reentrancy earlier; Perl also needs to
       support the operating system's threading interface and make that
       accessible to user space so that multithreaded programs can be
       written in Perl.
       Working threads!
    6. PROBLEM: Perl 5's syntax cannot be parsed by Perl
       At present, the only working implementation of a Perl parser is in
       the perl interpreter. (Slightly more error-prone implementations
       can be found in the brain of anyone who uses Perl extensively.)
       Because of Perl's context sensitive grammar, it's sometimes
       impossible to tell what ``part of speech'' a given token is
       without executing some of the code. This makes it really difficult
       to write style checkers, indenters, pretty printers and so on.
       Expose the workings of the tokeniser-parser to Perl space just
       like the B module does for the completed op tree. As much as
       possible, have the tokeniser-parser a modular, extractable
       component in the interpreter.
    7. PROBLEM: Perl 5 does not have a case/switch statement
       Damian Conway, of course, has a paper on this.
       Add a real switch or case statement to core.
    8. PROBLEM: Perl 5 does not support nested uses of each()
       The each() function uses a single counter, so it is not possible
       to nest the use of each() within an each() loop.
       Perl 6 should allow the nested use of each().

    1. PROBLEM: localtime's behaviour is non-intuitive for non-Unix
       localtime in a list context returns values grabbed directly from a
       C struct tm. This means that the day of the month starts from one,
       the month of the year starts from zero, and the year is 1900 less
       than common era. This is totally non-intuitive for people from a
       non-Unix background, and even catches a fair number of Unix users.
       Perl 6 should provide time functions which are not based on C's
       struct tm and which are more intuitive to novice programmers.
       Make the month start at one, the day of the month start at one,
       and the year reflect the actual year.
    2. PROBLEM: system() returning 0 for success is non-intuitive to
       non-Unix people
       System calls return true if they succeed and false if they do not.
       Apart from system(), which returns something mystical. This means
       you can't do the intuitive:
         if (system("ls")) {

       Perl 6's system() should return true on success.
    3. PROBLEM: several functions in Perl 5's core are Unix-centric, eg
       Perl contains a number of non-portable built-in functions like the
       semaphore and shared memory functions. These don't make sense on a
       number of platforms, add to core bloat and are hardly used by the
       vast majority of programmers anyway.
       All non-portable core functions should be removed from Perl 6.
       They can be put into separate libraries.
Obsolete features

    1. PROBLEM: Formats are not commonly used and are not needed in the
       core language
       Formats also add to core bloat without providing significant
       essential functionality. They could very easily be removed
       altogether and reimplemented in terms of an extension or a Perl
       Formats should be removed from Perl 6.
       Support for this functionality could be achieved through a Perl
       module. Text::Template does this sort of thing anyway.
    2. PROBLEM: There are too many special variables, many of them of
       minimal use
       Many of Perl's special variables are now deprecated, obsolete, or
       dangerous. More of them will become so
       Unnecessary perlvars should be removed from Perl 6.
       The following variables can probably be removed or replaced by
       more readable syntax:
          + $[ (dangerous? changes index of first array element)
          + $* (obsoleted by /m modifier on m// or s///)
          + $%, $#, $=, $-, $^, $~, $:, $^L, $^A (format related)
          + $|, $/, $\ (probably obsoleted by line disciplines)
          + $(, $), $<, $> (might be better done as functions)
          + $^O (identical to $Config{'osname'})

    1. PROBLEM: Perl 5 does not allow access to the regexp engine's
       internals for debugging
       Well, it does, sort of. use re 'debug' will produce debugging
       output. However, the regular expression engine is a highly
       optimised, highly complex, highly scary piece of code, so it's no
       wonder people don't play with its debugging support.
       Perl 6's regular expression engine should be accessible to mere
    2. PROBLEM: Perl 5 does not support pluggable regexp engines
       It's about modularity again. Phil Hazel had to write PCRE because
       it's impossible to extract the engine from the rest of Perl. If we
       could do that, we could add in other engines, slimmed down
       versions of Perl's engine without the arcane features, and so on.
       Perl 6 should support user-space pluggable regular expression
Data, data types and variables

    1. PROBLEM: Perl does not allow strong data typing, which can be a
       hindrance when dealing with more strongly typed interfaces such as
       COM and CORBA
       Many other languages treat integers, floats and strings
       separately, but Perl treats them as several faces of the same
       data. In some environments, however, the first style is preferred.
       While it's possible to create typed variables using a tie, it's a
       bit mucky. Fixing the type of a variable in core would enable a
       number of optimisations.
       Perl 6 should support optional typing in core.
    2. PROBLEM: Perl 5 doesn't have enough support for handling binary
       The main way of handling binary data at the moment is pack/unpack.
       This is considered insufficient.
       Perl 6 should have more ways of handling binary data.
    3. PROBLEM: Perl 5 doesn't have enough support for Unicode
       Unicode should be supported from the ground up; hacking Unicode
       support into Perl 5 is proving very difficult. Perl 5.6 and above
       will feature improved Unicode support, but Perl 6 should surpass
       Perl 6 should support Unicode from the ground up.
    4. PROBLEM: Perl 5's typeglobs are messy and unpopular
       Typeglobs are overused today. Features available through typeglobs
       (such as reflection) should remain, but the mechanisms to
       implement them could be cleaned up.
       Typeglobs should be removed from Perl 6.
    5. PROBLEM: Perl 5's file handles are not first class variables
       Typeglobs are generally disliked (see above). Promoting file
       handles to be first class variables is one part of making
       typeglobs unnecessary.
       Perl 6 should promote file handles to first class variables.
    6. PROBLEM: Perl 5's data types do not mesh well with some C
       Some C language extensions for Perl don't mesh well with Perl's
       current implementation. This involves such issues as the
       difference between char *'s and SVs, and modules which use event
       loops not easily supported in Perl.
       Perl 6 should support data types which work better with C
    7. PROBLEM: Perl 5 does not support pluggable data types
       It has been suggested that it would be useful for Perl to be
       pluggable enough to support data types such as bigints, sparse
       strings, complex numbers, etc.
       Perl 6 should support pluggable data types.
    8. PROBLEM: Perl 5 does not support the use of any scalar value (eg
       references) as hash keys
       Currently, hash keys are strings. It would be nice to be able to
       use any SV (for example, a reference) as a hash key.
       Perl 6 should support the use of any SV as a hash key.

    1. PROBLEM: Perl 5's object creation process is too complex
       To create objects, you currently have to mess around with
       $VERSION, AutoLoader, Exporter, @ISA, etc. It would be nice to
       simplify this process so that mere mortals can understand it.
       Perl 6 should make object creation easier.
       Integrate the functionality of Exporter into the language.
    2. PROBLEM: Perl 5's object methods are much slower than built-in
       Perl 6 should improve the speed of accessing object methods.
    3. PROBLEM: The "objects are just blessed data" model is awkward for
       programmers who come from a more formal OO background
       Perl 6's OO model and syntax should be brought more closely into
       line with other OO languages.
    4. PROBLEM: Perl 5 uses an arrow where other languages use a dot
       Perl currently uses the -> operator both as an infix dereference
       operator and to call methods on objects. While the first usage is
       relatively familiar to C programmers, the second causes a fair
       amount of confusion. It has been suggested that moving to a dot
       will alleviate this confusion, however this will result in the
       concatenation operator becoming overloaded.
       Perl 6 should consider supporting the use of a dot for calling
       object methods.
Errors and warnings

    1. PROBLEM: error handling for eval() code does not supply useful
       Errors inside evals often come with no indication of where in the
       eval they occurred.
       Perl 6's error reporting should show where in an eval an error
    2. PROBLEM: the -w warnings flag is not on by default
       Many people believe that the warnings flag should be on by
       default, as this catches many common programming errors for both
       novice and experienced Perl programmers.
       Perl 6 should consider turning on warnings by default.
    3. PROBLEM: the strict pragma is not used by default
       Like warnings, the strict pragma can provide a certain degree of
       assistance in writing less buggy Perl code. Many people believe
       that it should be used by default.
       Perl 6 should consider using the strict pragma by default.
    4. PROBLEM: when warnings are turned on, an undefined variable will
       cause an error but the error message will not mention which
       variable is causing the problem
       The error message Use of uninitialized value at -e line 1. can be
       confusing if several variables are used on that line.
       Perl 6 should name which variable is causing an uninitialized
       value warning.
Running Perl

    1. PROBLEM: Perl 5 does not allow for distribution of pre-compiled
       Many programmers and distributors of Perl applications wish that
       they could pre-compile their code, both to obfuscate the original
       source and to avoid having to distribute the Perl interpreter.
       Perl 6 should be able to create pre-compiled binaries.
    2. PROBLEM: Perl 5 does not allow programmers to hide or obfuscate
       their code
       Related to the previous point, many Perl programmers wish to
       obfuscate their source code, usually citing (bogus) intellectual
       property reasons. Most of the Perl community consider this to be
       anathema, however it may be more desirable than having projects
       eminently suited to Perl developed in Java instead. (Java is a
       popular choice for those who wish to obfuscate their code)
       Perl 6 should be able to obfuscate source code.
    3. PROBLEM: Perl 5 does not implement two pass compilation/byte code
       Perl currently executes a script via two pass/byte code
       compilation. However, the intermediate byte code is not saved
       anywhere for later re-use (Python does this). The B::Bytecode
       module does this, but the functionality could be implemented in
       the core.
       Perl 6 should be able to save bytecode for later use.
    4. PROBLEM: Perl 5 cannot be used as an embeddable language
       It would be nice to be able to run Perl on a Palm Pilot. Nuff
       Perl 6 should have a low memory footprint and be able to run on
       embedded systems such as the Palm Pilot.
Interfaces, APIs, and talking to other languages

    1. PROBLEM: Perl 5 does not support object frameworks such as CORBA,
       COM, or XPCOM
       Perl needs to support CORBA, COM, and Mozilla's XPCOM to maintain
       its status as a glue language. CORBA in particular is very popular
       with KDE and GNOME.
       Perl 6 should support CORBA, COM, and XPCOM.
Library, Modules, CPAN

    1. PROBLEM: The Perl 5 standard library does not include certain
       commonly-needed modules, such as
         a. LWP
         b. HTML
         c. XML
       Perl programmers should be able to expect that a full Perl
       installation will include a good set of common libraries. The
       current Perl core libraries do not adequately address common
       development requirements. In particular, the core library should
       include more modules for web development and applications
       Perl 6's core library should include a good set of common
       libraries for system, web, and applications development.
    2. PROBLEM: The Perl 5 standard libraries are inconsistent in their
       naming conventions, APIs, etc
       The current set of modules distributed with Perl have been
       developed by a number of authors in a range of styles. This can
       cause difficulties for developers. Greater consistency in module
       APIs and naming conventions will help people use Perl as a
       complete development environment.
       Perl 6's standard library modules should have common naming
       conventions and APIs.
    3. PROBLEM: Perl 5 suffers from a form of "DLL Hell" whereby
       upgrading some modules can break other modules
       Sometimes upgrading one module can break other modules. Upgrading
       the broken modules can, in turn, break more modules, leading to a
       chain reaction which frustrates users and makes Perl development a
       painful experience.
       Perl 6 should alleviate module incompatibility problems.

    1. PROBLEM: the POD documentation style lacks some desirable features
       Wishlist features include:
          + license identification
          + authorship and email address
          + structured README files
          + syntax checking for example code
       Perl 6's POD implementation should be more featureful.
    2. PROBLEM: there is no translation mechanism between POD and Docbook
       and/or XML
       There exist tools which can translate from POD to HTML, Unix man
       pages, and plain text. Tools to translate into Docbook and/or XML
       (both increasingly popular formats for documentation) would
       complete the set, and make POD a more useful format.
       Perl 6 should be distributed with tools to convert from POD to
       Docbook and XML.
       The Pod::Docbook module is one way of achieving this; a tool based
       on this module could be included with the Perl distribution.
    3. PROBLEM: Perl 5's design decisions are not clearly documented
       To understand the design decisions underlying Perl 5, it is
       necessary to read through huge archives of the p5p mailing list.
       It would be nice to have an archive of documents discussing each
       design point.
       Perl 6's full documentation should include an archive of documents
       explaining design decisions
Development process and community

    1. PROBLEM: p5p has been too busy for people to keep up with
       Having one large list for all Perl 5 development has led to a
       situation where many developers simply cannot keep up with the
       Perl 6's development process should allow for developers to be
       involved without having to read everything about everything.
          + Multiple lists
          + One main list, with small split-off lists for specific tasks
          + One big list with regular summaries, along the lines of
            Mark-Jason Dominus's p5p roundups
    2. PROBLEM: p5p has been prone to flamewars
       In the past, p5p has been host to some very heated discussions.
       These discussions and the argumentative/confrontational atmosphere
       that they engender have discouraged some people from participating
       in the development process. Lately, the "referee" system has
       alleviated this problem on the p5p list.
       Perl 6's development process should seek ways to avoid having
       mailing lists become too flame-prone.
    3. PROBLEM: the Perl community at large has been insufficiently
       informed of the Perl 5 development process
       The above two issues have led to many Perl avoiding p5p and hence
       being cut off from the development process of Perl itself.
       The Perl 6 development process should seek to inform and include
       Perl users who may not have been involved in Perl 5's development.
    4. PROBLEM: Not all Perl mailing lists are archived on the web, or
       the locations of the archives are not well known
       Archives of Perl mailing lists have been set up only occasionally,
       and on an ad-hoc basis. This makes it hard for people to find
       posts which pre-date their membership of a list, or which they
       haven't explicitly saved. Since older discussions often lead to
       policy or design decisions, and regularly answer frequently asked
       questions, it is worthwhile making archives of lists readily
       available to both list subscribers and those with a more casual
       Archives of all Perl 6's development mailing lists should be
       readily accessible via the World Wide Web.
    5. PROBLEM: The handling of patches for Perl 5 is not as well managed
       as it could be. In particular, it is hard for people to follow a
       patch submission and possible subsequent application of the patch
       When a patch is submitted for Perl 5, it is unclear what happens
       to it from there on. The process of submission, evaluation, and
       (eventual) approval needs to be clearly understood by anyone who
       might wish to submit a patch. This includes both current and --
       more importantly -- potential developers.
       Perl 6 should have a clearly documented procedure for patch
       submission, evaluation, and approval.
    6. PROBLEM: Perl 5 has not been widely accepted by corporates and
       managerial types
       Perl is often considered to be unsuitable for development work in
       corporate environments. In particular, Java is often chosen as a
       web or applications development language, ostensibly because it is
       platform independent, well supported, object oriented -- and a
       host of other things that Perl is too.
       The Perl 6 development and deployment process should include
       consultation with, and marketing to, corporate and managerial
    7. PROBLEM: Perl 5's distribution via OS vendors and other vendors
       has been somewhat haphazard
       Some vendor distributions of Perl have been obsolete or beta
       releases, had broken documentation, or other such problems. Other
       vendors choose not to distribute Perl for perceived reasons of
       security, etc. This reflects badly on Perl as a language, even
       though it's not the fault of the language. These problems have
       occurred both on proprietary/commercial operating systems and on
       Linux and other open source operating systems. These problems may
       also occur with applications, toolkit, or middleware
       The Perl 6 development and deployment process should include
       liaison with both proprietary/commercial and open source operating
       system and software vendors.
    8. PROBLEM: Perl 5's testing and QA process has been somewhat
       Perl 5 has not had a formal quality assurance process. A QA
       process and a team of people performing that process would help
       ensure that Perl is as good as it can be, and documentably so!
       Perl 6 should have a formal QA process.
       Michael Schwern has already set up the mailing
       list and started the ball rolling.

    1. PROBLEM: Perl 5's support for persistence frameworks are obscure
       and fragmented
Requirements not related to problems in Perl 5

    1. REQUIREMENT: Perl 6 should provide a smooth upgrade path from Perl
       For people to move to Perl 6, they need to be reasonably
       comfortable that their scripts will continue to work, or at the
       worst will require no more than a little tweaking.
       Perl 6 should be able to run 95% or 95% of Perl 5 programs.
          + backwards compatibility
          + switch to enable Perl 5 compatible mode
          + Perl 5 to Perl 6 translation tools
          + Use CPAN modules as a test for the compatibility/translation

Kirrily Robert -- <> --
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About