Perl 6 Alive and Well! Introducing the perl6-mailing-lists Digest

Feb 14, 2001 by Simon Cozens and Schuyler Erle

“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 only do. :-)

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,

Simon Cozens