"What *is* going on over there, anyway? It is unfortunately true that the effort looks stalled from the outside."
- Eric S. Raymond, to the perl6-meta mailing list
The push towards the next major version of perl started with a bang -- literally, thanks to Jon Orwant and his now-infamous coffee-mug-tossing act. Mailing lists were set up, a flurry of RFCs were submitted, and now, almost five months since the RFC process ended... Quiet. What *is* going on with perl6, anyway?
As it stands now, the silence is mostly due to the fact a lot of the work has
gone underground. First, of course, we continue to wait eagerly for Larry's
language design, although as Larry himself points out, he's got his
hands full with the 361 RFCs submitted last fall. Elsewhere, work continues at a
steady murmur, especially on the perl6-language and
perl6-internals lists. In particular, the
perl6-internals group, led by the redoubtable Dan Sugalski, has
borne some recent fruits, as discussions have started to coalesce into "Perl
Design Documents," or PDDs.
PDDs are detailed white papers that will hopefully serve as guides when
people actually sit down to write code. So far, PDDs have been submitted to
perl6-internals relating to the structures of the interpreter
itself, and of vtables, which will be used to implement primitive
variables, like scalars. More PDDs are expected on other language-independent
features, like garbage collection and I/O abstraction, which will need to be
implemented somehow, regardless of what Larry's final language design looks
like. Some preliminary code for the perl6 interpreter might even be written in
the next month or so, once the existing PDDs are finalized.
So, contrary to all outward appearances, perl6 is indeed alive and well! In order to remedy this information deficit, Simon Cozens has stepped forward, and volunteered a companion to his perl5-porters digest. As such, the O'Reilly Network is pleased to introduce the first edition of the perl6 mailing lists digest. Simon plans to set up e-mail distribution (analogous to the p5p digest), so we'll be sure to let you know when that happens. Meanwhile, the perl6 digest will become a regular weekly feature of www.perl.com, hot off the mailing lists to you. Enjoy!
This week on perl6 (04--11 Feb 2001)
Please send corrections and additions to
perl6-thisweek-YYYYMM@simon-cozens.org where
YYYYMM is the current year and month.
This week was reasonably quiet, seeing around 350 messages in all the
groups. For a change, most of the traffic was on
perl6-language
Autoloading Modules
Last week, Dan asked people to think about ways to autoload modules when a function was used; the idea being that you'd be able to say, for instance:
socket(SOCK, PF_INET, SOCK_STREAM, $proto);
(or moral equivalent) and Perl would load in all the socket functions.
This is actually what Perl 5 already does for
glob and some of the Unicode functionality. Some people went off on a bit of
a tangent and started discussing ways to autoload modules more
generally, by having modules declare what functionality they're providing.
One big question for both sub-discussions was how we key the functions to code. Jarkko said:
A gut feeling that I have is we can't simply go by interface 'names', be they just simple names of funtions/methods or their full 'signatures' (let us not even start on (1) how difficult with Perl's type system and functions it is to define signatures (2) the difficulty in defining an ontology/vocabulary), either would not really be enough.
What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual.
Branden suggested that a URI should be used, leading to the inevitable but still horribly scary notion of
use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
{ Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION
=> 2 };
Various people pointed out that this might not be secure.
Packaging
The autoloaded core functions idea got slightly left by the wayside, as the discussion finally veered off onto how to package up modules and programs to satisfy dependencies and make things easy for the user. A setup similar to Java's "jar"s was suggested. Dan came up with the very simple and neat idea of simply shipping a bytecode compiled version of a program instead. Schwern was a bit concerned that this would lose source code and would separate out documentation; Dan's brilliant answer was:
Not unless you strip the bytecode. I want to optionally package the source in the bytecode, since otherwise you can't do some optimizations after the fact on the generated bytecode stream.
He also suggested a text segment in bytecode so that, for instance, you can still get POD embedded in code.
That's something that may well happen anyway, but Branden came back on the packaging issue. He noted that Dan's suggestion wouldn't help for modules with C extensions, and also said:
Actually, I think the archive approach is more general, because it wouldn't have this kind of problems and would allow other resources to be deployed together with the code, like documentation, perhaps even text files and images used by a Perl/Tk application
Comparisons were made between this and the currently-existing PPM. Branden produced a draft PDD for his ideas.
Vtables
At long last, Dan produced the second PDD, specifying the vtable API. As expected, this exposed a lot of hidden confusion about what vtables are for and how they're going to be handled. Tim piped up with a few questions and corrections, including a discussion about how string handling is going to work, especially string encoding. Dan said he deliberately left UTF8 off, because dealing with variable-length data is horrid. Most people disagreed, saying that UTF32 was too big for most people, and UTF8 was a good compromise for most data. It was generally agreed that an abstracted string handling layer would make most of the problem go away.
Edwin Steiner asked whether the vtable API should be made up of macros; I pointed out that this was the road that Perl 5 went down, and look what happened to that. Dan also said that there wouldn't be an "API" for vtables - they're to be used by the Perl guts only.
There was still a lot of confusion as to how overloading and aliasing
would be accomplished. Branden came up with an alternative suggestion
for how to handle vtables, which seemed to be rather more high-level.
The current vtable PDD wants to make many core ops a single vtable call
if possible. There seemed to be much confusion about how the key field worked, and what operation was being carried out on what. No
doubt further revisions of the PDD will clear this up. Dan also said
that once the PDD has matured a little more, he wants to start writing
code for the base classes. We're nearly there, guys
Subroutine return values
There was a lot of light but very little heat in the continuing saga of assigning to a magic return value variable. Some people seem to want to do this:
sub foo {
foo = 10;
}
instead of
return 10, just like Pascal, Algol and all those other failed, now-dead
languages.
A (slightly) better suggestion was a magic variable to hold the return
value, similar to what
Parse::RecDescent (and of course,
yacc) does. The names
$__ and
$^R were suggested, but there was no consensus on whether or not it would
even be a good idea.
End of Scope Actions
A far better idea came out when people stopped looking at what they wanted and started looking at why they wanted it. A lot of the value in having a assignable return value is in the situation of subroutines which set something up, compute, and then turn it down again. Another way of looking at that was to stipulate a block executed at the end of the scope, like this:
sub lines {
open IN, $_ or die $!;
return scalar(<in>);
}
post lines { # This is executed on return
close IN;
}
Damian had, of course, thought ahead, and this is covered by his
RFC 271. However, he agreed that post-block actions should be allowed
everywhere, not just on subroutines. The
always keyword was agreed upon as a good way of doing this, although
POST was also suggested. This lead to the
semi-inevitable rehash of the
try-
catch exception handling debate. According to John Porter,
There is no
try, there is onlydo. :-)
Garbage Collection
Jamie Zawinski published his
rant about Java, which caused certain sensible people to ponder how to make sure Perl
avoids the same mistakes. A few of the things mentioned included
platform independence, the size of SVs, locking, but the discussion
settled down to garbage collection, as rather a lot of discussions on
perl6-internals are wont to do. (Oh, this was on
perl6-language. Ho hum.)
The trigger was a question from Branden:
I actually don't understand how traversing a graph can be faster than incrementing/decrementing/testing for zero on a refcount. I believe you, but I just don't understand. Could you point me to some URLs that talk about this?
and a masterful answer from Piers:
There's a jolly good book on this called (would you believe) 'Garbage Collection'. The crux of the matter would appear to be that with refcounts you have to do a pretty small amount of work very, very often. With a well designed GC system you do a largish amount of work much less frequently. The total amount of work done tends to come out higher in the refcounting scenario.
This was coupled with a more comprehensive answer from Ken Fox. Dan said he wanted to put GC-related data at the end of a variable, so that it didn't always get loaded into memory. He also pointed out that
The less memory you chew through the faster your code will probably be (or at least you'll have less overhead). Reuse is generally faster and less resource-intensive than recycling. What's true for tin cans is true for memory.
and hinted that Perl 6 is likely to be using a generational semi-space garbage collection scheme.
kdb
Joshua Pritikin mentioned kdb, but had to be tortured before he would explain why. It eventually became clear he was talking about the K language and its interesting data model; he says:
Whether K is ultimately a failure or not, i find it to be an interesting mix of design trade-offs. Of course i'd have to use it in a real project to offer a detailed report of its weaknesses.
ESR on Perl 6
Eric Raymond released two more chapters of his on-line book The Art of Unix Programming, something Perl 6 people would do well to read. Unfortunately, he wasn't particularly complimentary about Perl, claiming that both Perl 5 and Perl 6 are currently stagnant and stalled. This led to a rather acrimonious discussion about our public image, and it was resolved that these summaries might help us let the public know what's going on. So here we are.
And there we were. Until next week I remain, your humble and obedient servant,
