This week on Perl 6 (9/1 - 9/8, 2002)

Well, what a week it's been, eh, people? Larry's been telling the Slashdot crowd about quantum God and big knobs, there's been a call for Perl 6 programmers on Perlmonks (, and the Octarine parrot took flight.

So, let's start with perl6-internals, as is traditional.

The Octarine Parrot flies!

Jeff Goff (who deserves to suffer for his parody of Eight Days a Week) announced Parrot 0.0.8, available from the usual places. This release includes:

Working Perl 6 rules/patterns
Multidimensional keyed access
JIT for ARM processors
Lexical scope operators
Many bugfixes and smaller subsystems

Mere moments after announcing the new baby, Jeff realised he'd made a mistake with the tarball's MANIFEST, and announced the release of Parrot, which has all the same features as 0.0.8, but a MANIFEST error has been excised. MANIFEST seems to be a source of problems, as Tanton Gibbs also had problems with it later in the week. -- Announcement -- Tarball

Goal call for 0.0.9

Soon after the 0.0.8 announcement Dan asked us what we wanted to see in 0.0.9 and offered his list. The list became rather long as Sean O'Rourke, Steve Fink and Nicholas Clark all chipped in suggestions. The 'long' list ended up as:

Initial PMC freeze/thaw API
Sub indicators in bytecode
On-the-fly bytecode section generation
Methods (in PASM and C)
Implementation of some methods for the Perl classes
Resolve the prompt finalization problem
PMC name, implementation cleanup(*)
Filename, line number tracking
Careful elimination of compiler warnings
Rationalization of bytecode generation

(*) The PMC issue was brought up by Steve. He pointed out that right now we have a situation where theoretically language independent PMCs often refer to, and create, Perl specific PMCs on the fly, which seems slightly wrong. -- Steve's list

Approximate string matching in regexes

Sean O'Rourke discoursed on edit distances and approximate matching, and offered a patch implementing an rx_amatch opcode.

More regex stack manipulations

Sean also implemented a couple of opcodes for manipulating the regex engine's stack: rx_stackdepth Ix and rx_stackchop Ix. Dan thought that the semantics of rx_stackchop were slightly off, and that the instructions were actually intstack specific and should therefore be called intstackdepth and <intstackchop> respectively. Dan is also 'really, really close to tossing the last pretense of being a stack-based system and [moving] all the way to routine-based frames instead, which would definitely make some things easier.' (Whatever that means). Sean and Steve Fink both seemed to think that that may be a step too far, at least for something as backtrack heavy as the regex core. Steve thought he would rather not create a few thousand Exception or Continuation objects and also made noises about encapsulating intstack.c's functionality in an appropriately named PMC.

Later in the week, Steve delivered his patch to provide an integer array PMC, but wondered if it shouldn't be called an integer dequeue (a double ended queue). John Porter voted for dequeue. Leopold Toetsch wondered why the patch needed a pair of new ops, and questioned the entire premise of the patch, so Steve mounted a sterling defence of his patch.

core.ops ARGDIR

Leopold Toetsch kicked off a discussion of 'the intended meaning of ARGDIR_IN/OUT'. I'm afraid to say that while I understand the individual words in his message, I don't really understand the post as a whole. Which is my own fault, and makes life rather hard for a summarizer. However, Nicholas Clark and Angel Faus seemed to understand him, and discussion ensued. -- Thread starts here.

Parrot: maximizing the audience

Jerome Quelin put the cat among the pigeons when he made a few observations about the perlcentricity of Parrot, and wondered what the benefits of making Parrot more explicitly vendor neutral. Jerome wondered 'what could we do in order to open parrot to non-Perl centric people?'

Markus Lair suggested renaming perl6-internals to 'something better like "parrot internals". Sean O'Rourke wondered what effect this would have, apart from breaking his procmail setup. Dan thinks we'll probably shift to a more neutral list name eventually. John Porter claimed that 'some folks seem to think that sufficient reason [to change] exists now.', and Dan pointed out that John didn't have to convince 'some folks', he had to convince Dan. John then attempted to invoke Larry.

John Porter reckoned that changing the list name would have "a huge psychological effect, at least outside our tight little club. But if that's only as far as you can see..."; Dan responded with admirable restraint.

Steve Fink is surprised at how little Parrot is tied to Perl 6, and noted that Perl 6 'mostly provides evidence that this isn't just an exercise in intellectual masturbation', and came down in favour of renaming the mailing list.

Ask Bjoern Hansen popped his head up to say that it would soon be relatively easy to change the list name to, say, ''.

