This Week in Perl 6 (3 - 9 June 2001)

Notes

You can subscribe to an email version of this summary by sending an empty message to perl6-digest-subscribe@netthink.co.uk.

Please send corrections and additions to bwarnock@capita.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.

Unicode

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 Strict View Of Properties

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.)

Regular Expressions

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.

Lists, References, and Interpolation

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?

(The provided answers were " yes" (Damian Conway) and " undecided" (Larry Wall), respectively.

Miscellany

Follow-Ups

It's Alive

Because of (or to spite) last week's coverage of it, David Nicol produced a patch for 5.7.1 that does such a thing.

Perl Assembly Language: Clarification

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
Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en