This week on Perl 6, week ending 2003-05-25

By Piers Cawley on May 25, 2003 12:00 AM

Welcome back to another Perl 6 summary in which Piers comes back from
watching a load of pretty girls dancing 'round a huge Maypole in
Wellow (it's 60 feet high, the tallest permanent Maypole in England,
there's been on on the site since at least 1856. One does wonder if
the Lord of the Manor who put the first one up was compensating for
something). It's not my favourite English traditional event (you'd
have to go a long way to beat the Whitby Penny Hedge for weirdness or
the Brockworth Hill cheese-rolling for complete and utter reckless
insanity (it was called off this year because the people who usually
provide cover in case of accidents are in Algeria helping deal with
the aftermath of the earthquake there; St John's Ambulance didn't feel
up to the rigours of dealing with the kind of injuries that occur when
too many people chase a Double Gloucester cheese down a 1 in 2
slope.)) but it made for a lovely afternoon.

Which is why, instead of having this written by mid afternoon on a
Monday, I'll be lucky if I have it finished before Tuesday. Ah... the
trials of a summary writer.

So, we'll start with perl6-internals because that's what we always do.

Will Coleda discovered that IMCC didn't allow him to have a variable
name that happened to be the same as an op, which isn't what the spec
says and which could lead to interesting problems where IMCC source
code suddenly becomes invalid when someone adds a new op to the
language. Will sent a patch to fix the docs. Leo Tötsch didn't
apply the patch, choosing to fix the problem instead. Yay Leo.

Leo Tötsch finished checking a series of patches which switch
the Parrot source code over from accessing vtable innards directly to
accessing them via macros, thus making it easier to monkey with vtable
internals without having to change a million and one different source
files.

After last week's discussion of timely destruction, the debate
continued this week. Dan announced his design for dealing with the
issue. PMCs now get a flag marking them as requiring timely
destruction and there's a new op to trigger a DOD run if and only if
there are any flagged PMCs in memory. The idea is that compilers for
languages that care about timely destruction would insert the
lazysweep op into their generated code in the appropriate
places. Mr. Zellyn Hunter (hey, that's what he asked to be called, who
am I to argue?) suggested a different name for Dan's proposed flag and
offered the following joke which I repeat here in its entirety because
it's funny (because it's *true*).

Q: How many Parrot programmers does it take to screw in a lightbulb?

A: Just one, as long as it's Leo Tötsch. He will probably also
rewire your entire electrical system slightly, saving you about 3% in
power consumption during the evenings and on weekends.

Leo denied the truth of this as lightbulbs are hardware and he doesn't
do hardware.

Meanwhile, back at the thread...

Guess what? People didn't like the solution. I think this is a classic
problem of GC. Everyone agrees that real Garbage Collection is a good
idea, but they also want it to work by magic and take no time at
all. Sadly, whilst Leo is good, even he can't change the laws of
physics. My suggestion: if you're currently writing Perl code that
relies on magic to close a filehandle the instant it goes out of scope
then Don't Do That, close it yourself. That way, when you come to
switch things over to Perl 6 you can do use GC scope_end => undef (or something) and get blistering performance and real GC.

Clinton A Pierce has rewritten BASIC's expression evaluator and is
reintegrating it with the runtime. This has left a lot of 'junk code'
that never actually gets executed, and Clint wanted to know if there
was a way of tracking down (and removing) the unreachable code. Leo
implied that the answer is 'run it under IMCC' which apparently does
dead code detection. This didn't quite work for Clint as IMCC threw an
error when it tried to run some BASIC generated PASM (at least, it
does when run in dead code detection mode...) Leo wasn't able to help
directly with tracking down the issue, but did provide some pointers
for conversion of the BASIC compiler so that it targets IMCC's PIR
language instead of simple Parrot assembly. This prompted a list of
questions from Clint about IMCC and Luke Palmer provided a some good
answers.

Sean O'Rourke noticed the new Perl 6 book in O'Reilly's catalogue and
wondered where Leo found the time to become an author as well as a
coding machine. Dan popped up to note that the plan is to have the
book available in time for OSCON and YAPC::Europe. (Be there or be
somewhere else). Randal Schwartz mentioned that he'd been a tech
reviewer for the book and had found it 'quite an interesting read'.

Leo Tötsch posted a proposed new layout for PMCs now that PMC
access has been hidden behind macros and asked for comments on his
proposed new scheme for the new PMC layout. Dan commented on this, and
between them he and Leo appear to have hashed out a way forward. Leo
kicked out a patch using the new PMC scheme, with a second version not
long after.

Dulcimer wondered if anyone was working on a simple introductory
tutorial for Perl 6 yet. He thought that writing one might help get
him up to speed, especially if people on the list critiqued it as he
wrote it. Michael Lazzaro pointed to the documentation list
perl6-documentation@perl.org which is apparently rather quiet at
the moment. Dave Whipp wasn't sure that the time was right to write a
tutorial yet as we don't yet know enough about the final language
(Personally I think anyone attempting to write a Perl 6 tutorial
before the object system gets designed/documented is going to end up
having to do some fairly dramatic rewriting at some point).

Anyhoo, this led to a string of suggestions trying to sum up the
Spirit of Perl 6, one of which managed to be a spoiler for Buffy the
Vampire Slayer...

Simon Cozens also nodded towards the forthcoming Perl 6 Essentials
which may be just what Dulcimer is after.

Discussion of Coroutines in Perl 6 was the thread that ate the list
this week. John Macdonald, had a few observations about using
coroutines and suggestions for the best semantics for them in Perl
6. There seems to be a split between those who want the caller to know
it's calling a coroutine and those who want the coroutine to be
invisible to the caller. Halfway along the thread, Damian wrote up a
proposal which he hoped would make everyone happy. It didn't succeed,
but it was at least a step forward as the proposal got batted back and
forth a few times, leading to another proposal which got batted back
and forth a few more times and which received far more acclaim.

Damian's proposals introduced a new coro declarator for coroutines,
which Piers Cawley thought wasn't really necessary, and there was some
discussion about whether 'coroutineness' was something that could be
applied to all sorts of different Code based things, in which case
using new declarators could lead to ugliness (coro, comethod, coblock,
corule...) or if there was only really one thing. The jury is out on
this.

There was also discussion of possibly unifying coroutine and threading
syntax, which some people thought was cool and which others disliked
intensely (nothing new there then).

There was also discussion of what a coroutine is, and why you would
want to use them. Damian gave a good explanation of some of
this. Actually, Damian gave some really good philosophy in this thread
about why he likes Perl.

Elsewhere in the thread, some fool called Piers Cawley attempted to
introduce a discussion of multimethods and failed dismally to change
the subject line. Bad Piers.

The eponymous Bryan C. Warnock (note to any Wired Jargonwatch editors
who may be watching, that's Bryan, not 'Brian') popped up to set
the record straight about his dilemma. Delightfully, by the end of the
week, nobody had replied to him.

Thanks once again are due to all the good people on the Perl 6
lists. Apologies will probably be due to the organizers of YAPC North
America as I still haven't started writing the talks I'm supposed to
be giving.

If you've appreciated this summary, please consider one or more of the
following options: