This Week on Perl 6 (26 August - 1 September 2001)

Notes

This Week in Perl 6 News

Notes

Expunge Implicit @_ Passing

Finalization and Deterministic Destruction

Multiple Dispatch on Objects

Program Metadata

!< versus >=

Parroty Bits

Last Words

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 lists saw a little more traffic during this week: 137 messages across 19 threads, with 40 authors contributing.

Expunge Implicit @_ Passing

(22 posts) This topic from two weeks ago came up again, as Ken Fox mentioned its use in redirectors. Michael Schwern suggested using goto &code instead, and provided this final justification:

Why not just $method->(@_); or &{$method}(@_); or goto $method?

Any time you want to implicitly pass @_, you can just as easily *explicitly* pass it or use goto. As we’re not doing pass-throughs all over the place, it’s not the sort of thing you want implicit, as opposed to, say $_.

(This thread then devolved into a general debate on the usefulness of Java final classes.)

Finalization and Deterministic Destruction

(11 posts) Hong Zhang, however, did branch off and talk about the differentiation between finalization and destruction. There were then quite a few posts lamenting the demise of deterministic destruction with the move away from ref counting towards a more complex garbage collection scheme.

Dan Sugalski pointed out:

GC has nothing to do with finalization. Many people want it to, and seem to conflate the two, but they’re separate. Dead object detection and cleanup doesn’t have to be tied to memory GC. It won’t be in perl 6. The perl 6 engine will guarantee whatever cleanup/finalization order and timliness that Larry puts into the language definition. That’s not a problem.

Multiple Dispatch on Objects

(11 posts) The first of two threads on multiple dispatch started here, with two examples here and here.

There was talk about whether it was an OO technique, how it should work with the dynamicness of Perl, and what the best, most efficient manner of implementing multimethod dispatch is. In the end, Perl will support some form of pluggable multimethod dispatcher, although that was about all that was agreed upon.

(10 posts) The second thread decoupled multiple dispatch from objects, creating what it essentially subroutine overloading (by signature).

Program Metadata

(15 posts) I mentioned a few pieces of metadata that I would like access to from within a Perl 6 program. The bulk of the thread was about how to access the source of a script from within a script in Perl 5.

!< versus >=

(7 posts) Raptor suggested adding !> and !< to the logical operators as Another Way To Do It. Reactions were mixed, but no technical reason was given why it couldn’t be. (It should be noted that in tri-state logic, where he saw this, !< is not the same as >=.)

Parroty Bits

Simon Cozens and Dan Sugalski are finishing up the seed code for the Parrot interpreter base.

Dan:

The broad design of the Parrot internals is sufficiently complete to start implementing parts, and we are. We’ve the first cut core of an interpreter and, while I figure we’ll probably rewrite the thing at least once before final release, it runs. You can now write code in Parrot assembler, assemble it, and run the results.

Most of the defined opcodes don’t have corresponding code for them, so it’s limited at the moment to integer and float operations with some control flow (branch, jump, and if) but more will be on the way soon.

Simon:

I’ve been sitting down and writing bits of Perl 6 (I’m working primarily on the string functions at the moment, because I can do that without getting in Dan’s hair too much) and also collecting our thoughts on the interpreter into documents that will specify the API and as much of the Grand Design as people need to know to be able to start helping.

The next phase of Parrot will be a code review - for the Perl internals community to poke and prod and make sense of what Dan and Simon have done. The community will provide feedback, and Dan and Simon will disappear for a brief period, before the code is opened up for development.

After going public, work will mostly progress according to Dan’s To Do list.

Last Words

The last I heard, the next pair of stone tablets from Larry Wall and Damian Conway are coming down the mountain. That’s my story, and I’m sticking to it.


Bryan C. Warnock

Tags

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub