This week on Perl 6, week ending 2003-06-29

Welcome to the third of my US tour Perl 6 summaries. Once again I'm pleased
to report that the denizens of the Perl 6 mailing lists continue to make the
life of a touring summarizer an easy one by not posting all that much to the
lists. So, I can sit here in my room at the Shaker Inn in Enfield and marvel at
the traffic noise outside, wonder about the car next door with the New
Hampshire plates reading PERLFAN, and just generally appreciate the loveliness
of the room.

At the end of last week, Dan outlined his thoughts on how exception handling
will work in Parrot. This week, people talked about it. Discussion revolved
around how much information should be attached to an exception and how/whether
we should support resumable exceptions.

Last week I said that "I get the strong feeling that Leo Tötsch isn't
entirely happy with the new Continuation Passing Style". This week Leo
corrected me; I hadn't noticed that the speed issues had been addressed by the
latest changes to parrot (in fact the current CPS implementation is faster than
the old invoke/ret scheme).

Sean O'Rourke addressed Leo's problem with the Perl 6 Compiler tests failing
by saying that the compiler should really be ported to use CPS rather than
implementing a new variant of the Sub PMC that uses the old scheme. Leo
reckoned that such a port wasn't currently doable because IMCC needed to be
modified to use the CPS scheme, which would also involve reworking the register
allocator. Given Leo's prodigious rate of implementation, this may have already
happened.

Clinton A. Pierce had reported a memory leak in Parrot, but tracked it down
to a situation where he was doing:

.arg 0
call _foo

and forgetting to take the 0 off the stack. However, even after
he'd fixed that, he had segfault issues, and posted a (largish) code fragment
that tweaked the bug.

It appears that Parrot wasn't throwing warnings when stacks get to big, just
failing silently. Leo added a check for too deeply nested stacks, which at
least avoids segfaulting on logic bugs.

Leo and Dan discussed other places where such limit checking should be put
in place. Dan also muttered something about turning stack chunks into PMCs,
allowing for the garbage collection of stack frames. Leo also muttered about
the proliferation of stack implementations in Parrot (there are five) and
thinks it should be possible to have one general stack engine.

Jürgen Bömmels is in the process of porting the IO subsystem from
its current mem_sys_alloc/free based implementation to the sunny,
garbage-collected uplands of a PMC based implementation. However, he's run into
a problem; some of the operations in op.ops use integer File
Descriptors, grabbing information from a table in the interpreter structure.
This gets in the way of garbage collection, since any integer could be a file
descriptor.

Jürgen proposed removing the integer file descriptors and mandating
that ParrotIO PMCs be the only way to access IO (including the standard
STDIN, STDOUT, and STDERR). He proposed
adding get_std[in|out|err] ops to get at the standard streams.

Dan suggested that Jürgen Just Do It; the current IO system being more
than slightly hackish, essentially put in place until something better came
along.

Want to get involved in the Parrot development process? Don't know much
about Virtual Machine design and implementation? Do know Perl? Dan has a small
but interesting task for you.

At present, Parrot gets built without any compiler level optimizations
turned on because files like tsq.c can't have any optimizations
turned on (tsq.c is the thread safe queue module, which is
"annoyingly execution-order-dependent because it has to operate safely as
interrupt code potentially interrupting itself").

Dan would like a version of Configure.pl which can build a
Makefile (or whatever build tool we end up using) with per-C-file
compiler flags, and it needs to be possible to override those flags, per file,
by the platform configuration module.

Interested? David Robins seems to be, and he asked whether the build system
had to be Makefile based. Dan says not, but the really important
thing is that the resulting build script, or the config system that generates
the script be adequately understandable/maintainable.

Leo explained what's going on; essentially it boils down to issues with
register allocation not being aware of .local scopes. He
recommended that Clint use either true globals or lexicals instead of
.local. Clint isn't so sure that this is a good idea, pointing out
that there are occasions when having lexically scoped names at the IMCC level
as well as at the level of lexical pads would be very useful.

Luke Palmer has been thinking about value and reference objects. He wondered
if there was any value in a valclone operator alongside
set and clone which would allow the target PMC to
decide whether to use set or clone semantics. He also
offered a patch implementing the operator if people thought it would be useful.
Leo Tötsch wasn't sure the new operator was necessary.

Klaas-jan Stol noted that he'd encountered problems with reference/value
confusion when he'd been working on his Lua compiler, but he wondered if the
problem couldn't be solved by having a general, language independent "argument"
PMC class. (I'm not sure I understood what he meant by this so I'm hoping for
an explanation with code fragments).

There is a story that UK prime minister Harold MacMillan was asked by a
student what it was that concerned him most as Prime Minister. Mac replied
"Events dear boy, events."

Leo Tötsch laid out his thoughts and ensuing questions about
Exceptions, events, and threads, and how they played together. There has been a
small amount of discussion in response to this, but I think everyone's
currently thinking hard about the issue....

Luke Palmer wondered if there would be a standard way of inspecting the call
stack (for debugging/caller/etc). (I think I'm going to switch to
using the phrase 'call chain' rather than call stack, as the presence of
continuations makes the call 'stack' look pretty unstacklike....).

Leo and Dan both thought that this would be a high level language issue
rather than a Parrot issue, though Dan did note that there might be useful
things that Parrot could do to make such introspection easier/possible.

Leo Tötsch has been thinking about occasions when one might need to
monkey with the internals of an existing continuation (he was thinking about
the warnings state) and proposed several solutions. Dan favoured
his new opcode, updatecc and thought it would be good to be able
to broaden the scope of what one could update in a continuation/context. This
scared Leo somewhat, but Dan came up with some examples of where it might prove
to be useful.

Miko O'Sullivan engaged in some summer daydreaming by asking what everyone
was looking forward to most from Perl 6. Miko himself is looking forward to
more Pure Perl modules. If Perl 6 delivers on its performance promises then
there are going to be more and more things where implementing directly in Perl
will be fast enough, and Perl is so much easier to implement in than C....

Jonathan Scott Duff incurred Cozeny when he said that he's hoping that by
this time next year we'll have an 85% complete Perl 6 that will be usable in
production (by brave people). Simon Cozens noted that we already have such a
beast and it's called Perl 5. For some reason this led to a new marketing
slogan being proposed: Perl 6, the reconstituted cheeseburger of programming
languages. Somehow I don't think that one's going to fly. (I just read this bit
out loud to my wife and she says that she really doesn't like the thought of a
flying reconstituted cheeseburger, so I think we'd best leave it at that.

Tcha! I announce the retirement of Leon Brocard from his post as Perl 6
Summary Running Joke and put the right to choose the next joke up for auction
at YAPC. And what do you know, the winner of the auction nominates Leon Brocard
as the new running joke. So, settle in for another year of desperate
rationalizations for mentioning Leon in these summaries. Who knows, maybe
Leon's Parrot related workrate will go up to such an extent that it'll be easy,
but somehow I doubt it.

Thanks to, in chronological order, Adam Turoff and Lisa Wolfisch; Walt
Mankowski, Mark-Jason and Laurie Dominus; Dave Adler; Dan and Karen Sugalski;
and Uri and Linda Guttman for being such fine hosts in Washington,
Philadelphia, New York, Hartford, and Boston respectively. Next time we do
this, we will not be attempting to visit quite so many cities on the Eastern
Seaboard in such a short time. At one point all we were seeing was Perl nerds
and freeways in rapid succession.

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