Front page | perl.bootstrap |
Postings from July 2000
Re: perl 6 requirements
Thread Previous
|
Thread Next
From:
skud
Date:
July 31, 2000 17:32
Subject:
Re: perl 6 requirements
Message ID:
20000801103244.B14585@netizen.com.au
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
first.
However, since you've asked...
K.
Perl 6 Requirements Document
Kirrily Robert
_________________________________________________________________
Introduction
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,
<skud@netizen.com.au>. Major contributors (those who sent me prepared
material for inclusion in this document) include:
* Adam Turoff <ziggy@panix.com>
* Simon Cozens <simon@brecon.co.uk>
* Garrett Goebel <garrett@scriptpro.com>
The latest version of this document is available from
http://infotrope.net/opensource/software/perl6/. 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 $
_________________________________________________________________
Internals
1. PROBLEM: Perl 5's internals are overly complex
DISCUSSION:
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.
REQUIREMENT:
A complete redesign of the internals will need to put emphasis on
modularity, simplicity, extensibility and maintainability.
2. PROBLEM: Perl 5 is bloated
DISCUSSION:
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
accumulates.
REQUIREMENT:
Remove little-used features from the Perl core, perhaps leaving
them accessible if they are required.
SUGGESTED SOLUTIONS:
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
easily
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
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
http://www.jwz.org/doc/gc.html and a full academic survey of GC
techniques at http://www.cs.wisc.edu/~zhong/termproj_surveyGC.html
REQUIREMENT:
Perl should use the most efficient suitable garbage collection
technique.
SUGGESTED SOLUTIONS:
Mark-and-sweep garbage collection
5. PROBLEM: Perl 5's signal handling is broken
DISCUSSION:
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.
REQUIREMENT:
Make Perl 6's signal handling both safe and re-entrant.
_________________________________________________________________
Language
Miscellaneous language issues
1. PROBLEM: Perl 5's syntax is disliked by programmers familiar with
other languages
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should add support for a main loop
SUGGESTED SOLUTIONS:
+ 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
DISCUSSION:
People want to do this:
try {
foo
} catch {
bar
};
which you can probably do with the Exceptions module or similar.
REQUIREMENT:
Perl 6 should support exceptions.
SUGGESTED SOLUTIONS:
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)
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should support stackable I/O filters.
SUGGESTED SOLUTION:
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
DISCUSSION:
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.
REQUIREMENT:
Working threads!
6. PROBLEM: Perl 5's syntax cannot be parsed by Perl
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
Damian Conway, of course, has a paper on this.
REQUIREMENT:
Add a real switch or case statement to core.
8. PROBLEM: Perl 5 does not support nested uses of each()
DISCUSSION:
The each() function uses a single counter, so it is not possible
to nest the use of each() within an each() loop.
REQUIREMENT:
Perl 6 should allow the nested use of each().
_________________________________________________________________
Unixcentrism
1. PROBLEM: localtime's behaviour is non-intuitive for non-Unix
people
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should provide time functions which are not based on C's
struct tm and which are more intuitive to novice programmers.
SUGGESTED SOLUTIONS:
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
DISCUSSION:
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")) {
...
}
REQUIREMENT:
Perl 6's system() should return true on success.
3. PROBLEM: several functions in Perl 5's core are Unix-centric, eg
shm*
DISCUSSION:
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.
REQUIREMENT:
All non-portable core functions should be removed from Perl 6.
SUGGESTED SOLUTIONS:
They can be put into separate libraries.
_________________________________________________________________
Obsolete features
1. PROBLEM: Formats are not commonly used and are not needed in the
core language
DISCUSSION:
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
module.
REQUIREMENT:
Formats should be removed from Perl 6.
SUGGESTED SOLUTIONS:
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
DISCUSSION:
Many of Perl's special variables are now deprecated, obsolete, or
dangerous. More of them will become so
REQUIREMENT:
Unnecessary perlvars should be removed from Perl 6.
SUGGESTED SOLUTIONS:
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'})
_________________________________________________________________
Regexps
1. PROBLEM: Perl 5 does not allow access to the regexp engine's
internals for debugging
DISCUSSION:
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.
REQUIREMENT:
Perl 6's regular expression engine should be accessible to mere
mortals.
2. PROBLEM: Perl 5 does not support pluggable regexp engines
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should support user-space pluggable regular expression
engines.
_________________________________________________________________
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
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should support optional typing in core.
2. PROBLEM: Perl 5 doesn't have enough support for handling binary
data
DISCUSSION:
The main way of handling binary data at the moment is pack/unpack.
This is considered insufficient.
REQUIREMENT:
Perl 6 should have more ways of handling binary data.
3. PROBLEM: Perl 5 doesn't have enough support for Unicode
DISCUSSION:
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
that.
REQUIREMENT:
Perl 6 should support Unicode from the ground up.
4. PROBLEM: Perl 5's typeglobs are messy and unpopular
DISCUSSION:
Typeglobs are overused today. Features available through typeglobs
(such as reflection) should remain, but the mechanisms to
implement them could be cleaned up.
REQUIREMENT:
Typeglobs should be removed from Perl 6.
5. PROBLEM: Perl 5's file handles are not first class variables
DISCUSSION:
Typeglobs are generally disliked (see above). Promoting file
handles to be first class variables is one part of making
typeglobs unnecessary.
REQUIREMENT:
Perl 6 should promote file handles to first class variables.
6. PROBLEM: Perl 5's data types do not mesh well with some C
extensions
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should support data types which work better with C
extensions.
7. PROBLEM: Perl 5 does not support pluggable data types
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
Currently, hash keys are strings. It would be nice to be able to
use any SV (for example, a reference) as a hash key.
REQUIREMENT:
Perl 6 should support the use of any SV as a hash key.
_________________________________________________________________
OO
1. PROBLEM: Perl 5's object creation process is too complex
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should make object creation easier.
SUGGESTED SOLUTIONS:
Integrate the functionality of Exporter into the language.
2. PROBLEM: Perl 5's object methods are much slower than built-in
functions
DISCUSSION:
REQUIREMENT:
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
DISCUSSION:
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
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
information
DISCUSSION:
Errors inside evals often come with no indication of where in the
eval they occurred.
REQUIREMENT:
Perl 6's error reporting should show where in an eval an error
occurred.
2. PROBLEM: the -w warnings flag is not on by default
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should consider turning on warnings by default.
3. PROBLEM: the strict pragma is not used by default
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
The error message Use of uninitialized value at -e line 1. can be
confusing if several variables are used on that line.
REQUIREMENT:
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
binaries
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should be able to create pre-compiled binaries.
2. PROBLEM: Perl 5 does not allow programmers to hide or obfuscate
their code
DISCUSSION:
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)
REQUIREMENT:
Perl 6 should be able to obfuscate source code.
3. PROBLEM: Perl 5 does not implement two pass compilation/byte code
compilation
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should be able to save bytecode for later use.
4. PROBLEM: Perl 5 cannot be used as an embeddable language
DISCUSSION:
It would be nice to be able to run Perl on a Palm Pilot. Nuff
said.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
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
development.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should alleviate module incompatibility problems.
_________________________________________________________________
Documentation
1. PROBLEM: the POD documentation style lacks some desirable features
DISCUSSION:
Wishlist features include:
+ license identification
+ authorship and email address
+ structured README files
+ syntax checking for example code
REQUIREMENT:
Perl 6's POD implementation should be more featureful.
2. PROBLEM: there is no translation mechanism between POD and Docbook
and/or XML
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should be distributed with tools to convert from POD to
Docbook and XML.
SUGGESTED SOLUTIONS:
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
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
Having one large list for all Perl 5 development has led to a
situation where many developers simply cannot keep up with the
volume.
REQUIREMENT:
Perl 6's development process should allow for developers to be
involved without having to read everything about everything.
SUGGESTED SOLUTIONS:
+ 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
DISCUSSION:
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.
REQUIREMENT:
Perl 6's development process should seek ways to avoid having
mailing lists become too flame-prone.
SUGGESTED SOLUTIONS:
Refereeing.
3. PROBLEM: the Perl community at large has been insufficiently
informed of the Perl 5 development process
DISCUSSION:
The above two issues have led to many Perl avoiding p5p and hence
being cut off from the development process of Perl itself.
REQUIREMENT:
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
DISCUSSION:
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
interest.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
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
DISCUSSION:
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.
REQUIREMENT:
The Perl 6 development and deployment process should include
consultation with, and marketing to, corporate and managerial
types.
7. PROBLEM: Perl 5's distribution via OS vendors and other vendors
has been somewhat haphazard
DISCUSSION:
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
distributions.
REQUIREMENT:
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
haphazard
DISCUSSION:
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!
REQUIREMENT:
Perl 6 should have a formal QA process.
SUGGESTED SOLUTION:
Michael Schwern has already set up the perl-qa@perl.org mailing
list and started the ball rolling.
_________________________________________________________________
Uncategorised
1. PROBLEM: Perl 5's support for persistence frameworks are obscure
and fragmented
DISCUSSION:
REQUIREMENT:
_________________________________________________________________
Requirements not related to problems in Perl 5
1. REQUIREMENT: Perl 6 should provide a smooth upgrade path from Perl
5
DISCUSSION:
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.
REQUIREMENT:
Perl 6 should be able to run 95% or 95% of Perl 5 programs.
SUGGESTED SOLUTIONS:
+ 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
tools
--
Kirrily Robert -- <skud@netizen.com.au> -- http://netizen.com.au/
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
Thread Previous
|
Thread Next