[Phoenix-pm] "Perl 6 Now" introduction

[Scott Walters]

Hi generous, helpful, supportive Perl Mongers - I have a favor to ask ;)

My technical reviewer just left on a cruise and the publisher is in a hurry
to get the first chapter to production and technical review. That's where you
come in. I'm sending the first chapter in a second email but the introduction
could use comments and the first chapter will make more sense given the
introduction (as the first chapter is kind of odd).

So, here it is, in almost-POD:



=head1 i. Introduction

I<Perl 6 Now> demonstrates the Perl 6 language's concepts, ideas, and their roots in Perl 5,
using retro-ported Perl 5 implementations as well as standard but advanced Perl 5 features.
Perl 6 Now is the early adopters guide to the Perl 6 language and it's concepts.
This book:

=over 1

=item Introduces new ideas, their applications, and why Perl is adopting them

=item Unearths dozens of modules to illustrate these ideas so Perl 5 so programmers can start using them now

=item Concentrates on modern Perl, ignoring legacy baggage

=item Solves real programming problems 

=item Gently introduces, using simpler ideas, skills demanded of senior programmers

=back


"Perl 6 Now" is for people who actually want to start using the new features 
(or merely experimenting with them) in day to day programming tasks.
All of the Perl 6-like features and changes available for Perl 5 as modules are completely
optional to use.
When you need them, they're invaluable.
This books is for people who are eager to see what has been done to Perl, and want to 
know that their favorite tricks will still work in some form.


=head2 Improving Perl