Andrew Kuchling, one of the python-dev crew, popped in to talk about, and why it's not being heavily developed. (From his point of view, the mailing list name is an irrelevancy BTW). Andrew made some good points about the fun and benefits of Parrot from the point of view of a Pythoneer (it isn't much fun, mostly because of the culture shock and that there don't appear to be any real benefits apart from the possibly chimerical cross-language stuff), and worried about the amount of optimization that was going on before we'd got any real languages implemented. Andrew also suggested making Scheme one of the driving languages for Parrot, based on its simple syntax and fully specified semantics.

As a result of all this, Dan posted his list of 'Parrot long-term goals/prospects', a 9 point list, with footnotes about where he sees things going. I'm not going to summarize it because it's already its own summary. Read it. There was some discussion about what the eventual 'pure parrot' build environment will look like, including some optimistic copyright lines... -- A Pythoneer speaks -- Dan's list

Implementation of Lists for languages/scheme

Jügen Bömmels offered a patch implementing Scheme pairs, using simple Arrays. Dan was impressed, and wondered how far we were from 'real' scheme. Jürgen thinks we're quite some way away; we still need symbols, strings, lexicals, functions, macros, continuations... Piers Cawley outlined an OO way forward using (initially) hashes, and proposed a 'SchemeObject' PMC, which would hide a lot of the common structural code needed for dispatching methods implemented in any of C/Parrot/Scheme.

Teasing notes

Dan announced that he was about to go dark for a while as a deadline of his had just got a lot closer. However, he dropped a list of hints about what was forthcoming. Bryan asked for some clarification of a few hints (but they're hints, they're supposed to be a bit vague), and Dan went and spoiled the mystery by giving him some.

Tinderbox turning green

Andy Dougherty noted that the recent work on portability and general lint gathering meant that we were well on the way to a green tinderbox (ie: automated builds are mostly working, yay!). Dan thought that gave him an ideal opportunity to break things again by adding exceptions to the mix. Andy then went a bit red, for assorted and faintly embarrassing reasons: the patch that was meant to turn things green had been applied and then inadvertently backed out. There's a moral here somewhere.

Actually there was a spate of inadvertent unpatching last week. People are embarrassed and hopefully putting procedures in place to avoid another spate.

Perl 6 miscellany

Steve Fink offered a portmanteau patch for the Perl 6 compiler, including such delights as a '-e' flag to perl6 so the one line script folks could play. (First person to do the RSA one-liner in Perl 6 gets much kudos from me). Sean wondered about a few of the other fixes, and between them he and Steve found and squashed a bug with here docs, and discussed ways of getting working Perl 6 patterns up and running.

Meanwhile, in perl6-language

Garrett Goebel reopened the 'auto deserialization' thread from last week (which ended up with the concept of my Date $date .= new('June 25, 2002') as the Damian approved idea). Garrett's confusion seemed to hang on whether my Date $date and my Date $date = Date->new() were equivalent. If they were, then a class which implemented its own operator:= method could arrange things so that the originally proposed my Date $date = 'June 25, 2002' would work.

Miko O'Sullivan proposed that, in the absence of a method name, .= should automagically call a new_from_[class of object being passed], noting that golfers would love it. The consensus seems to be against this particular bit of DWIMmery.

A subthread of this mammoth thread concerned multimethod dispatch. David Wheeler wanted to know what it was, so Dan explained, and Damian pointed at a Perl Journal article on the subject. This subthread ended up spawning its own thread, where Miko wondered if multi dispatch/overloading implied anything about runtime/compiletime. Dan thought not, and said it was dependent on the language.

Quote of the thread: "I can still remember the precise moment I first fell in love with polymorphism." -- Damian, in the TPJ article referred to. -- multimethods? -- TPJ article

Class aliasing

The 'auto deserialization' thread also spawned a discussion of Class aliasing, but declined to change its subject line, making the life of a summarizer so much easier...

Last week, Damian had proposed doing class Date is Really::Long::Package::Name::Ugh, ie. subclassing the long name into a handy short name. Everyone else seemed to think he was proposing aliasing a class name (which Damian later denied).

