HEAD: A Taste of Perl 6

DECK: A dozen tempting new features of the forthcoming Perl 6

TOC_LINE: Perl 6 will be the language's first major revision since the
           early 90's. We look at why, how, who, what, and when.

AUTHOR: Damian Conway


I<"Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's
    rewrite of Perl...and of the community.">
        -- Larry Wall, State of the Onion speech, OSCon 2000.

SUBHEAD: If it ain't broke, why fix it?

First of all, Perl 5 I<ain't> broke. Those of us who are working on
the design of Perl 6 are doing so precisely because we like Perl 5 so
much. We like it so much that we use it everyday, for everything from
filtering our mail, to maintaining our servers, to formatting this very
paragraph.

It's I<because> we like Perl 5 so much that we want it to be even 
better.
Perl 5's goal was to make "easy things easy, and hard things possible".
It does that very well, but we believe it could do more. We believe it
could make easy things trivial, hard things easy, and impossible things
merely hard.

Moreover, our love of Perl doesn't blind us to its flaws. Those C<$>,
C<@>, and C<%> prefixes on variables are confusing; some of its other
syntax is unnecessarily cluttered; it lacks some basic language features
(like named subroutine parameters, or strong typing, or even a simple
case statement); its OO model isn't really strong enough for most
production environments; and the list goes on.

So the Perl 6 design process is about keeping what works in Perl 5,
fixing what doesn't, and adding what's missing. That means there will be
a few fundamental changes to the language, a larger number of extensions
to existing functionality, and a handful of completely new features.
This article showcases some of the ways in which these modifications,
enhancements, and innovations will work together to make the future Perl
even more insanely great.

Without, we hope, making it even more greatly insane.


SUBHEAD: Sigils simplified

Let's start with those mysterious C<$>'s, C<@>'s, C<%>'s, C<&>'s and 
C<*>'s
that can be such a source of grief for newcomers to Perl (and can
occasionally trip up experts too!)

They're called "sigils" and the most important news is that Perl 6 will
keep most of them. We did consider removing them completely (as some
people requested), but we concluded that they are far too valuable to
remove. They make it much easier to interpolate a variable into a
character string or regular expression. And they provide important
sanity checks on the arguments of various built-ins (finding logical
errors like C<pop %hash> and C<keys @array>).

But we're modifying how sigils relate to their variable, in a way that
actually reduces mistakes, rather than causing them. In Perl 5,
the type of sigil a variable requires depends on how it's being used,
and in particular what kind of value that usage is supposed to produce.
Consider the code in Listing 1.

[ BEGIN Listing 1 -- Accessing hashes and arrays in Perl 5 ]

C<
01 # Perl 5 code...
02
03 print keys %hash;
04 print $hash{"name"};
05 print @hash{"name", "rank", "cereal preference"};
06
07 print @array;
08 print $array[0];
>

[ END Listing 1 ]

If you're using a hash as a full hash (as in line 3), you use the
normal "hash sigil" (C<%>). But if you're looking up a single entry in
the hash (line 4), and hence expect a single scalar value back, you use
the "scalar sigil" (C<$>). And if you're looking up several entries
at once (line 5), and expecting to get back a list of values, you use
the "array sigil" (C<@>).

Likewise, when you want the full array (as in line 7), you use C<@>, but
when you want just a single element of it (line 8) you use C<$>.

It's a logical enough system -- at least until we throw subroutine
references and method calls into the mix, at which point to breaks
down completely. More importantly, it doesn't fit well into many
people's brains.

That's because sigils act rather like English demonstrative articles
("that value", "these values", "those values"). But an English article
always agrees with the underlying plurality of the object it
demonstrates, I<not> with the plurality of the bit(s) of the object
you're currently interested in.

So when you say "pass me those apples" and "pass me one of those apples"
the "those" stays plural, whether you're asking for one or all of the
fruits. But in Perl the equivalent requests are:

C<
pass(@apples);      # "Pass those apples"
pass($apples[1]);   # "Pass one of that apples"
>

To most programmers that's simply counter-intuitive.

So Perl 6 will change how sigils operate. In the new version of Perl,
they'll cease to be adjectives and become an indivisible part of the
nouns themselves. Listing 2 shows what that means for the five C<print>
statements shown in Listing 1.

[ BEGIN Listing 2 -- Accessing hashes and arrays in Perl 6 ]

C<
01 # Perl 6 code...
02
03 print keys %hash;
04 print %hash{"name"};
05 print %hash{"name", "rank", "cereal preference"};
06
07 print @array;
08 print @array[0];
>

[ END Listing 2 ]

The previous complicated rules about selecting the sigil according to
the nature of the value(s) being returned are replaced with a single
rule that simply says: "If it's a hash, use C<%>; If it's an array,
use C<@>; If it's a scalar, use C<$>. Always."

Not only is that vastly easier to teach, to learn, and to remember, it
also has the elegant side-effect of silently fixing one of the most
common mistakes made by Perl programmers. Many programs include code
that locates and returns a particular data structure (say a hash) by
reference. That reference is then usually stored in a local scalar
variable, through which the hash is later accessed. Like so:

C<
$data = locate_hash_for("required data");

# then later...

print $data{"particular_entry"};
>

In Perl 5 that's a nasty and subtle error. The first line stores a
reference to a hash in the scalar variable C<$data>. But later a
particular entry is looked up in the hash C<%data>. Same name, different
variables. In fact, the C<$data{...}> syntax has I<nothing> to do with
the variable C<$data>. Instead, it means: "Look up the entry in
C<%data>, using the C<$> prefix on the variable because it's returning a
single value".

What they should have written was:

C<
print $data->{"particular_entry"};
>

which dereferences the hash reference in C<$data> (using the C<< -> >>
operator) and then looks up the particular entry.

But people just don't think that way. So they're constantly being
bitten by this mistake. Fortunately, in Perl 6, it's not a mistake at
all. Because the sigil is determined by the variable, rather than the
value(s) it's providing, C<$data> I<always> means the scalar variable.
So C<$data{"particular_entry"}> always means "look up the entry in the
hash whose reference is stored in C<$data>".

We suspect that when people port their code from Perl 5 to Perl 6 many
of these kinds of hidden bugs will simply "evaporate", because the
language semantics will have been changed to match how people actually
think and code.


SUBHEAD: A Swiss Army case statement

Perl's problem isn't that it doesn't have a case statement. Its problem
is that, because it doesn't have one standard case statement, people
have invented 23 alternative "case patterns". Everything from
the pedestrian:

C<
# Perl 5 code...

$val = 'G4';

    if ($val eq 'A4') { print "paper" }
elsif ($val eq 'B4') { print "prior" }
elsif ($val eq 'C4') {   die "BOOM!" }
  else                { print "huh??" }
>

to the baroque:

C<
# Perl 5 code...

$val = 'G4';

({ 'A4'    => sub { print "paper" },
    'B4'    => sub { print "prior" },
    'C4'    => sub {   die "BOOM!" },
  }->{$val} || sub { print "huh??" }
)->();
>

In Perl 6, there's no need (nor any temptation) to jury-rig such
awkward inefficient solutions. Instead, there is a single, standard,
built-in, control statement that does the job:

