You can subscribe to an email version of this summary by sending an empty message to firstname.lastname@example.org.
Please send corrections and additions to email@example.com.
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.
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.)
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.
Simon Cozens asked a couple of questions about the new syntax:
Should properties interpolate in regular expressions? (and/or strings) I don't suppose they should, because we don't expect subroutines to. (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)
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?
- Simon Cozens has dropped several hints about having Ruby spit out Perl bytecode. At least mostly. No official announcement yet, though.
- Adam Turoff announced a "Perl Apprenticeship Hour" for YAPC.
Two weeks ago, when discussing A.C. Yardley's Assembly Language proposal, I mentioned the "very-low-level operations" of the Perl Virtual Machine itself.
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.)
Bryan C. Warnock