Tom Christiansen
(a famous Perl personality best known for 
co-authoring the Perl Cookbook, O'Reilly, 1998),
in his 1996 article, "Seven Deadly Sins of Perl", wrote:
Back in the Perl4 days I made a list of the greatest "gotchas" in
Perl. Almost all of those have been subsequently fixed in current
incarnations of Perl, some to my deep and abiding amazement. In that
same spirit, here's of my current list of what's-um... let's be
charitable and just say "suboptimal"...

Tom Christiansen's listed sins have long been stumbling blocks for novice and intermediate 
Perl programmers, and fixing some of them required deep seated changes to the language.
All have been addressed in the design of Perl 6, though few of them in the obvious way.
Problems were fixed by generalizing the language rather than merely removing the unpleasant bits.

Convincing you to buy this book (if you haven't already) means convincing you 
that Perl 6 is interesting, and that means selling the idea that Perl 6 introduces things you
want but might not have realized you wanted.
Besides cleaning up rough edges, Perl 6 brings to Perl a host of the most sought after
features previously lacking.

Saying that Perl could improve is not slur against Perl.
Perl 4 had already defined most of the Perl language, but it had plenty of room for improvement.
Name spaces, data structures, lexical variables, and dynamically loadable binary
extensions, added in Perl 5, make up only a small part of Perl, but they're
now considered critical parts of the language.

Advanced programmers and programmers working on large or complex projects will reach a point
where they'd benefit from features present in other languages but missing from traditional Perl 5.
Novices and those learning Perl for casual use could be surprised less often by the language.
The parts of Perl unique to Perl are now much easier to explain and teach. 

Perl is unique in that it's developed primarily in the spare time of people
who use the language for their day job.
Pie-in-the-sky notions of how things "should be" are ignored in favor of pragmatic
solutions to real problems.
Perl 6 imports ideas from other languages not merely because the language has something
Perl lacks but because these features are legitimately useful, at least in special circumstances.


=head2 Major Themes

Perl 6 is Perlier Perl. 
Some themes repeated throughout Perl 5 come back with a vengeance in Perl 6.
Here are places where Perl 6 builds on the accomplishments and design of Perl 5:

=over 1

=item List processing: Operating on sets of data is nearly as easy
as operating on individual items of data.
Sorting, searching, and iterating are Perl 5 primitives.
Perl 6 adds hyper operators, which operate on entire lists and arrays, and
setwise operations which compute intersections (and many other things) on data. 

=item Stringification and numification: objects communicate sets of data between
operators internally, and user defined logic in the object decides what the object
should look like when used as a string or number.
Perl 6 allows programmers to write their own rules for when data items should
be considered true or false and makes stringification and numification easier.

=item Contexts: Hashes, arrays, function and method calls, references, and objects
respond to the circumstances of how they're used.
Perl 6 adds more contexts, allowing function results to be transparently encapsulate
multiple return values using an object, and allowing expressions to behave as
references on demand and vice versa.

=item Compilation: Programs may be bytecode compiled and/or bundled for easy
distribution. 
Perl 6 programs may be Just In Time compiled, where the program is compiled on demand,
and Perl 6 designs in support for true compilation without any dependency on an interpreter.

=item Flow control: Meta information may be read from caught errors, and
logic runs conditionally depending on the circumstances of a blocks exit.
In Perl 6, expressions may be restructured to more easily move data between blocks.
Continuations take snapshots of program state, pipelining data between routines.
The default variable, C<$_>, is used by certain new flow control constructs.

=item Extensibility: No design can anticipate the future in any meaningful
way. 
Perl 5 left open many avenues for programmers to extend the language to 
meet their specific needs, and Perl 6 takes this idea further.

=item Stricture: Perl optionally helps verify your code given meta-information.
Better, safer, cleaner code is encouraged.

=back

Perl 6 builds on the best parts of Perl 5.
These themes manifest repeated though numerous features discussed throughout this book.
For a detailed account of topics covered in this book, see "Organization of This Book"
(XXX in this chapter? at page number ...?).


=head2 Who This Book is For

Perl 6 Now, besides showcasing distinctly Perl innovation, also
bridges Perl with ideas popularized by other programming languages such as Java, Ruby, C#, and Scheme.
As a natural consequence, programmers of those other languages find in this book Perl equivalents to familiar ideas.

However, the primarily audience is Perl 5 programmers who are curious (and in many cases, anxious) about
Perl 6.
Many Perl programmers pick up a few other scripting languages to expose themselves to new ideas,
and learning Perl 6 is a nifty way to get this exposure as Perl 6 borrows heavily from other languages.


=head3 Programming Novices

Perl 6 Now covers several university computer science topics such as
graphs, recursion, compiler diagnostics, strong typing, and other things you're 
not likely to be exposed to outside of college.
However, this book does not teach I<programming basics>.
This book could be considered a companion to "Beginning Perl" by James Lee (Apress, 2004).


=head3 Programmers of Other Languages

Larry Wall, the creator of Perl, has said that it's okay to speak a subset of Perl.
This book I<will> teach you a subset of Perl, but you must be aware that you'll 
learn a subset not used by the mainstream.
The I<entirely new> parts of Perl are interesting, useful, powerful tools for Perl programmers,
but they're not the most important features of the language.
Conversely, Perl 6 drops problematic and hard to teach parts of Perl 5 in favor of cleaner
interfaces, and this book avoids these now deprecated features.


=head3 Perl Programmers

Until now, published knowledge on Perl 6 has come from only a few sources,
the best known of which are the design documents themselves, the Apocalypses,
written by the creator of Perl, Larry Wall.
The Apocalypses are brilliantly written, but they're unreadable without a 
advanced knowledge of Perl and computer science lore.
Damian Conway's Exegeses break down Larry's design so mere mortals can follow,
and they admirably demonstrate practical uses for the new features, 
but the rationale beyond the new features is largely lost in the absence of
the required Perl and computer science lore.

Perl 6 Now was conceived as a hands on, practical guide to Perl 6 concepts and features
rather than syntax.
This book gives the background and necessary to under the Apocalypses
and the computer science lore necessary to understand the Exegesis.

Discussion of Perl concepts new to Perl 6 accomplishes little if you can't use the ideas.
CPAN modules implementing Perl 6-like features for Perl 5 lay at the heart of this book.
When I proposed this book, I had several modules in mind I thought to be non-obvious (as
well as the obvious picks).
By some fluke, I'd written one of them, and I've since written another.
I've scoured CPAN in search of more modules to demonstrate the ideas from the
Apocalypses, and I've talked to legions of Perl programmers.
Herein lies the fruit of my labor.


=head2 Today's Perl 5

Nine years ago, Perl 5 was released, introducing objects, data structures,
and lexical closures to the language for the first time. 
These nine years have not been wasted. 
Perl has been repeatedly reinvented as threads, a compiler, a decompiler, weak 
references, lvalue subroutines, tainting of input data, data structure 
serialization, and other goodies were added to the language.
Today's Perl 5 hardly resembles the Perl of yesteryear.
Some chapters document under appreciated or imperfect features of Perl 5 slated
for stability in Perl 6 (by virtue of being designed into the language rather than bolted on).

As it turns out, announcing Perl 6 was the best thing that could happen to Perl 5.
That so many experimental Perl 5 features would be selected to be part of the core
of the Perl 6 language was vindication to the people that thought them up.
This encouraged further development and more widespread adoption.
Undefined areas, like F<Switch>, were finally fully specified after being put off for too long. 
The community reached precious consensus that F<Switch> should be done and on how to do it.

Adam Turoff best put light on the situation in the article, "The State of Perl", 
published at F<http://perl.com>.

Adam writes, 
"In 2000, Larry Wall saw Perl 6 as a means to keep Perl relevant, and to keep the
ideas flowing within the Perl world. 
...
Furthermore, backwards compatibility with thirteen years (now sixteen years) of
working Perl code was starting to limit the ease with which Perl can adapt to new
demands. 
...
Today, over three years later, the Perl development community is quite active
writing innovative software that solves the problems real people and businesses face
today. 
However, the innovation and inspiration is not entirely where we thought it would be. 
Instead of seeing the new language and implementation driving a new wave
of creativity, we are seeing innovation in the libraries and modules available on
CPAN -- code you can use right now with Perl 5, a language we all know and love."

Adam continues, "In a very real sense, the Perl 6 project has already achieved its true goals: to
keep Perl relevant and interesting, and to keep the creativity flowing within the
Perl community.
One way to get a glimpse how Perl is used in the wild is to look at CPAN. 
I recently took a look at the modules list (F<http://www.cpan.org/modules/01modules.index.html>) and
counted module distributions by the year of their most recent release. 
These statistics are not perfect, but they do give a reasonable first approximation of the
age of CPAN distributions currently available".

=for production table, please

	1995:	30	(0.51%)

	1996:	35	(0.59%)

	1997:	68	(1.16%)

	1998:	189	(3.21%)

	1999:	287	(4.88%)

	2000:	387	(6.58%)

	2001:	708	(12.03%)

	2002:	1268	(21.55%)

	2003:	2907	(49.40%)	

	CPAN:	5885	(100.00%)

Adam continues, "Interestingly, about half of the distributions on CPAN were created or updated in 2003. 
[...]
If anything, Perl development, as measured by CPAN activity, is quite healthy".

Adam warns that these numbers don't tell the whole story.
Modules are uploaded for numerous reasons including bug fixes.
On the other hand, some modules have been stable for years, and merely haven't been updated
because no bug fixes are requited.
Still others have been abandoned and won't be updated regardless of Perl developments arise.
Certainly not all of those 49.40% of modules updated in 2003 represent stimulation in the
Perl 5 camp by the announcement of Perl 6, but they do indicate that the
announcement of Perl 6 has done nothing to diminish Perl 5.

These quotes were taken from somewhere in middle of the article; the article talks about the realities
of needing a new version, how Perl is actually being used today, in what
ways and to what degree Perl's user base is stable.
Adam's article is available in full at F<http://www.perl.com/pub/a/2004/01/09/survey.htm>.


=head2 Announcing Perl 6

Perl 6's roots go back to 1999, when
Chip Salzenberg announced the Topaz project to rewrite Perl's internals
(XXX footnote 1? http://www.perl.com/pub/a/1999/09/topaz.html).
The goal for Perl 6 was to make the interpreter easier to maintain, not to update the language.
Code written for Perl 1 still runs on Perl 5.8.4 with little adjustment and at that time,
no one had suggested breaking this line of compatibility.
However, each feature added to Perl created bugs in far removed parts of core and 
many highly sought after features seemed impossible to add to the Perl 5 core at all.
The internals were scaring away new developers.
Topaz eventually fizzled - rewriting Perl proved far more time consuming than expected,
and those using Perl were by and large oblivious to the plight of Perl's developers.
Cleaning up the internals is still a high priority, and L<RoadMap> delves into the
perks of rewritting the internals (such as Just In Time compilation).

The seeds were sown in 2000 when Jon Orwant 
(the reserved, universally respected editor of the Perl Journal)
walked into a The Perl Conference meeting where Larry Wall
and others were discussing reportedly mundane things.
The story goes (I'm quoting Larry here)
(XXX footnote 2? http://www.mail-archive.com/perl6-meta@perl.org/msg00409.html)
that Jon walks in, and stands there for a few minutes listening, and
then he very calmly walks over to the coffee service table in the
corner, and there were about 20 of us in the room, and he picks up a
coffee mug and throws it against the other wall and he keeps throwing
coffee mugs against the other wall, and he says "we are ****** unless
we can come up with something that will excite the community, because
everyone's getting bored and going off and doing other things".
He said "I don't care what you do, but you gotta do something big".
And then he went away.
Larry describes this "the most perfectly planned tantrum you have ever seen". 
Consensus was that Jon was right, and Perl 6 was what had to be done.
Mailing lists were set up.

Soon thereafter, Damian Conway (who wrote many of the modules mentioned in this book)
published a bold vision for improving Perl as a language by making the whole language
more consistent, intuitive, extensible, and expressive.
Current specifications for Perl 6 strongly reflect the basic goals of
this document
(XXX footnote 3? http://web.archive.org/web/20040207072905/http://www.yetanother.org/damian/Perl5+i/).
Damian Conway's suggested plan for Perl 6 drew primarily on things programmers were trying
to do with Perl 5 but were having trouble with, for one reason or another.
F<http://dev.x.perl.org/perl6/talks/> further chronicals the early history of Perl 6.

Because specifications for Perl 6 directly addressed the tasks programmers
have trouble with in Perl 5, Perl 6 has a large amount of prior art to
draw from in the form of Perl 5 modules.
The bulk of the improvements for Perl 6 are formalizations of Perl 5 modules and idioms.
Should Perl be found lacking in any serious way, at least one CPAN module would
attempt to rectify the problem.
In this way, much of what's new for Perl 6 actually started as a proof of concept in Perl 5.
These attempts are sometimes badly implemented, sometimes were just impossible to do right,
and sometimes lack nothing but being formalized as part of the language, included
into core, and documented in books on the Perl language. 

Damian Conway would later write,
(XXX footnote 4? http://www.linux.org.au/conf/2004/eventrecord/LCA2004-cd/papers/90-damian-conway_Perl6.pod), 
"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. 
(...) 
It's I<because> we like Perl 5 so much that we want it to be even better.
(...)
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".


=head2 Reading This Book

Newly introduced, indexed terms appear in I<italics>.

C<Monospace type> is used for text typed at the keyboard, including URLs, code examples,
program names, and commands to type at the shell.
In this book, most commands to be typed at the shell are invocations of the F<perldoc> command.

Should your system lack F<perldoc>, the standard documentation is also
available from F<http://www.perldoc.com> and documentation for CPAN modules
is online at F<http://search.cpan.org>.

Perl 6 and Perl 5 extensions offer new things for every part of the language so
I wrote this book in the style of a plain programming language manual with basic
concepts coming first and later chapters building on them.
Each chapter in this book introduces an idea but also leads into the next chapter.
The chapter on the F<Switch> module leads into the chapter on block control constructs,
which leads into the chapter on subroutines.
The chapter on multidimensional arrays leads into the chapter on data structures.

However, it is not an ordinary programming book.
Only the first section covers features present in traditional programming languages.
The book quickly moves on to cover features from functional programming,
object oriented programming, and things unique to Perl.
The new parts of the language make strong use of existing concepts such
as execution contexts, lexical variables, and symbol tables.
This book need not to be read straight through. 
If you like, jump straight into a topic that looks interesting. 
The chapters are extensively cross referenced.

Traditional Perl 5 style isn't depicted and not everything demonstrated
in this book is suitable for production environments 
(I've indicated throughout which ones are and aren't suitable for production,
but in general, things that merely add to or change the syntax aren't suitable
for production work, and things that add new features are).


=head2 Sales Support Perl Development and Electronic Freedom

=for production This should probably be it's own little section after a page break

Twelve and a half percent of the royalties from this book go to the Electronic
Freedom Foundation (EFF).
The EFF is a non-partisian, non-profit organization defending the rights of 
software programmers to innovate.

Twelve and a half percent of the royalties from this book go to The Perl Foundation.
The Perl Foundation accepts donations with which to sponsor Perl developers working on key projects, such
as some of those documented in this book.


=head3 The Perl Foundation

The Perl Foundation oversees Perl public relations, heads up the Perl Mongers
user groups, and managers the Perl 6 project.
TPF puts on "Yet Another Perl Conference" event around the globe, which is 
inexpensive to attend.
They maintain the F<http://perl.org> website and
work with creators of important Perl related resources such as CPAN, in which
they have an unofficial hand.
They also accept donations and use the money to sponsor projects.
In 2001 through 2003, TPF hired three core developers:

=over 1

=item Larry Wall completed some of the hardest parts of the language
design for Perl 6, including operators and subroutines, while
funded by TPF.
He also spent countless hours reading every single post to the
Perl 6 language mailing list, and responding personally to many.

=item Damian Conway was hired for 18 months and TPF flew him
to twenty cities in United States, England, Germany, Canada, and Australia,
where he presented for companies and users groups.
At the same time, he collaborated with Larry Wall on the design of Perl 6 and
wrote 14 new modules, most of which are related to Perl 6
and are discussed in this book.

=item Dan Sugalski made considerable progress on Parrot, the
virtual machine for Perl 6, while under wondering under TPF grant.
The virtual machine has garbage collection, basic I/O, and a full compliment of data types.
Dan has more recently completed the first version of support for objects.

=back

TPF has a website at F<http://perlfoundation.org> where they accept donations on-line.
Most work done by these fine folks and the dozens of other people who
active hack on Perl is still done without compensation, but compensation certainly
makes it easier to do the things you want to do.
Donating to the TPF is one of the best ways to speed development of Perl 6.
Funding development of Perl is an excellent way to entice core developers to come
to your college or user group and present (and ask for more money).
Most of all, supporting TPF is a great way to say thank you.


=head3 The Electronic Frontier Foundation

In 1991, the United States bill S.266 stated:
"It is the sense of Congress that providers of
electronic communications services and manufacturers
of electronic communications service equipment shall
ensure that communications systems permit the
government to obtain the plain text contents of voice,
data, and other communications when appropriately
authorized by law".
A couple years later, the NSA would unveil the CLIPPER chip as a system of
government issued encryption. 
High strength encryption would be made available with the understanding that 
the keys would be on file with the government.
The physical encryption chip would be placed in specially equiped telephone handsets
and PC expansion cards.
Around the same time, the creator of PGP (Pretty Good Privacy, an encryption tool), Phil Zimmermann,
and others involved in marketing PGP, were sent a letter by the United States State
Department informing them they'd need to register as arms dealers to distribute
cryptographic tools, apparently a cue taken from cold war politics.

A few short years later in 1997, people clung to the little yellow padlock icon in Netscape as their lifeline
when confiding credit card number online.
That little yellow padlock almost didn't happen.

The EFF subpoenaed details of the NSA's CLIPPER chip project and testified before congress, 
representing both future-minded businesses and privacy-minded citizens.
The EFF helped fund Phil Zimmermann's defense in the interest of setting a precedent against regulation
of crypotography.
Government provided encryption would have made the e-commerce revolution impossible.
Had the Netscape browser required expensive hardware to conduct secure transactions, it's doubtful 
online shopping would have taken off.
Remember, at the time, Netscape was a lark.
No one predicted the e-commerce revolution.

This is one example.
A sample of EFF victories include:

=over 1

=item Coordinated the defeat of S.314, the "Online Decency Act", which would make it illegal to transmit any
"obscene" material, forcing ISPs to censor all communication.
Of course, this was before ISPs were mainstream and large enough to take care of themselves,
and most people who used computer networks were on "information services" not connected to the Internet.

=item Coordinated opposition to the eventually withdrawn UCITA bill.
UCITA would make free software programmers unable to disclaim warranty against special
and incidental damages of software distributed over the Internet.
"Incidental damage" includes any money a user of the software is not able to make because
the software fails, in some circumstance, to do something it tries to do.
Commercial software has always disclaimed special and incidental damages.

=item Representing and successfully defending Jon Johansen in Norwegian court.
Jon Johansen clean-room reverse engineered the encryption on DVDs and used the knowledge
to create a DVD player for Linux.
Before this program, it was already possible to copy DVDs, but DVDs could only be played
on Microsoft Windows, Apple Macintosh computers, and dedicated DVD players.

=back

Details of past victories are available on-line at F<< http://www.eff.org/effector/ >>.
Present battles are every bit as serious, and details of current litigation and
legislation are news items at F<< http://www.eff.org >>.
Joining the EFF as a member is one of the best things you can do to protect everyones
right to innovate and use technology.


=head2 Biography of the Author

=for production This too should probably be a section after a page break

Scott Walters has been fixing things that weren't broken since he was 5 years old. 
After some brief dabbling with hardware, Scott quickly religated himself to working on software.
To this day, hardware hasn't forgiven Scott.

Scott Walters has been programming Perl since a lot of Perl 5 programmers still had their purple 
camels, which is to say, years after Perl 5 came out, which isn't all that long ago. 
The period of time in which Scott managed to ignore Perl is much more impressive - he has been banging around the
Internet since 1990, back when it wasn't lame. 
After hearing over and over that Perl is a messy language and that he should 
learn it (from two non-intersecting groups of people), Scott finally sat down and learned it. 
When someone offered him a $1000 to create a little dynamic website with it, that is.

For the past six or so years, he's worked (and hacked) primarily in Perl for various
companies, working as technology lead in two start-up companies and serving as lead programmer
on a project to implement an intranet at a major healthcare provider, among other things.
For the past four years, he has consulted full-time.
Presently, most of his work is done for Pariyatti Book Services, who has tolerated his relative
absence with relatively good humor.

Scott is involved in the Phoenix Perl Mongers where he often speaks.
He maintains F<< http://projects.netbsd.org >> (and plans to do more as soon as he figures out how
to get messages to go through on the NetBSD WWW mailing list), and of course,
works on numerous projects and modules related to Perl including the budding
F<http://perldesignpatterns.org> free documentation project.

Scott has had love affairs with Forth, SNOBOL, Scheme, and has always liked C and bash. 
He picked up a smattering of Java back in the Java 1.0 beta days, and thinks that it is okay. 
In fact, he likes most languages.
He hails from Fountain Hills, Arizona, but considers himself a Minnesotan,
even after baking in the desert heat for 5 years. 
He still has his long underwear and wool socks, just in case.


=head2 Thanks and Shouts

It's a surprise ;)


=head2 Organization of This Book

=for production This should be a little section after a page break

This book has three sections, each section corresponding to the field of
programming primiarly responsible for the new Perl features documented.
(Where ideas were new and had no field, I put the chapter where I thought best).
These fields are procedural programming, object oriented programming, and functional programming.


=head3 Section 1

Section 1 covers features implementing ideas that go back to the 1960s or 1970s.
Compiler diagnostics, constants, variables, multidimentional arrays, datastructures,
control structures, and subroutines all fit this description.
Section 1 also takes care of some preliminaries.

L<PerlIntro> speaks briefly on Perl and provides some background needed for the
rest of the book.
For instance, one module used heavily throughout the book requires a patch to
the Perl core, and this book assumes a version of Perl that hasn't been
released yet at the time of this writing, so you'll need to download, patch, and compile Perl.

L<RoadMap> lists the parts of Perl 5 and Perl 6 that you'll encounter in development
and gives some resource pointers for projects to mix Perl 5 and Perl 6 in the same
program and for projects to migrate from Perl 5 to Perl 6. 
It goes into some depth on the problem of mixing Perl 5 and Perl 6.

L<StrictureByDefault> introduces compiler diagnostics, a feature that's largely
optional in Perl, and how they relate to changes in the language.
Perl 6 increases communication between the programmer and the compiler so the
compiler is better able to help the programmer find and avoid bugs.
This is really a chapter about debugging before our chapter about debugging which is
fitting as it aims to prevent bugs from happening. 
This chapter is especially useful to new programmers. 
The bugs that novices struggle with most are exactly the ones that Perl
is best able to check for and report on - when the options are enabled.

L<ConstantValues> introduces literals and constants. 
It looks at numeric literals, string literals, and constant values such as system
symbolic constants. 
String interpolation, treating data as files, and bundling files in literal 
data are all touched upon.
Perl 6 expresses some constants differently and the rules for interpolating
hashes and arrays into strings has changed.
Perl 6 standardizes code output intropolation.

L<NamesContainersValues> introduces variables and simple arrays and hashes
and then takes a detour into variable innards. 
Perl 6 has the same four layers of abstraction variables exist in, but
all levels are much more readily accessable to programmers.
For instance, aliasing variables together allows multiple arrays and
hashes to share data and present different views of that same data.
Perl is a dynamic language, and a single variable may hold different 
datatypes at different times.
Each datatype knows how to interpret itself in various contexts.
Strings, numbers, arrays, and hashes all have different ways of deciding whether or not
they are true or false.
Perl 5 and Perl 6 both allow programmers to meddle with how data is stored
and how variables interpret the data they hold.

L<PerlOperators> examines Perl 6's truth testing operators, hyper operators,
stacked filetest operators, stacked comparison operators, and new mutating operators.
The special undefined value is more widely recognized and supported, new operators
and operator features save typing, and more expessive code is possible.

L<MultidimensionalArrays> introduces rectangular arrays. 
These are easier to explain than full blown datastructures and have the added benefit of being gentle on RAM.
They're primarily useful for processing numeric data, images, audio samples,
and other large sets of uniform data.
Perl 6 introduces vectorized operators on sets of data as well as rectangular multidimensional
arrays with minimal storage requirements.

L<DataStructures> use references, arrays, and hashes to represent irregular arrays,
linked lists, graphs, binary trees, and other structures.
Datastructures are essential to modeling data and problem solving with it.
Perl 6 simplifies datastructure construction and use and adds numerous features,
replacs weak references with garbage collection, and introduces a reference context.

L<PerlSwitch> looks at simple conditionals, starting with C<if>, and then dwelling on C<given>,
Perl's switching construct. 
The dose of structured programming will make you feel like it's the 70's all over again,
setting the stage for far more interesting control structures later in the book. 

L<BlockStructure> shows how to break out of loops and how to provide code to run as blocks
are exited in different ways, an idea introduced in Perl 6. 
It also takes a first look at the idea of variable scope.

L<PerlSubroutines> shows how to write and call subroutines, including the bulit-in functions
that are always available. 
It examines argument processing, context, prototypes, and formal parameter lists. 
Subroutines may provide different contexts to their arguments, just as built-in functions do.


=head3 Section 2

Section 2 is about ideas coming out of the software industry.
Software shops have a love affair with object oriented programming. 
Objects are a social institution that communicates to new programmers how to jump
into a project and establishes boundaries between programmers so that responsibilities
and faults are clear.
CPAN demonstrates this admirably.
Objects are a technical institution that lets the compiler help you by 
performing more sanity checks than any reasonable human would bother to write.

L<ModulesOnDemand> introduces CPAN, the Comprehensive Archive Network, and ideas
of code compilation, packaging, and distribution, with an eye towards rolling
out desktop applications in the corporate setting or for download with the
professional flurishes.

L<PerlObjects> discusses writing classes and objects in Perl. 
It examines the syntax for constructors, accessors, and inheritance.
Perl 6 does most of the work for you including processing arguments to an implied
constructor - creating a class is as easy as creating a data structure.
Notes on navigating interfaces that return object help programmers deal with
the more complex modules available for Perl.
Objects may present themselves as a string, number, boolean value, array, or hash when
used as such.
Objects may be given rules to define their sorting order and to decide whether they're
logically equivalent to another object.
Methods called in object context should return objects, such as iterators, or
bundles of data.

L<PerlExceptions> looks at object oriented style error handling, which really has
little to do with objects or object oriented programming but does allow
programs to understand what has gone wrong and deal with it accordingly. 

L<TypeSafety> introduces a whole class of static analysis that object oriented languages
can perform on your program.
Objects encourage the programmer think about what the exact classes of problems are
and work out what routines are capable of handling what data. 
Chances for reuse and problem cases both become evident when this is done.
This continues the idea, introduced in L<StrictureByDefault>, that if you give the
compiler more information about what you're trying to do, it can help you do it
(or atleast help you to not not do it).

L<MultiThreading> is a quick introduction to threads in Perl. 
It teaches the ideas of concurrency and its evil twin, race conditions.


=head3 Section 3

Section 3 looks at techniques out of acedamia. 
Popularized by applications like artificial intelligence, they bring very hard 
problems down to Earth. 

L<AnyAndAll> introduces two other kinds of data collection something like arrays:
conjunctive sets and disjunctive sets.
These let us easy ask questions of the data such as "do any match?" and "do all match?".
Sets may contain other sets, not necessarily of the same type, allowing data to
be structured in immediately useful ways.

L<LexicalClosures> talks about subroutines that can be configured and customized by the
subroutine that returns or creates them.

L<FunctionalContinuations> explains functional continuations. 
Continuations ease connecting pieces of code, lessoning the need to hard-code
function or method names into a routine by letting multiple coexistant 
function calls pass data back and forth without knowing who they're talking to.

L<CoRoutines> describe coroutines, which allow multiple
subroutine calls to be made in parallel.
Concurrent network connections represent well as coroutines.