This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit

This week on Perl 6 ~(24-30 June 2002)

By Piers Cawley, 020020702


Experimenting with a slightly different format this week (theft from NTKnow considered sensible...), I'll also be looking at some of the things that've been posted on (and I'd really appreciate some reports on the YAPC Perl6 chats from those who were there, so I can summarize them for the next issue or as an appendix to this one).

System calls/spawning new processes

A newbie seemed somewhat confused about the purpose of the perl6-language list and asked about spawning subprocesses... in Perl 5. Mark J Read demonstrated admirable tact and diplomacy in both pointing the newcomer at a better place to ask ([email protected], a great mailing list) and providing some pointers toward an answer.

The only reason this particular episode made the summary, by the way, is because of its rareity. I've been generally impressed by the general 'on topicness' of the perl6-* lists. I hope it stays that way for a long time to come.

Mailing list urls omitted to protect the innocent.

Ruby iterators

Ruby interators were the subject of Erik Steven Harrison's post, which also referred to 'pass by name' and 'the Jensen Machine', and wanted to know 'the Perl 6 stance on the matter'. Nobody has yet stepped up to the plate on this one and, speaking personally, I'm not entirely sure I've understood the question. has the whole question

Fun with the Perl 6 Grammar.

Sean O'Rourke asked us to "disregard my past shoddy attempt at a Perl 6 grammar" and presented "a larger one that appears to capture much more of the syntax found in Apocalypses and Exegeses 1 - 4 (5 just scares me)." He promises bugs and missing elements, but still earns hero points from me.

Later in the week, Dan asked how the perl 6 grammar was going and Ashley Winters responded that he isn't working on a grammar, but posted a list of variable forms (and a couple of other awkward constructs) with which he'd be testing each grammar. I particularly liked the last three entries in his list:

   # As a final sanity check, let's chain these things


   # And, just to make sure your parser doesn't pass this suite

   $foo{"Do you want to try $interpolated{"string"}?"};

Sean O'Rourke responded with some comments on the legality of some of the examples, and offered his own *@$*foo, a flattened, dereferenced, global $foo, he thinks (and I concur). (Ooh... I just had a bad thought. @foo^.(), AFAICT it's the same as map $_.(), @foo, but a good deal more evil).

There was also some talk of overriding [] on hashes and {} on arrays to do surprising things. Personally, I reckon if you're going to do perverse stuff like that then you should add some rules to the grammar to make it legal, as well as writing the tie magic (or its perl 6 equivalent), but laziness meant I didn't post that to the list.

Oh yes. John Porter suggested that 'maybe Damian should write [the grammar]?'. Which leads me to postulate an analog to Godwin's Law, tailored to the perl 6 process, stating that at some point in any thread about the perl 6 language, someone will suggest that Damian do it. Or maybe Damian will do it. After all, Reports from YAPC seem to imply that he's come up with a cunning way of doing things in zero time (but I'm assuming he uses lots of space to compensate).

This thread kicks off at

Sean O'Rourke's parser is at

The increasingly misnamed 'Perl5 humor' thread.

Particulary, the branch that should be titled 'Porting XS modules to Parrot' rumbled on, mostly discussing how one would do it without implementing the entire perl 5 virtual machine on top of Parrot, with a small digression about achieving flight if you waved your hands fast enough.

Dan, as usual, applied the scalpel very neatly. "Parrot's not going to have XS as an interface--that'd be insane", proposing instead an 80/20 type solution and suggested that "If someone wants to start a list of sensible entries in perl 5's API that should be provided, we can work from there". Tim Bunce suggested starting "with a perl script that reads extension source code ... and spits out details of what perlapi/guts have been used", feeding it a bunch of popular extensions, and then profiling the results.

The implementation of such a tool was left as an exercise for the interested reader.

Dave Goehrig appears to have been that interested reader as he kicked off the 'Possibility of XS support' thread. He took at look at some sample XS based modules and reckoned that getting a minimal core of XS up would need about 50 functions to be ported. Dan thought that would be cool (no surprise there then, it would be cool) and Dave (the star) set off implementing an extension API for parrot. Dave also pointed at the Python and Ruby extension mechanisms as examples of good solutions to the general problem. Dan told us that he's "trying to kate the line between exposing the semantics of the internals and the actual internals." and commented that the semantics of what XS does are fine, but that the syntax is horrible. He also made it clear that any XS compatibility layer would live outside the Parrot core.

See: for the application of the scalpel. has the start of the 'Possibility of XS support' thread. It's all worth reading.

Stack performance

Tom Hughes posted a patch to the stack code. His test figures are impressive: No overflow Overflow Integer stack, before patch 0.065505s 16.589480s Integer stack, after patch 0.062732s 0.068460s Generic stack, before patch 0.161202s 5.475367s Generic stack, after patch 0.166938s 0.168390s

The test programs "push and pop 65536 times with the first column being when that loop doesn't cross a chunk boundary and the second being when it does cross a chunk boundary".

Dan was impressed, and subject to a couple of caveats, it looks like the patch will be accepted. has the patch.

Small stuff Dan added a find_type op to make working with non core PMC types much easier (no more modifying the assembler code every time...) And a lookback op for inspecting the user stack (in type safe fashion). Dan also took advantage of the new, mutable strings to write a string_append op, and doctored copre.ops to use it for "concat Sx, Sy" where x is both source and destination. The phrase "Order of magnitude or two" was used, so that's probably good then. Brian Wheeler gave us the "typeof op which returns the integer type or string type of a PMC." (Thanks. Applied. -- Dan) Simon offers "more extensive tests for the mul_p_p op." Eric Kidder provided a "list of all the opcodes [...] that are not documented in docs/pdds/pdd06_pasm.pod", and a list of all the opcodes that are documented but not implemented.

Peter Cooper pointed to his review of "Virtual Machine Implementation in C/C++", available at Leon Brocard offers a patch to escape strings when tracing.

Leon also offers the latest version of his bravura mandelbrot set generator written in Parrot.

Meanwhile, away from the mailing lists...

Dan said in his journal that "Damian's [YAS/Perl Foundation] grant is up now, and not coming back. Mine ends the end of July, and barring a miracle (which means we gather more than $60K before the end of July), is also not being extended. A chunk of what's left is going to hire a professional grant writer, with everything after, up to $40K, going to fund Larry."

I'd like to extend my heartfelt thanks and best wishes to Damian for the work he's done for Perl 6. Whilst the more visible parts of the work he's done have been jeux d'espritsb like Lingua::Romana::Perligata, Acme::Bleach and the scary talks like Time::Space::Continuum or whatever it's called, it's also apparent that the work that's gone on behind the scenes to help Larry make perl 6 be the best it can be has been unceasing, and his Exegeses have often been masterful examples of how to explain tricky concepts with clarity.

Dan's work for Perl 6 has been more visible more often. Parrot is looking good, in large part because of Dan's efforts as programmer and project manager. Personally, I hope the miracle happens; having Dan full time can only be a good thing.


I'm not getting paid for this, and I don't particularly want to get paid for it. But if you find the summaries useful, please, please give some money to the Perl Foundation to support the ongoing design and development of Perl 6 and Parrot.