Uri Guttman certainly thought that Damian was talking about lexical aliasing of classes (my mailer picks his post as this week's base for this particular subthread). Trey Harris thought that Damian was talking about subclassing, and proposed my class Date is Really::Long::Package::Name::Ugh, which introduces a lexically scoped subclass. Nicholas Clark wondered if class Date := Really::Long::Package::Name::Ugh would express aliasing of classes. Damian thought it probably would, but noted that Larry hasn't said a definite 'yes' to class name aliasing.

Brent Dax wondered if classes weren't in danger of becoming the "new filehandles" -- relatively limited entities with no sigils that confuse the syntax horribly.' and pointed out an ambiguous case.

David Wheeler apologised to everyone for confusing inheritance and aliasing in the first place, and the thread wound down to a close.

@array = %hash

Another thread from last week that rumbled on into this one.

The discussion of when hashes could have pairs as keys wouldn't go away. Damian says that the %hash = (...) case is syntactic sugar and that having a pair in an even slot of such a list would probably be an error. I assume that this also applies in the case of %hash = @array.

In a subthread, Piers Cawley told David Whipp that he hadn't actually been joking when he proposed implementing the entire Smalltalk Collection hierarchy and making it available in core Perl 6. Luke Palmer liked the idea too. Dan saw no reason why such a thing should be impossible either...

Atomicness and \n

Last week Damian reminded us of $roundor7 = rx/<<roundascii>+[17]>/, and Brent Dax wondered how one could be sure that <roundascii> is a character class. Luke wondered if it mattered. The thread eventually led Aaron Sherman to make a few proposals about user defined character classes in regular expressions. Deborah Ariel Pickett wondered why we still used ? for non-greedy quantifiers, citing teachability reasons for why we shouldn't.

Hypothetical variables and scope

Aaron Sherman announced that he was working on a library of rules and subroutines for dealing with UNIX system files, mostly as mental exercise to help with his understanding of Perl's new pattern features. He wondered, in particular, about the scoping of hypothetical variables in the presence of lexicals of the same name. For some reason this turned into a minor argument about whether my $x; / (\S*) { let $x = .pos } \s* foo /, from Apocalypse 5, was a typo for my $x; / (\S*) { let $x := .pos } /. I'm not going to try to summarize the argument.

Argument aliasing for subs

Pete Behroozi wondered about syntax for 'allowing subroutines to have many different names for the same argument', citing as an example of such code in Perl 6. Damian thought that if it were allowed, it would be done with properties sub hidden (..., int $force is aka($override) ) {...}, (well, he did after he realised that his first post on this issue was the result of posting after travelling 14,000 miles and giving 93 hours of talks in the space of 18 days, and was somewhat flawed).

All this cunning use of is led Erik Steven Harrison (who should fix his mailer so it does References or In-Reply-To properly) to wonder if properties weren't being a little overused, and wondered if the is/but distinction was still around. Damian thought not, and reiterated the difference between is and but, and when you would use each of them. Erik also wondered what was wrong with sub hidden ( int $force := $override ) {...}. Damian pointed out that it didn't play well with the defaulting operator, //=, in parameter declarations.

Peter Behroozi got confused about the difference between $foo is named('baz') and $foo is aka($baz). (named changes the externally visible name of a parameter, aka adds another external name for the parameter).

The thread then morphed into a discussion of runtime and compiletime properties. If you've not seen such a discussion before, the whole thread is worth reading.

Perl 6 parser, built in rules, etc.

Erik Steven Harrison wondered about backward compatibility issues with changing Perl 6's grammar when the grammar rules are so exposed to the user. Sean O'Rourke didn't think it was an issue yet. Dan told us that the eventual Perl 6 grammar would be maintained in a backward compatible way, with documented places for adding changes, and that this would be maintained for as long as Larry said so.

regex args and interpolation

David Whipp confused the heck out of me when he asked about 'regex args and interpolation'. I confess I can't for the life of me see what the issue is that he's trying to get at. Ken Fox seemed to understand him though, but wanted to know what the rule was that he was using in his example code, and proposed a couple of implementations of it. Nicholas Clark wondered about a section of Ken's post:

    { use grammar Perl::AbstractSyntax;
      $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }

Specifically, what was that S-expression doing there? Piers Cawley pointed out that S-expressions were a concise way of writing out an AST's structure. Nick agreed, but pointed out that it was still in the middle of a stream of Perl, but worked out that the use grammar Perl::AbstractSyntax part of Ken's code meant that all bets were off. At this point Nick's head threatened to explode at the wonderfulness of it all.

Defaulting params (reprise)

Miko O'Sullivan doesn't like sub foo ( $arg //= 1 ) {...} for specifying default values for function arguments. He would rather have sub foo ( $arg is default(1) ) {...}. Damian pointed out that is default(...) would be a compiletime only thing, which didn't necessarily make sense.

Hypotheticals again

Jonathan Scott Duff wondered some more about hypotheticals and let. He wanted to know whether hypothetically binding to a lexically scoped variable would also introduce that name into the match object. A strict reading of Apocalypse 5 suggests that that isn't the case, which, Jonathan points out, causes the programmer a few headaches. Damian agreed that he'd like to see $0 contain keys for all the hypotheticals used in a match, whether they came from the lexical scope or not. Damian would also like them to turn up in $o{'$name_with_dollar' as well. So, it seems that everyone's assumptions are aligned and we can carry on.

First crack at Builtins.p6m

Aaron Sherman decided that what the world needs now is, at least, a set of function signatures for everything that's in perl5's perlfunc listing. He's even had a crack at implementing those functions where possible. Aaron points out that he thinks of this file as documentation, not code. People were impressed, and there's talk of using it to compile down to the IMCC input as a base for hand optimizing. Aaron also released a second version with more functions implemented and a slightly different organization.

More A5/E5 questions

Jonathan Scott Duff asked a bunch of questions about the pattern engine, and got a bunch of answers.

In brief

Leon Brocard wondered if the concatenation bug was fixed yet...

Leon also offered a patch implementing chr, reckoning that if we have ord, then symmetry demands chr. Dan applied it, and Jerome Quelin found a bug in his Befunge-93 interpreter which he thought was a bug in the chr implmentation, but turned out not to be.

The Perl 6 compiler now does interpolated strings. Kudos to Joseph Ryan.

Josef Höök had a problem with key_next not behaving as expected within multiarray.pmc. Tom Hughes pointed where expectation and reality differed, and harmony was restored.

Kevin Falcone patched the glossary to include a definition of ICU.

Mike Lambert is having problems with the Perl 6 compiler under Windows. Sean O'Rourke can't duplicate the problem. Anyone else tried this? More information is welcome.

Ken Fox and Damian continued their discussion of how one would munge the current Perl 6 grammar.

John Williams wondered about doing reduce with ^+=. Damian can't remember what side he argued when it came up last October, but is now of the opinion that John's suggestion is a good idea.

Mr Nobody suggested some changes to the Apocalypse 5 pattern syntax for reasons of length. Consensus seems to be that these changes aren't a good idea.

Who's who in Perl 6

Who are you?
I'm Dan and ... I design virtual machines.
What do you do for/with Perl 6?
I'm designing the virtual machine to compile and run it.
Where are you coming from?
A place about 70 miles east of here.

I started fiddling with computers with an Atari 800 (fully decked out with a massive *48*K of RAM!) a long, long time ago. That lead me to Atari BASIC, then to 6502 assembly, then to Forth. Then (briefly) to college and Pascal and PL/I running under VM/CMS on an OS/370 system.

From there I bounced to COBOL (on both RSTS/E and OS/370) and OS/370 assembly, and then to C under RSTS/E. I disliked C on first sight (so of course that's what I spend most of my life writing now), and it didn't get any better on my Amiga, though AREXX there was rather nice. Wrote an article on AREXX for one of the now-dead Amiga magazines, too.

My first real job in the industry was maintaining a horrid app written in BASIC on RSTS/E (with the new bits written in BASIC/PLUS 2.6, which was a nice dialect of BASIC, and something I still like better than C) and helping write a new system in Progress on Unix boxen. (DG AViiON systems with the 88K series processor. Now there was a sweet, and alas, now dead, RISC processor)

That lead to writing C and SQL code on a VMS system, at which point my fate was sealed, and I've been doing VMS admin and programming ever since.

I first encountered Perl when looking for a guestbook for a webserver we were running on one of the VMS boxes. It was, of course, written in Perl, which meant grabbing a copy of perl. It was one of the 5.003_9x releases, and since Dec C was significantly pickier than any other C compiler at the time, I started shooting patches for it to Chip.

That lead to my first XS module, and then to the second, and third (and eighth, and tenth, and...). Oddly enough, I wrote my first piece of Perl code about six months after my first patch to the perl core (Charles Bailey wrote the Perl pieces for the first module I did, and chunks of the XS) I ended up with the VMS maintenance hat for a while, which has since been passed on, and I got snared by the fun that was the first threading attempt for 5.005.

I ended up volunteering to coordinate the Perl 6 development at TPC 4, since everyone more competent had the good sense to run screaming away from the job, and I've had it ever since.

When do you think Perl 6 will be released?
When it's done.
Why are you doing this?
Beats the heck out of me. Someone's got to.
You have 5 words. Describe yourself.
Tall enough, under the circumstances.
Do you have anything to declare?
Yes, absolutely.


This summary is dedicated to the memory of Gizmo, a cat of great character, who we had to have put down on Saturday at the age of 17.

Chris Ball, Mark Fowler and Pete Sergeant helped with proofreading this week. Thanks chaps.

Once again, if you like the summary, please consider giving money to the Perl Foundation at -- your money will go to help fund the ongoing development of Perl 6.

This week's summary was, once again sponsored by the O'Reilly Network who are paying the publication fee for the article directly to the Perl Foundation.

Visit the home of the Perl programming language:

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en