C<
# Perl 6 code...

$val = 'G4';

given $val {
   when 'A4' { print "paper" }
   when 'B4' { print "prior" }
   when 'C4' {   die "BOOM!" }
   default   { print "huh??" }
}
>

The C<given> statement associates the value in C<$val> with the special
Perl "current topic" variable C<$_>. This association lasts for the
duration of the associated block. Then each successive C<when> statement
within the block compares its associated value (C<'A4'>, C<'B4'>, etc.)
against the current value of C<$_>. The first C<when> statement whose
value matches C<$_> has its associated block executed, after which
control passes straight to the end of the surrounding block.

Though this seems no different in essence from a case statement in
many other languages, there is far more power here than first meets
the eye. The way each C<when> compares its value against C<$_> is
determined by the (runtime) types of the two values being compared. In
the above example, each C<when> value is a string, so the string in
C<$val> is compared against each of them using Perl's C<eq> string
comparison operator.

However, if the code had been:

C<
# Perl 6 code...

$val = 'G4';

given $val {
   when 'A4' { print "paper" }
   when %B4  { print "prior" }
   when /C4/ {   die "BOOM!" }
   when &D4  { print "huh??" }
}
>

then the first C<when> would still compare against C<$val> using
C<eq>, but the second C<when> would treat the string in C<$_> as a key
into the C<%B4> hash and consider the match successful if the
corresponding element in the hash contained a true value. The third
C<when>, on the other hand, would note that the C<$_> was being
compared against a regular expression, so it would use pattern
matching to compare the two. And the final C<when>, finding a
subroutine (C<&D4>), would pass C<$_> as an argument to that
subroutine and consider the match successful if C<D4($_)> returned
a true value.

It may sound complex, but it isn't really. In all instances, the C<when>
just automatically chooses the most appropriate way to compare the
"given" value (i.e. C<$_>) against the current case. In other words, it
just Does What You Mean.

A more practical example of the power, flexibility, and convenience of
this approach can be seen in the following code, which guesses an
encoding scheme based on the first character in the data:

C<
given $first_char {
   when [0..9]    { $guess = 'dec' }
   when /<[A-F]>/ { $guess = 'hex' }
   when &is_ASCII { $guess = '7-bit' }
   when %known    { $guess = %known{$_} }
   default        { die Cannot::Guess }
}
>

Interestingly, because a C<given> statement is really a function -- one
that returns the final value from any successful nested C<when>
statement -- this example could also have been written as:

C<
$guess = given $first_char {
   when [0..9]    { 'dec' }
   when /<[A-F]>/ { 'hex' }
   when &is_ASCII { '7-bit' }
   when %known    { %known{$_} }
   default        { die Cannot::Guess }
}
>

