Whither Perl 5? - Page 172
June 18, 2001
From the conception of Perl 6 attention has been paid to the
future of Perl 5. Given its widespread use powering many a Web
site, Perl 5 is not likely to disappear anytime soon.
Realistically, the Perl developers see Perl 5 and 6 coexisting
for some time — counted in years — and the arrival of
the latter does not immediately render the former obsolete. There
are no plans to abandon work on Perl 5 as far as refinements and
bug fixes.
A more crucial question for migration is whether and how Perl 6
will be able to run Perl 5 scripts. There may be many cases where
Perl 6 is installed on a system containing many Perl 5 scripts,
and automatically breaking these scripts is an extremely
undesirable solution. Because of sometimes significant changes
between Perl 6 and Perl 5, it cannot be assumed that Perl 5
syntax would be understood by the Perl 6 interpreter. With
regards to packages and modules, the distinction between Perl 5
and Perl 6 code is easily made: any "package" declaration will
necessarily be Perl 5 code, because Perl 6 does away with
"package" in favor of two more specific replacements: "module"
and "class". For the main section of program code, Larry Wall is
currently advocating an opt-in solution for Perl 6 — that
is, the interpreter will assume a script is Perl 5 unless
otherwise designated. The exact mechanism for this opt-in
approach remains undecided.
Major Ambitions
Perl 6 is not intended as a timid statement. Flexibility has
always been a cornerstone philosophy in Perl — "there are
many ways to do it". Whereas some cite the opportunity for a
programmer to twist Perl to conform to his or her own taste's as
a liability, the Perl developers certainly do not agree, which is
why Perl 6 promises an even more adaptable environment for
developers, including an increased decoupling of the syntax
model. The hope is that a decoupled syntax model could allow
developers to write Perl code using syntax that conforms to
Python or
JavaScript, for example, if so
desired.
Object orienatation has long been a thorny subject for Perl 5,
with many claiming that its presence has been like the ways of a
Sunday church-goer — Perl 5 believes in object orientation,
but it's not a fundamental way of living. Perl has always tried
to please everyone and rather than shy away from this philosophy,
it's taken one step further in Perl 6: everything becomes an
object, including variables, but the programmer can usually opt
not to treat them as such.
Compiling and decompiling Perl is another central ambition for
Perl 6. Distributing compiled binaries of Perl code, without the
source, may be frowned upon by the Open Source movement but is a
feature much desired by many developers — whatever their
reasons. Plans for a migration tool that can decompile Perl 5
into Perl 6 code would also ease help flatten the path for
developers.
Speaking of Perl developers, a crucial issue in the introduction
of Perl 6 is
CPAN.
This repository of contributed modules from hundreds of
developers around the world is one of Perl's largest strengths.
Yet, with most of these modules written in Perl 5, an extensive
education and/or migration program will need to take place so
that Perl 6 is not deprived of CPAN's rich resource.
Departures from Perl 5
The majority of developers will be mostly interested in how Perl
6 differs from Perl 5, and what new features it offers. In some
cases, the departures are themselves the new features. While none
of these are carved in stone yet, Larry Wall has made a number of
decisions that have an air of certainty about them, if not the
actual atmosphere.
Variables
Perl 6 features data types more formally than seen before in
Perl. While the Perl 6 developers will generally be able to rely
on typeless values, a number of types are introduced including
INTEGER, NUMBER, STRING, REF, SCALAR, ARRAY, HASH,
REGEX, CODE and int, num, str,
ref. The capitalized data types support object
oriented access. Use of these types in Perl 6 scripts will
provide an element of safety — in being able to constrain
and validate values — as well as improved performance
because Perl won't have to make type determinations at run-time.
For example,
my int $dayofmonth=14;
my str $dayofweek="Thursday";
Here we create integer and string scalar variables. Later in the
script, if these values change they can be validated as being the
proper type, and Perl will know the types at compile-time,
improving performance.
Another significant departure in Perl 6 is the use of variable
prefixes. In Perl 5 we all became familiar with $, @,
% and scalar, list, and hash prefixes respectively. These
are not changing in Perl 6. However, one of the more confusing
aspects of Perl 5 was that only scalars could be references, and
so in the list named @colors the first color would
be referenced as $colors[0].
To reduce this awkwardness of changing prefixes, in Perl 6 each
type of variable may be a reference, and so in the list
@colors the first element would be
@colors[0].
On a related note, Perl has always been very context sensitive.
That means it behaves differently depending on whether it is in a
scalar context or a list context. For example, in Perl 5 context
was determined at times by prefixes (the $ or
@) and at times by subscripts (such as
[0]). Perl 6 clarifies things again by suggesting
that the prefix is simply part of the variable name and does not
imply context; rather, only the subscript will provide context
information, as to whether the expression should be treated in
scalar or list context for example.
The Perl You Need to Know Part 25: Life Cycles -- A Series Ends, A New Perl Is Born - Page 172
The Perl You Need to Know
Interpolation - Page 173
|
