The Perl 6 mailing lists saw 226 messages across 19 threads, with 40
authors contributing. Although the traffic was moderate, and very little
heat was generated, most of the light was of the mysterious,
all-encompassing kind.

Dan Sugalski
dropped a link provided by
Slashdot's recent article on
why Unicode won't work. Russ Allbery and Simon Cozens both started with
an anti-FUD discussion, pointing out some of the questionable veracity
and the datedness of the paper's conclusions, and providing basic Unicode
information.

There was a brief discussion
starting here on the lossiness of Unicode, and whether the tables were going to be
embedded/included in Perl 6. (Dan's plan is to build external libraries
(for the latter) so that improved or alternate encoding sets can be replaced
independently (to handle the former).)

Hong Zhang then
kicked off a thread that brought locales into the discussion, particularly with case
determination and sorting.

The discussions were mostly academic - not much was actually decided on.
Larry did drop a couple hints as to
how much (or
how little ) Perl 6 may differ from Perl 5.6 with Unicode handling.

A lengthy discussion on the interaction of properties with
use strict was
started by Me. (In truth, the actual discussion
on properties and stricture was very short - because properties can be both
static variable properties or dynamic value properties, Perl
can't determine at compile-time whether a property being accessed actually exists.

A parallel discussion involving a
'super-strict' mode to, in essence, allow programmers to completely turn off
any runtime constructs and beef up compile-time checking devolved into a
Perl-Java debate. Albeit more civilized than usual.)

In a continuation of last week's
discussion on registers and opcodes, Larry
listed his reasons for wanting the regex engine
integrated into the regular opcode space:

But there is precedent for turning second-class code into first-class
code. After all, that's just what we did for ordinary quotes in the
transition from Perl 4 to Perl 5. Perl 4 had a string interpolation
engine, and it was a royal pain to deal with.

The fact that Perl 5's regex engine is a royal pain to deal with should
be a warning to us.

Much of the pain of dealing with the regex engine in Perl 5 has to do
with allocation of opcodes and temporary values in a non-standard
fashion, and dealing with the resultant non-reentrancy on an ad hoc
basis. We've already tried that experiment, and it sucks. I don't
want to see the regex engine get swept back under the complexity carpet
for Perl 6. It will come back to haunt us if we do:

Although everyone was in agreement that halfway was, on a scale from Good to
Bad, Bad, there was some dissention on whether integration or separation was
needed to solve the maintenance issues.

What should $foo = (1,2,3) do now? Should it be the same as what
$foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
$foo = \@INC; does now.) Putting it another way: does a list in scalar
context turn into a reference, or is it just arrays that do that? If
so, how can we disambiguate hashes from lists?

The Perl Virtual Machine is, of course, far removed from any layers
that are normally considered to be "very-low-level," and the Virtual Machine
opcodes tend to be somewhat complex in what and how much they accomplish.
"Very-low-level" wasn't intended as a description of the complexity on an
absolute scale, but as a description of the atomicy of operations relative
to the Virtual Machine itself. (Thanks go to John Porter for bringing it to
my attention.)