Considering Perl's predominantly C/Unix background, people often wonder
why we chose C<given> and C<when> as keywords, rather than C<switch> and
C<case>. There were two reasons. Firstly, because C<given> and C<when>
read much more naturally, and are therefore much easier for non-C/Unix
programmers (now the majority of Perl's users) to understand. But more
importantly, we chose new keywords because the constructs they label are
vastly more powerful than a mere C<switch> statement.

For a start, a C<when> always compares its value against C<$_>,
whether or not it's inside a C<given>. It doesn't care whether
C<$_> was set by something else entirely. So a C<when> can be used in
I<any> context that has an active C<$_>, not just inside a C<given>.

For example, in Perl a C<for> loop successively aliases C<$_> to the
list of values it's iterating , so in Perl 6 it's possible to combine
looping and selection in a very efficient and readable manner:

C<
# Perl 6 code...

for (@events) {
   when Mouse::Over       { change_focus($_) }
   when Mouse::Click      { make_selection() }
   when Window::Enter     { change_focus($_) }
   when Window::Close     { delete_window()  }
   when /unknown\s+event/ { log_event($_)    }
}
>

Here, the first five cases have class names as their values, so their
C<when> statements attempt to match each event object by checking 
whether it
belongs to that class. The last C<when>, on the other hand, uses a 
pattern
match as its test. So that C<when> treats the event object as a string 
(by
implicitly invoking the object's coercion-to-string method) and then
checks whether that coerced string matches the specified pattern.

Just as a C<when> doesn't have to be associated with a C<given>, so
too a C<given> doesn't have to depend on nested C<when>s. A C<given>
statement always sets C<$_>, whether or not that C<$_> is ever examined
by a C<when>. So, within a C<given> block I<any> of the Perl constructs
that default to operating on C<$_> -- including the new unary
dereference operator (C<.>) -- can be used. As Listing 3 illustrates,
that gives Perl 6 the equivalent (and more) of a Pascalish C<with>
statement.

[ BEGIN Listing 3 -- Another use for C<given> in Perl 6 ]

C<
01 given $obj_ref {
02   .synchronize();
03   %data = .get_data;
04   given %data {
05     .{name} = uc .{name};
06     .{addr} //= "unknown";
07     print;
08   }
09   .set_data(%data);
10 }
>

[ END Listing 3 ]

Within the lexical scope of its associated block, the outer C<given>
(line 1) aliases C<$_> to an object reference. Then lines 2, 3, and 9
use the new "unary dot" notation to call the C<synchronize()>,
C<get_data()>, and C<set_data()> methods of that object. Without having 
to
explicitly and repeatedly re-refer to the C<$obj_ref> variable.
Similarly, the inner C<given> (line 4) lexically aliases C<$_> to the
C<%data> hash, enabling its various entries to be accessed without
having to explicitly write C<%data> everywhere. So too, the C<print>
statement at line 7 defaults to printing C<$_>, and hence prints the
updated hash.

The Perl 5 equivalent of this code is considerably more cluttered with
repeated referents, as Listing 4 demonstrates.

[ BEGIN Listing 4 -- Repetitious referents in Perl 5 ]

C<
01 do {
02   $obj_ref->synchronize();
03   %data = $obj_ref->get_data;
04   do {
05     $data{name} = uc $data{name};
06     $data{addr} = "unknown" if !defined $data{addr};
07     print %data;
08   }
09   $obj_ref->set_data(%data);
10 }
>

[ END Listing 4 ]

Perl has waited a long time for a real case statement, and the one it's
finally getting is the most powerful, flexible, and generalized tool we
could invent.


SUBHEAD: Takes all types

Data types and type specifications take a much more prominent role in
Perl 6. It isn't that Perl 5 is weakly typed (as many people seem to 
think).
It's just that it lacks some important compile-time type-specification
mechanisms.

For example, in Perl 5 there's no (easy) way to set up a variable that
is only permitted to store integers. Or only references to objects of
class Widget. Or an array whose elements must be character strings. Or a
hash whose values must be references to arrays of numbers. In Perl 6
there is. When declaring a variable (with a C<my> or C<our> keyword),
the type of the variable can be specified immediately after the keyword:

C<
my Int $number;
my Widget $obj_ref;
my Str @strings;
my Array of Num %counters;
>

In fact, Perl 6 variables can be more precisely typed than variables in
most other languages, because Perl 6 allows you to specify both the
B<storage type> of a variable (i.e. what kinds of values it can contain)
and the B<implementation type> of the variable (i.e. how the variable
itself is actually implemented).

For example, a declaration like:

C<
my Num @observations is SparseArray;
>

specifies that the C<@observations> variable is required to store
numbers, but takes the necessary internal structure and behaviour to
do so from the C<SparseArray> class (rather than from the usual
C<Array> class)

Explicit typing extends to Perl 6 subroutines as well. For example:

C<
sub Num mean(Int @vals) {
   return sum(@vals)/@vals;
}
>

specifies that the C<mean()> subroutine takes an array
of integers and returns a number. We could also write
that:

C<
sub mean(Int @vals) returns Num {
   return sum(@vals)/@vals;
}
>

This extended form is handy when the return type is more complicated.
For example, the following subroutine definition specifies that
C<hist()> takes an array of integers and returns another array of
integers (namely, the frequency histogram it creates):

C<
sub hist(Int @vals) returns Array of Int {
   my Int @histogram;
   for @vals { @histogram[$_]++ }
   return @histogram;
}
>

The C<Array of Int> notation is an example of the way that compound
types are composed in Perl 6. The compound type is constructed by 
passing
the "inner" type (the one after the C<of>) to the constructor of the
"outer" type (the one before the C<of>). This allows the outer type (in
this example, C<Array>) to determine how to implement the required
storage and behaviour to allow it to hold integers.

Note that most of the subroutines shown throughout this article
have proper named parameter lists. Those parameters, just like
all other variables, may be given simple or compound types,
just as the C<@vals> parameter was in the first line of C<hist()>.

That's "I<may> be given", not "I<must> be given". Explicit typing is
entirely optional in Perl 6. It's still perfectly valid to specify a
subroutine with neither formal parameter list, nor return type:

C<
sub hist {
   my @histogram;
   for @_ { @histogram[$_]++ }
   return @histogram;
}
>

Of course, without named parameters, you have to access the
subroutine's arguments via the standard C<@_> variable. And
now there's no guarantee that each element of that argument
list is an integer suitable for indexing the C<@histogram> array.

But the point to remember is that this "untyped" version of C<hist()>
isn't untyped at all. It's simply using the standard I<default
types> (as Perl 5 always does). We could get precisely the same
"untyped" effect with explicit typing:

C<
sub hist(Scalar @_) returns Array of Scalar {
   my Scalar @histogram;
   for @_ { @histogram[$_]++ }
   return @histogram;
}
>

So strong typing isn't optional in Perl 6. Only I<explicit> strong
typing is. In the absence of type specifications, Perl will simply use
its default types. And, in those situations where more type-precision is
called for, you can explicitly provide it.

This is a distinctly Perlish approach to typing: it doesn't get in the
way unnecessarily, it tries to "Do The Right Thing" automatically, and
it provides a specific syntax to override the defaults for those times
when Doing the Right Thing isn't quite the right thing to do.


SUBHEAD: Avaunt, foul homonyms!

One of the few ways in which Perl 5's "natural language" approach
doesn't seem to work so well is in the naming of some of its built-in
control structures and functions. For example, the C<do> keyword has
three entirely unrelated purposes (it marks expression blocks, calls
subroutines, and loads source code from a separate file). Likewise, the
C<eval> keyword is used both to compile and execute text strings and to
intercept exceptions. The C<select> function mediates two utterly
unrelated I/O behaviours. The C<goto> keyword is used both for
unconditional control jumps and for stack-frame manipulation. Even the
C<for> loop has two very different behaviours (fixed-count iteration and
C-like conditional repetition) depending on how it's used. All-in-all
it's a mess.

Every one of those "homonyms" will be dehomogenized in Perl 6. For
example, C<eval> will be reserved for compiling strings, and its
exception handling duties will be taken over by the new C<try> 
statement.

The C<for> statement is particularly troubling, because not only is it a
homonym, but one of its two meanings also has a "synonym" -- C<foreach>.
In Perl 6, both those maintenance headaches have been removed.

The old-style C-like Perl 5 C<for> statements:

C<
for (my $i=0; $i<@list; $i++) {
   print "$list[$i]\n";
}

for (;;) {
   my $text = <>;
   last if $text =~ /END/;
}
>

has been renamed and tidied up a little:

C<
# Perl 6 code...

loop (my $i=0; $i<@list; $i++) {
   print "@list[$i]\n";
}

loop {
   my $text = <>;
   last if $text =~ /END/;
}
>

The C<for> keyword will now be used exclusively for fixed-repetition
loops of the form:

C<
for (@list) {
   print "$_\n";
}
>

This syntax has been tidied up too. There is no longer a variant that
explicitly allows an iterator variable to be specified:

C<
# Perl 5 code...

for my $iter_var (@list) {
   print "$iter_var\n";
}
>

Instead, in Perl 6, the block being controlled by the C<for> statement
is treated as an anonymous subroutine (in the same way as the block of a
C<sort> or C<map> is in Perl 5). And the value currently being iterated
by the C<for> loop is passed to that subroutine as its argument. That
means, in Perl 6, you'd write the above example as:

C<
# Perl 6 code...

for (@list), sub($iter_var) {
   print "$iter_var\n";
}
>

Now you're probably thinking that that's I<seriously> ugly compared
to the old Perl 5 way. And we agree. That's why we've defined a
graphical synonym for the C<sub> keyword: C<< -> >>. So you can (and
should) write:

C<
# Perl 6 code...

for (@list) -> $iter_var {
   print "$iter_var\n";
}
>

which reads quite naturally, and conveniently separates the list from 
the
iterator variable. Better still, because the iterator variable is really
a parameter of the following block, it's automatically lexically scoped
to that block (without the clutter of an explicit C<my> keyword).

And there's nothing to say that the subroutine a Perl 6 C<for> loop 
controls
has to have exactly one parameter:

C<
# Perl 6 code...

for @nrc -> $name, $rank, $cereal_pref {
   print "$rank $name likes $cereal_pref\n";
}
>

That is, if a C<for> loop's block specifies I<N> parameters, on each
iteration the C<for> will grab the next I<N> values from the list it's
traversing. So, because the block above has three parameters after the
C<< -> >>, the C<for> takes three values from the list on each
iteration. That's especially handy for working through the contents
of a hash:

C<
# Perl 6 code...

for %config.kv -> $key, $value {
    print "$key = '$value'\n";
}
>

Here the C<kv()> method of a hash is called to produce a list of
alternating keys and values, and each key/value pair is then iterated in
parallel. Incidentally, the C<kv()> method will be available for arrays
too, making it easy to directly iterate through the elements of an
array but still have access to their corresponding indexes as well:

C<
# Perl 6 code...

for @readings.kv -> $N, $value {
    print "Reading $N was $value\n";
}
>

And, by using the new "zipper" function -- which interleaves the
elements of two or more arrays into a single list -- you can even
traverse multiple lists in parallel:

C<
# Perl 6 code...

for zip(@names, @ranks, @cereal_prefs)
      -> $name,  $rank,  $cereal_pref {
   print "$rank $name likes $cereal_pref\n";
}
>

These changes to Perl's C<for> loop simplify the simple cases and
greatly extend Perl's ability to handle more challenging iteration
problems. Those improvements reflect a fundamental principle that is
guiding the entire language redesign: "More power, less syntax, same
great Perlish flavour".


SUBHEAD: Properties: Post-It notes for Perl

Another new feature in Perl 6 is the notion of "properties". Ever wish
you could annotate a variable, a subroutine, or a piece of data? For
example, to keep track of where a value came from, or the units it's
measured in? Or to suggest that a subroutine be memoized? With Perl 6
properties, you can do all those things.

Every value, variable, subroutine, and class in Perl 6 can have one or
more "out-of-band" pieces of information associated with it. Those extra
data can modify the way an item behaves or is evaluated, or they can
simply be passive reminder notes attached to it.

For example, in Perl 5 a scalar value is true so long as it's not
undefined, nor zero, nor an empty string. But that leads to subtle
problems with code like:

C<
while ($val = next_val()) {
   report($val);
}
>

This fails nastily if C<next_val()> ever has to return a value of
zero or an empty string. The solution in Perl 5 is to change the
nature of the test:

C<
while (defined($val = next_val())) {
   report($val);
}
>

But the solution in Perl 6 is far more lateral in its thinking:
(temporarily) change the nature of truth!

That is, the C<next_val()> subroutine could be implemented like this:

C<
sub next_val {
   # get value here somehow
   return undef if $failed_to_get_value;
   return $value but true;
}
>

That C<but true> on the final return value is the key to the whole
solution. The C<but> operator takes the value of its left operand and
"annotates" that value with the property specified by its right operand.
In the above example, it's used to set the C<true> property of
whatever the next value is. So Perl 6 sees that value as being true,
regardless of the normal truth or falsehood of the actual value itself.

In a similar way, Perl 6's C<system> command will be modified so
that it returns either C<0 but true> on success or C<$errcode but
false> on failure. That way, C<system> can still return the
appropriate error codes on failure, but will not longer be prone to
subtle logic errors such as:

C<
if (system "patch <$patchfile" ) {
   print "$patchfile successfully applied\n";
   unlink $patchfile;
}
>

Here, if the C<patch> utility manages to apply the patch, the C<system>
call will return 0, which is Unixish success but Perlish falsehood. So,
in Perl 5, the C<if> statement won't execute its block and the patch 
file
won't be cleaned up. Worse, if C<patch> fails for some reason, C<system>
will return its (non-zero) exit status, so the C<if> I<will> execute,
deleting the unapplied patch.

But the same code works perfectly in Perl 6 because, although C<system>
still returns an integer status code, that number is "annotated"
with a property (C<but true> or C<but false>) that makes it behave
correctly in Perl boolean contexts.

Any kind of Perl value can have any kind of property associated with it.
For example:

C<
$next_value = <> but tainted;
$self_ref = \$self_ref but weak;
$another_val = <$file> but Source($file);
$passwd = 'bart' but NB("find better pw");
>

Value properties like these make it easy to track insecure data (C<but
tainted>) or make specific references invisible to garbage collection
(C<but weak>), or record where the data came from (C<but Source(...)>),
or just associate a reminder with some value (C<but NB(...)>).

In addition to transient properties on values, Perl 6 also allows you to
define more permanent properties on variables, subroutines, methods, and
classes, using the C<is> operator. Listing 5 illustrates some
typical ways in which such properties may be used.

[ BEGIN Listing 5 -- Properties in Perl 6 ]

C<
01 my $PI is constant = 3.1415926;
02 my $semaphore is shared;
03 my @hourly_rainfall is dim(10,366,24);
04
05 sub fib($n) is cached {
06   return fib($n-1)+fib($n-2) if $n>1;
07   return 1;
08 }
09
10 class Employee is interface;
11
12 class Manager is Employee
13               is Employer
14               is Decision::Maker;
15
16 method set_salary is private;
>

[ END Listing 5 ]

The C<is constant> property (line 1) prevents a Perl variable
from being assigned to once it's been initialized. The C<is shared>
property (line 2) causes a variable to be shared across multiple 
threads.
The C<is dim> property (line 3) defines a fixed-size
multidimensional array.

Properties can be given to subroutines and methods too, for example to
make them memoize return values (line 5) or specify that they should
not be accessible outside their defining scope (line 16).

Properties on classes can be used to indicate that a class should
act merely as an interface specification (line 10), or can be used
to specify the superclasses from which a class inherits (lines 12-14).

Properties act like adjectives and adverbs. They're a means of
fine-tuning the meaning and behaviour of data and processes within a
Perl 6 program. That's a very powerful facility, because it gives us a
clean and consistent way to create new modifications and extensions to
the core language...without actually having to modify or extend the
language itself.


SUBHEAD: Industrial-strength OO

Perl 5's object-oriented features are powerful, flexible, mutable,
extensible, minimalist, and thoroughly in keeping with Perl's "There's
More Than One Way to Do It" philosophy. And to many people that makes
them totally unsuitable for implementing production code.

Listing 6 shows a simple, but typical, Perl 5 class definition that
illustrates why.

[ BEGIN Listing 6 -- Class declaration in Perl 5 ]

C<
01 package Staff::Record;
02
03 sub new {
04   my ($class, $name, $rank, $cereal_pref) = @_;
05   my $self = bless { name=>$name, rank=>$rank, pref=>$cereal_pref }, 
$class;
06   $self->check_rank($rank);
07   return $self;
08 }
09
10 sub name {
11   my ($self) = @_;
12   return $self->{name};
13 }
14
15 sub rank {
16   my ($self, $new_rank) = @_;
17   if (@_ > 1) {
18      $self->check_rank($new_rank);
19      $self->{rank} = $new_rank
20   }
21   return $self->{rank};
22 }
23
24 sub check_rank {
25   my ($self, $rank) = @_;
26   die "Invalid rank for ", ref($self), " object: $rank"
27     unless 0 < $new_rank && $new_rank < 10;
28 }
29
30 # Other methods here
>

[ END Listing 6 ]

C<Staff::Record> is a class (even though the keyword says C<package>).
C<new()>, C<name()>, C<rank()>, and C<check_rank()> are polymorphically
dispatched methods of the class (even though the keywords say C<sub>).
Objects of the class are really just hashes, which have been associated
with the class by the C<bless> function (line 5). Hence, all the other
methods of the class access the data stored in those methods via hash
entry look-ups (lines 12, 19, and 21).

Unfortunately, because they're really just hashes, the entries of all
Staff::Record objects are equally accessible outside the methods of the
class. There's absolutely nothing to stop anyone from by-passing the
C<name()> and C<rank()> methods completely and out in the main program
writing something like:

C<
$obj->{name} = "Mudd";
$obj->{rank} = 1000000;
>

The C<new()> method acts like a constructor, and hence expects to be
called on the class itself, as opposed to C<name()> and C<rank()>, which
expect to operate on objects. The C<check_rank()> method is really just
an internal utility, and not intended to be part of the class's public
interface. Notice however that there is nothing in the way the methods
are defined that indicates (or enforces) these important distinctions.

As you can see, there are numerous opportunities for this kind of code
to go horribly (and subtly) wrong. Which is why we're adding a new,
declarative OO mechanism to Perl 6. Listing 7 shows the corresponding
class under Perl 6.

[ BEGIN Listing 7 -- Class declaration in Perl 6 ]

C<
01 class Staff::Record {
02   has Str  $.name;
03   has Int  $.rank;
04   has Hash $.pref;
05
06   method CREATE(Str $name, Int $rank, Hash $cereal_pref) {
07     .check_rank($rank);
08     ($.name, $.rank, $.pref) = ($name, $rank, $cereal_pref);
09   }
10
11   method name() returns Str {
12     return $.name;
13   }
14
15   method rank() returns Str {
16     return $.rank;
17   }
18
19   method rank(Int $new_rank) {
20     .check_rank($new_rank);
21     $.rank = $new_rank;
22   }
23
24   method check_rank(Staff::Record $obj: Int $rank) is private {
25     die "Invalid rank for $obj.class() object: $rank"
26       unless 0 < $rank < 10;
27   }
28
29   # Other methods here
30 }
>

[ END Listing 7 ]

Notice first that the keywords now correspond to the constructs they
define: C<class> for classes, C<method> for methods. The class
itself is confined to the scope of a block. The attributes of the
class are explicitly defined using the C<has> keyword (lines 2 to 4),
with special names that start with a dot. And they're no longer directly
accessible outside the class's block.

There is no need to define a C<new()> constructor; it's generated
automatically by the class definition. Instead, a specially named
initializer method (lines 6 to 9) is defined and simply assumes that the
object it is setting up will already have been created for it.

Methods can be declared private (line 24) using a property. They can
have proper parameter list and return types. They no longer need to
refer to their object explicitly; within a method, attributes can be
accessed directly, by their (dotted) variable name (as at lines 12,
16, and 21).

However, when a named I<invocant> (i.e. an explicit reference to the
calling object) is required, it can still be specified: at the start of
the method's parameter list (as it is for C<check_rank()> at line 24).
The declaration of the invocant is separated from the method's normal
parameters by a colon. Whether or not an object reference has been
explicitly declared, within a method C<$_> is always aliased to the
invoking object. That means that the unary dot operator can be used to
call other methods from within a method (as C<check_rank()> is at lines
7 and 20).

Methods can be overloaded within a class (for example, the two C<rank()>
methods defined at lines 15 and 19), so long as the variants can be
distinguished by their parameter lists. Method calls can even be
directly interpolated within a character string (as C<$obj.class()> is
at line 25).

Many of the details of the new OO mechanism are yet to be finalized. For
example, Perl 6 will also provide delegated dispatch of methods,
multiple dispatch (i.e. method selection based on the types of two or
more parameters at once), anonymous classes, interfaces, multiple
inheritance, and parametric classes. The syntax and semantics of all
those features are yet to be locked down.

In the meantime, it's certain that Perl 6 will make object-oriented Perl
coding more declarative, more secure, more robust, and far more
standardized. Ironically, it does all that in its usual postmodern way:
by extending the existing language to I<increase> the programmer's
choice of tools.


SUBHEAD: Add our vector, Victor!

Something that occasionally surprises newcomers to Perl is that arrays
don't always act like arrays. For example, whenever they're used in a
context that expects a scalar value (such as the operands of a C<+>
operator), arrays evaluate to a single number: their own length. That's
convenient when it comes to writing C<for> loops:

C<
for (1..@lines) {
   print "$_: $lines[$_-1]\n"
}
>

or when you're computing an average:

C<
$average = sum(@vals)/@vals;
>

But is also means that the behaviour of a statement like:

C<
my @payroll = @salaries + @bonuses;
>

can seem quite counterintuitive. You might expect that the addition of
two arrays would treat each operand as a vector, and add each salary to
the corresponding bonus, producing a list of total wages to be stored in
C<@payroll>.

However, that's not what happens. The C<+> operator requires scalar
operands, and that requirement forces the two arrays to evaluate to
their respective lengths, which are then added and assigned as the sole
element of C<@payroll>.

But these kinds of "vector" operations are very common in some
application areas and it's very annoying to have to write them
like so:

C<
# Perl 5 code...

my $max = @salaries < @bonuses ? @bonuses
                                : @salaries;
my @payroll;
$payroll[$_] = $salaries[$_] + $bonuses[$_]
   for 0..$max-1;
>

Perl 6 rectifies this deficiency by providing a modifier syntax that can
be applied to any operator. This modifier converts the operator to a
vector form. Operators are vectorized by placing the symbols C<È> and
C<Ç> around them. That's right, the Unicode codepoints 00BB
("RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK") and 00AB ("LEFT-POINTING
DOUBLE ANGLE QUOTATION MARK") respectively. Or, if you're still stuck in
ASCII, you can use C<<< >> >>> and C<<< << >>> instead. So, in Perl 6,
that vector payroll calculation is just:

C<
@payroll = @salaries È+Ç @bonuses;
>

or:

C<
@payroll = @salaries >>+<< @bonuses;
>

And if there were fines to be subtracted, you could extend it to:

C<
@payroll = @salaries È+Ç @bonuses È-Ç @fines;
>

Nor does it matter what dimensions the arrays operands happen to have.
If the operands were both three-dimensional tables, then the vectorized
operators would still add their corresponding individual elements,
producing another 3D table.

If one operand is of lower dimensionality, it is simply replicated as
many times as necessary. For example, if the bonus to be added were a
fixed amount for every person, you could write:

C<
01 @payroll = @salaries È+Ç $common_bonus;
>

and the scalar value in C<$common_bonus> would be added to every element
of C<@salaries>, just as you'd expect.

The vector markers can be placed around any unary or binary operator,
and around any subroutine or method call as well. When placed around a
subroutine call, that subroutine is called on each element, and a list
of the individual results is constructed. For example, the minimum
number of bits required to encode a fixed set of symbols is bounded by
its Shannon entropy, which is zero minus the sum of the products of each
symbol's probability multiplied by the binary log of that probability.
In English that's quite painful, but in Perl 6 it's just:

C<
print -sum(@probs È*Ç ÈlogÇ(@probs))/log(2);
>

The equivalent C<print> statement in Perl 5 is less straightforward:

C<
print -do{ my $sum = 0;
            $sum += $_ * log($_) for @probs;
            $sum;
          }/log(2);
>

The benefits of supporting these types of "Single Instruction Multiple
Data" statements might not be immediately obvious, but they are very 
real.
There are many situations where a computational loop could be evaluated 
in
parallel (either in separate threads, or separate processes, or even on
separate processors) if only the compiler could determine that the
sequence of computations is independent. With vectorized operations
that's often the case I<by definition>, so vectorizing a calculation may
be a significant optimization in Perl 6.

And even when there won't be any performance boost, the notation is
still much more compact and declarative, encoding I<what> to do, rather
than I<how> to do it. And that's always a win when it comes to
maintenance.


SUBHEAD: Parallel data

Perl 6 will introduce an entirely new scalar data-type: the "junction".
Junctions are like a collision between set theory, boolean logic,
quantum state superpositions, and SIMD parallel processing.

That probably sounds terrifying but, curiously, in practice it isn't at
all. The way junctions are used is very straightforward and convenient.
Consider the following two C<if> statements:

C<
if ( any(@new_values) > 10 ) {
   print "Too big\n";
}

if ( all(@new_values) < 0 ) {
   print "Too small\n";
}
>

You can almost certainly work out what's happening there just by reading
the code aloud. The C<any> function takes a list of scalar values as its
arguments and returns a "junction" of those values. That is, it returns
a single scalar value that is equivalent to I<any> of the arguments it
was given. So the first C<if> statement means exactly what it says: "If
any of the new values is greater than 10, print a message." In other
words, comparing the junction returned by C<any> against the value 10
implicitly compares all of the values from C<@new_values> against 10.
And if any of them is greater than 10, then the overall comparison is 
true.

Likewise, in the second C<if>, the call to C<all> creates a junction
that is equivalent to all the values at once. Hence, the subsequent
comparison against zero is true only if I<all> the new values are less
than zero.

"Any" junctions are known as I<disjunctions>, because they act like
a Boolean OR: "this OR that OR the other". "All" junctions are known as
I<conjunctions>, because they imply an "AND" between their values --
"this AND that AND the other".

There are two other types of junction available in Perl 6:
I<abjunctions>, which represent exactly one of their possible values at
any given time:

C<
if ( one(@roots) == 0 ) {
   print "Unique root to polynomial\n";
}
>

and I<injunctions>, which represent none of their values:

C<
if ( $passwd eq none(@previous_passwds) ) {
   print "New password accepted\n";
}
>

Junctive comparisons like these are ideal candidates for compiler
optimization -- by distributing the computations involved to parallel
threads, or processes, or processors. The notation also provides an
easily understandable (and hence maintainable) way to incorporate
parallel processing into a serial language.

Nor is that parallelization restricted to linear processing. In the
following Perl 6 example, the I<N>xI<M> comparisons required between the
two sets of values could all be performed in parallel:

C<
if ( any(@new_values) > all(@old_values) ) {
   print "New maximum value recorded\n";
}
>

The equivalent Perl 5 code is much slower, far less clear, four
times as long, and consequently has been banished to Listing 8.

[ BEGIN Listing 8 -- I<N>xI<M> comparison in Perl 5  ]

C<
01 # Perl 5 code...
02
03 my $any_true = 0;
04 for my $new (@new_values) {
05   my $all_true = 1;
06   for my $old (@old_values) {
07     $all_true &&= ($new > $old) or last;
08   }
09   $any_true ||= $all_true and last
10 }
11 if ($any_true) {
12   print "New maximum value recorded\n";
13 }
>

[ END Listing 8 ]

Junctions also act as mathematical sets. For example, you could read in
text lines and print them out without repetitions (like the Linux 
C<uniq>
utility does, only without the requirement that repeated lines be 
adjacent):

C<
for (<>) {
   next when $seen;
   print;
   $seen = any($seen,$_);
}
>

The C<< for (<>) >> reads each input line in turn and aliases it to the
C<$_> variable. The C<when> then compares that line against the junction
in C<$seen>. If the current line matches any of the previously seen
lines, the C<when>'s comparison will succeed and the C<next> command
will cause Perl to skip immediately to the next iteration of the C<for>
loop. Otherwise, the input line is printed. Then the final statement in
the block updates the set of "seen" lines by creating a new set (i.e. a
junction) consisting of all the previously seen lines plus the current
input line.

That last line is, admittedly, a little clunky. But Perl 6 also provides
a binary operator (C<|>) that creates an "any" junction from its two
arguments. So you could rewrite the last line much more cleanly as:

C<
   $seen = $seen | $_;
>

or, better still, as:

C<
   $seen |= $_;
>

Alternatively, by changing the sense of the comparison
you could use an "all" junction instead:

C<
for (<>) {
   if $_ ne $seen {
      print $_;
      $seen = all($seen,$_);
   }
}
>

Because C<$seen> now contains an "all" junction, the comparison
C<$_ ne $seen> means "the current line is not equal to all the
previous lines", which is exactly what's wanted. Here too, Perl 6
provides a binary operator (C<&>) to facilitate creating "all"
junctions, so the last line could be written more cleanly as:

C<
      $seen &= $_;
>

By the way, if you're wondering what happened to the bitwise boolean
operators that C<|> and C<&> represent in Perl 5 (and C), they're still
available. But their dual Perl behaviours have been "factored out" and
renamed:

         * C<+|> for bitwise OR on a number,
         * C<~|> for bitwise OR on a string,
         * C<+&> for bitwise AND on a number,
         * C<~&> for bitwise AND on a string.

The junctive binary operators are particularly handy for tests on a 
fixed
number of values. For example, the ability to code tests of the form
"if [A or B or C] is zero" is an often-requested language feature; one
that junctions provide in a very natural way:

C<
if ($A|$B|$C == 0) {
   print "Coefficients must be non-zero\n";
}
>

Another feature that is often asked for is the ability to easily detect
if a particular value appears in a list. With junctions, that's just:

C<
if ( $value == any(@list) ) {...}
>

This solution is far superior to providing an explicit C<in> operator:

C<
# NOT Perl 6 code...

if ( $value in @list ) {...}
>

because the use of junctions allows you to select the most appropriate
form of comparison for a particular list:

C<
if ( $value == any(@list) ) {...}
if ( $value eq any(@list) ) {...}
if ( fuzzy_match($value,any(@list)) ) {...}
>

The first C<if> checks if any element of C<@list> is numerically equal
to C<$value>, whereas the second checks if any element is equal to
C<$value> under string comparison, whilst the third looks for list
membership as defined by some user-supplied subroutine.

Junctions also provide "union types". That is, if you need a variable
that can store either integers or file descriptor objects, but
nothing else, in Perl 6 you can declare precisely that:

C<
my Int|FileDesc $variable;
>

The type specified for C<$variable> is a junction of the C<Int> and
C<FileDesc> types so, whenever a value is assigned, its run-time type is
compared against I<both> types simultaneously, and the overall
comparison succeeds if either type comparison succeeds.

But, of course, junctions give you more than just unions. You can also
specify "intersection types", such as:

C<
my FloorWax&DessertTopping $shimmer;
>

This declaration requires that any object assigned to C<$shimmer> must
belong to I<both> the C<FloorWax> and C<DessertTopping> classes. (Like
Perl 5, Perl 6 allows multiple inheritance, so it's perfectly possible
to create objects that inherit from two unrelated classes.)

Using an injunction, you can even create a variable that will store
anything I<but> a particular type of value:

C<
my none(Soup) $for_you;
>

This declaration means that you're allowed to assign any type
scalar value to C<$for_you>, as long as it isn't a reference to a
C<Soup> object.

In addition to Perl 6's threads, coroutines, and vector operators,
junctions provide yet another kind of parallelism: for data, types, and
procedures. And, though junctions can be enormously powerful, they're
also unexpectedly intuitive.


SUBHEAD: Deniggling Perl

Apart from the new mechanisms described so far, the Perl 6 project is
also about filing off those few remaining rough edges of the language.
This minor but important fine-tuning will bring long-hoped-for features
such as multiway comparisons, simplification of the parenthesizing
rules, generalized string interpolators, and auto-dereferencing in
suitable contexts...

B<Multiway comparisons> are boolean expressions like this:

C<
if (0 <= $x < 10) {
   print "Still in single digits\n";
}
>

In Perl 5 (and C and C++ and most other languages for that matter),
an expression like that is an error: the first comparison (C<0 <= $x>)
returns a boolean value, which is then erroneously compared against
the C<10>. But humans (or, at least, mathematicians) often use this
kind of notation to specify upper and lower bounds on a value. So Perl 6
supports it too. In Perl 6, the above example is exactly equivalent to:

C<
if (0 <= $x && $x < 10) {
   print "Still in single digits\n";
}
>

except that C<$x> is only evaluated once. That's an important
distinction because it also means that, when subroutines are used in a
multiway comparison, they're only called once.

This multiway facility is available for all twelve of Perl's comparison
operators. For example:

C<
$post_aardvarkian =
   'aardvark' lt $new_word ne $last_word;
>

These chained tests ensure that the string in C<$new_word> is
lexicographically after "aardvark" and also different from the last
word chosen.

C<Parentheses> in Perl 5 aren't as convenient as we'd like. Sure, 
they're
optional around subroutine and method argument lists, and in most other
places, but they're still mandatory on control statements. Every C<if>
or C<while> condition requires them, as does every C<for> loop. They
clutter up code for no good reason except to overcome a (very uncommonly
encountered) ambiguity in the syntax.

So in Perl 6, we're making them optional in control statements too.
Instead of the Perl5-ish:

C<
for (@list) {
   if ($_ < $max) {
     while ($counter != $_) {
       print $counter++, "\n";
     }
   }
}
>

in Perl 6 you can just write:

C<
for @list {
   if $_ < $max {
     while $counter != $_ {
       print $counter++, "\n";
     }
   }
}
>

Of course, if you prefer the parens, they're still perfectly acceptable.
Just no longer required.

B<String interpolation> is one of the most useful features in Perl. It
allows allows you to construct strings by inserting text directly from
variables, much as you can in the various command shells. So, in Perl 5,
instead of stitching together a long string with concatenations:

C<
$text = $hero . " looked " . $dir
       . " and saw " . $obj . ".\n";
>

you can just write:

C<
$text = "$hero looks $dir and sees $obj.\n";
>

That's very handy, but it's still a little annoying that you to have to
create a series of temporary variables when the values being
interpolated have to be computed:

C<
my $hero = name();
my $obj  = obj($dir) || 'rats';

$text = "$hero sees $obj.\n";
>

So, in Perl 6 there is a special "string interpolator"
syntax that allows Perl code to be placed directly in
a string that's being constructed:

C<
$text = "$(name()) sees $(obj($dir)||'rats')";
>

That is, inside a Perl 6 string any text placed in a C<$(...)> is
treated as a piece of Perl code to be executed. The result of that code
is then interpolated in place of the entire C<$(...)>.

Better still, simple subroutine and method calls can be
directly interpolated into strings, without a surrounding
C<$(...)>:

C<
$text = "&name() saw $environ.objs($dir)";
>

C<Dereferencing> Perl 5 references to get at the actual variables can be
particularly annoying. Perl is renowned for it's "do-what-I-mean"
philosophy, so it seems strange that, in situations where it knows an
array or hash is expected, Perl won't accept an array reference or hash
reference, and then just dereference it for you. For example, in Perl 5
the following code doesn't work, even though the intent -- to add the
keys of C<@hash> onto the end of C<@array> -- is clear enough:

C<
$aref = \@array;  # create reference to array
$href = \@hash;   # create reference to hash

# and later...

push $aref, keys $href;  # run-time error!
>

In Perl 6, the same code just works exactly as you'd hope. It still
expects the first argument to C<push> to be an array. So, on finding an
array reference it simply "follows the pointer" to locate the array it
needs. Likewise, although C<keys> expects a hash as its single argument,
a hash reference suffices in Perl 6.

None of these minor new features is, by itself, a quantum leap for Perl
6. But programming in Perl is supposed to be easy, natural, and fun.
Eliminating those trivial everyday annoyances and facilitating less
intrusive, more intuitive ways of solving the same problems is an
essential part of making Perl programmers even more productive.


SUBHEAD: The once and future Perl

20-20 hindsight is a tremendous advantage when you're creating a
language. In designing Perl 6 we're re-examining 15 years of Perl
usage to see what we got right and what we could do better.

Many of the tools and techniques that are important to the modern Perl
community have been developed as CPAN modules -- such as PDL,
Parse::RecDescent, Inline, Memoization, List::Utils, base.pm,
attributes.pm, etc. Many of these have become so widely used that it
makes sense to integrate their functionality into the language itself.

So PDL vector operations become Perl 6 vector operators; the C<any> and
C<all> data types from Quantum::Superpositions become Perl 6
disjunctions and conjunctions; the Memoization module becomes the C<is
cached> property; and Parse::RecDescent-like grammars become part of
Perl 6's greatly enhanced pattern matching facilities (which are
evolving so significantly that we're planning a separate article on them
in a forthcoming edition).

So, like Perls 1 through 5, Perl 6 is evolving to meet the needs of its
users: taking that which has proven widely useful or commonly necessary
and making it part of the core language; relegating to external modules
that which has proved too specialized and occasional; and consigning to
oblivion those ideas that just didn't work.

Our goal is to make the next version of Perl an even more powerful tool
for today's programmer, and a tool that can grow and adapt to meet the
needs of programmers over the next two decades.


[ BEGIN Sidebar One -- "FAQs vs FUD" ]

Perl has always stirred strong emotions, both for and against it. The
Perl 6 project, with its mandate to change what needs changing in Perl,
has engendered more than its fair share of fear, uncertainty, and
doubt. Here are ten common Fearfully Asked Questions and some
brief defuddling answers:

      1. Perl 5 isn't broken. Why are you fixing it?

         Well, there are places where it I<is> broken. Or at least
         seriously sprained. Pseudohashes were clearly a mistake.
         Variable attributes are too hard to use. The syntax of regexes
         has become bloated and their semantics, arcane. Threading is
         just a nightmare. Modules don't export their functionality in a
         clean (i.e. lexical) way. The OO mechanisms aren't robust
         enough. And maintaining the Perl interpreter is now beyond the
         abilities of all but the most Ÿber of Ÿbergeeks. Those things
         need to be fixed, so we're fixing them.

      2. Isn't this a classic case of "Second System Syndrome"?

         It may I<seem> like we're throwing every possible feature into
         this new version of the language, but that's not quite the case.
         It's true that we're looking to steal...err...borrow many good
         ideas from other programming systems, but we're very conscious
         of the need to avoid creeping featurism. Our main defense
         against the temptation to assimilate every idea under the sun is
         our refusal to add anything that only solves a single problem.
         So properties have been added, but only because they unify the
         Perl 5 concepts of attributes, inheritance, and ties. Subroutine
         parameter lists have been added, but give us multi-iterator
         C<for> loops as well. Junctions have been added, but only
         because they provide multiple comparison, set operations, type
         unions, and parallel processing. Second system effect is the
         result of solving one problem at a time by indiscriminately
         bolting on new functionality wherever there's a gap. What we're
         trying to do with Perl 6 is actually the exact opposite: to
         distill out of each set of problems a common underlying
         solution, and then fit those solutions together seamlessly.

      3. If you're changing everything, why call it Perl?

         If we I<were> actually changing everything, we wouldn't call it
         Perl. But in reality we're only changing about 15% of the
         syntax of the language, 20% of the semantics, and about 5% of
         its "spirit". Perl 6 programs still look and feel like Perl.
         Programming in Perl 6 still has that same sense of ease and
         playfulness. The problem is that we generally only ever talk
         about what's changing, not the vast majority of features that
         are staying the same. In other words, the design documents are
         "diffs". To see how much is actually changing you need to patch
         them against Perl 5 and see how most of the language stays
         precisely the same.

      4. Aren't all these new features just going to slow it down?

         We certainly don't intend that to happen. In fact, many of the
         features we're adding or improving are designed to be faster and
         easier to parse, compile, and execute. Some of the new features
         (e.g. type checking) certainly will slow some code down, but
         even then we still have a much more powerful virtual machine
         on which to run (see Dan Sugalski's "Welcome to the Fjord"
         elsewhere in this issue). Overall, we expect equivalent code to
         run significantly faster in Perl 6.

      5. Aren't you just needlessly breaking all my Perl 5 code?

         We aren't breaking I<anything> in Perl 5. Perl 5 will continue
         to be available (and maintained) for many years to come. And
         Perl 6 will have built-in backwards compatibility. Any source
         file that begins with a C<package> declaration will be
         automatically treated as Perl 5 code. So porting any existing
         program will be no harder than prepending C<package Main;> to
         it. Of course, doing it that way probably won't allow you to 
take
         advantage of all the new features and performance of Perl 6, so
         we're also going to provide a Perl 5 to Perl 6 translator
         (C<p52p6>) just as we already supply translators for folks
         who are upgrading to Perl 5 from awk (C<a2p>) and sed (C<s2p>).


      6. Aren't you just needlessly breaking all the CPAN code?

         Not at all. Since every CPAN module begins with a C<package>
         declaration, they'll all trip the automatic backwards
         compatibility mode. Of course, we'll still be encouraging
         CPAN authors to migrate their modules to Perl 6, so they can
         take advantage of new language features that will make their
         modules more robust, faster, and instantly available to all
         the languages that the underlying Parrot virtual machine
         will support.

      7. But how am I ever going to learn all this new stuff?

         Gradually. Incrementally. The way you learnt Perl 5. Most of the
         basics will stay the same. And the basics that do change will
         become simpler and more consistent. As for the new advanced
         features like junctions and vector operators and multimethods,
         you won't I<have> to use them. At least, not until you discover
         that you really I<want> to use them. At which point the fine
         manual will be there to explain how.

      8. Why try and compete with Java/C#/Python/Ruby/Scheme/etc.?

         We're not. It's much worse than that... we're trying to (gasp!)
         co-operate with them.

      9. It's all just vaporware. Why is it taking so long?

         It's hardly vaporware. We've already shipped nine releases of
         Parrot, and several of them have come with a prototype Perl 6
         compiler. And there are more than a dozen CPAN modules (see the
         sidebar entitled "Impatience is a Virtue") that let you use many
         of the new Perl 6 features in Perl 5. But, yes, the design of
         Perl 6 is only about one-third complete at this point. And the
         design process I<is> taking more time than most people seem to
         have expected. Why? Because there are many things that we do
         need to fix. Because it takes time to find and fit the minimal
         set of new features that will allow us to avoid second system
         syndrome. Because, although we have a set of design milestones
         (each of Larry Wall's design documents corresponds roughly to a
         chapter in "Programming Perl, 3rd Edition"), we don't have a
         fixed timetable for delivering them. Because designing Perl 6 is
         a highly creative exercise in lateral re-thinking, one that
         we're all undertaking on a voluntary basis in our spare time.
         And because we'd rather get it right, than get it right now.

     10. You obviously need help. How can I get involved?

         The best place to start is at the dev.perl.org website. There
         you can learn about the history of the project, read the current
         design documents, and join one (or more) of the mailing lists.
         Alternatively, if your tuits are in short supply, you might
         consider contributing to the Perl Foundation
         (www.perlfoundation.org), a not-for-profit organization that
         provides funding for all things Perlish, including some key
         aspects of the Perl 6 project.

[ END Sidebar One ]


[ BEGIN Sidebar Two - "Impatience is a virtue" ]

Once working programmers see the power and elegance that Perl 6 will
provide, their most common response is "I want it now!" Although there
I<is> a prototype Perl 6 compiler already available to download from
www.parrotcode.org, we're still a few years away from a full release of
Perl 6. But it turns out you I<can> sample many of the tasty new Perl 6
features today...in Perl 5. Some of the modules listed below change Perl
5's syntax to match that of Perl 6. Others just provide similar
functionality, but with a non-Perl 6 syntax. You can grab any or all of
them from the Comprehensive Perl Archive Network (search.cpan.org).

   * B<Perl6::Currying> enables you to use Perl 6's higher-order
     functions in Perl 5.

   * B<Perl6::Interpolators> allows you to use the Perl 6 C<$(...)>
     function-interpolation syntax in Perl 5.

   * B<Perl6::Placeholders> makes Perl 6's implicitly declared parameter
     mechanism available in Perl 5.

   * B<Perl6::Parameters> allows Perl 5 subroutines to take typed
     parameter lists just like Perl 6.

   * B<Perl6::Variables> changes Perl 5's sigil rules to match those
     of Perl 6.

   * B<Attribute::Handlers> provides some of the functionality of Perl 6
     properties.

   * B<Class::Contract> implements declaratively specified, properly
     encapsulated classes, much as Perl 6 will.

   * B<Class::Delegation> provides OO delegation similar to that in Perl 
6.

   * B<Class::Multimethods> supports Perl6-style multimethods and 
function
     overloading in Perl 5

   * B<NEXT> provides Perl6-ish method redispatch in Perl 5.

   * B<Quantum::Superpositions> is the forerunner to Perl 6 junctions.

   * B<Switch> adds the Perl 6 C<given> and C<when> statements to Perl 5.

   * B<Text::Reform> is the prototype for the Perl 6 replacement for Perl
     5's C<format> statement.

   * C<Want> provides Perl 6's extended call-context detection in Perl 5.

   * B<Bundle::Perl6> is a convenient collection of many of the
     above modules.

[ END Sidebar Two ]


[ BEGIN Sidebar Three - "Resources" ]

Larry Wall's Perl 6 design documents:
   http://dev.perl.org/perl6/apocalypse/
Damian Conway's tutorials on Perl 6:
   http://dev.perl.org/perl6/exegesis/
Why Perl 6 will still be Perl:
   http://damian.conway.org/Articles/ANFSCS.html
Search the CPAN for Perl 6 related code and documentation:
   http://search.cpan.org/search?query=Perl6&mode=all
Everything else Perl6ish:
   http://dev.perl.org/perl6
The Perl Foundation:
   http://www.perlfoundation.org

[ END Sidebar Three ]