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 165 messages across 20 threads, with 31 authors contributing. Two threads (and two authors) dominated the lists this week. Other than that, traffic was noticeably lighter with YAPC going on.

Even More on Unicode and Regexes

It seems that both general relativity/quantum mechanics and linguistics/text processing are hoping superstrings can solve their respective enigmas:

We probably also ought to answer the question "How accommodating to non-latin writing systems are we going to be?" It's an uncomfortable question, but one that needs asking. Answering by Larry, probably, but definitely asking. Perl's not really language-neutral now (If you think so, go wave locales at Jarkko and see what happens... :) but all our biases are sort of implicit and un (or under) stated. I'd rather they be explicit, though I know that's got problems in and of itself.

                                        Dan

This was followed by a lengthy discussion on different languages, although Perl wasn't really one of them. It was the general conclusion that Perl needn't try to support the world's languages, but should at least leave sufficient hooks for others to do so. More will surely follow.

Multi-Dimensional Arrays and Relational Databases

Me started the other lengthy thread for this week, in a call for a multi-dimensional array syntax that would allow easy modeling of a relational database. Several folks pointed out that

1. Me could always use Perl 6's planned replaceable syntax to define such capabilities.
2. If Perl 5 arrays (even with only a pseudo-multi-dimensional nature to them) aren't fundamentally in sync with database access, then to make them so would require rendering them out sync with everything else they've been used for.
3. Array slicing, even with tying and overloading, isn't nearly as good as working with SQL (as through DBI) for this type of data manipulation.

David L. Nicol did provide an interesting digression on "tasty" variables, which are, more or less, the ultimate in lazy evaluation. Mostly, though, the discussion went completely sideways.

Core Architecture

Dan Sugalski provided a glossy on what the guts of the new interpreter will look like.

Perl 6 Emulator

Simon Cozens released a rough Perl 6 emulator.

Handler Function or VTable?

Dave Mitchell asked if a single handler function would be better than the vtable scheme currently planned. (" No," says Dan.)

Argument Decoding

Dan also asked for opnions on who should decode opcode function arguments - the functions or the dispatch loop? (Argument decoding, in this case, is the translation from a virtual register number to its memory address.) A number of trade-offs were discussed, with function decoding having a slight edge. That, in turn. led to a brief discussion on shadow functions - C functions that mirror Perl functions - and how useful they are or aren't.

Polymorphic Builtins

David Nicol lamented about not having multiple dispatch based on signatures.

YAPC

Although he didn't mention it on the mailing lists, Nathan Torkington did tell use.perl.org where to find an MP3 of Damian Conway's opening spiel on Perl 6. (Damian was speaking in place of an ill Larry Wall.) For the less imaginative, the slides can be found here in PDF format.

• Notes
• Even More on Unicode and Regexes
• Multi-Dimensional Arrays and Relational Databases
• Core Architecture
• Perl 6 Emulator
• Handler Function or VTable?
• Argument Decoding
• Polymorphic Builtins
• YAPC

Perl.com Compilation Copyright © 1998-2006 O'Reilly Media, Inc.