The Perl 6 Summary for the week ending 20030608
It's another Monday, it's another summary and I need to get this
finished so I can starting getting the house in order before we head off
to Boca Raton and points north and west on the long road to Portland,
Oregon. Via Vermont. (I'm English and as the poem comments, the rolling
English road is "A rare road, a rocky road and one that we did tread //
The day we went to Birmingham by way of Beachy Head." Just because I'm
in America doesn't mean I can't take an English route to OSCON)
We'll start with the internals list this week (and, given that there are
only 18 or so messages in my perl6-language inbox, we may well stop
there).
Building IMCC as parrot
It's been pretty much decided that IMCC will soon become 'the' parrot
executable. Josh Wilmes, Robert Spier and Leo "Perl Foundation grant
recipient" Tötsch are looking into what needs to be done to make this
so. It's looking like the build system may well see some vigorous
cleanup action in this process.
http://xrl.us/jax
The Horror! The Horror!
Clint Pierce continued to expand on the internals of this Basic
implementation. The more I see of his pathological examples, the gladder
I am that I escaped BASIC as quickly as possible. Still, kudos to Clint
once more for the effort, even if it is a tad embarrassing that the most
advanced language hosted on Parrot is BASIC. (On IRC Leon Brocard and
others have been heard to remark that they're? unlikely to go all out at
a real language until Parrot has objects. Dan?)
http://xrl.us/jay
The Horror! The Horror! Part II
The timely destruction thread still doesn't want to go away. Dan has
been heard muttering about this on IRC. Eventually, he did more than
mutter on IRC -- he stated clearly on list that 'We aren't doing
reference counting' and that as far as he is concerned the matter is
closed.
Dan's blog also has another of his excellent "What The Heck Is" posts,
this time about Garbage Collection.
http://xrl.us/jaz
http://xrl.us/ja2
http://xrl.us/ja3 - What the Heck is: Garbage Collection
The Continu(ation)ing Saga
Jonathan Sillito posted a longish meditation on Parrot's new
continuation passing calling conventions. He wondered if, now we have
continuation passing, we really needed the various register stacks that
were used in the old stack based calling conventions. Warnock's Dilemma
currently applies.
http://xrl.us/ja4
Clint Pierce, IMCC tester extraordinaire
Over the past couple of week's Clint Pierce has been porting his BASIC
implementation over to run on IMCC. In the process of doing so he's been
finding and reporting all sorts of IMCC bugs and/or misunderstandings
and Leo Tötsch (usually) has either been correcting Clint's assumptions
or fixing the bugs he's found. I've mentioned a few of these exchanges
that generated longish threads in the past, but that hasn't covered
everything that's been found, discussed and fixed. It's been great to
see this sort of dialogue driving the design and implementation forward
based on the needs of a real program.
The thread I've linked to below is another exchange in this ongoing
dialogue. Clint found a way of reliably segfaulting IMCC. Leo fixed it.
And on to the next.
http://xrl.us/ja5
And, on the subject of list stalwarts...
Jürgen Bömmels is still working away at the Parrot IO (PIO) subsystem.
In this particular patch, he's gone through the Parrot source replacing
occurrences "PIO_fprintf(interpreter, PIO_STDERR(interpreter, ...)" with
the better factored "PIO_eprintf(interpreter, ...)", which as well as
eliminating repetition, helps to keep the IO code slightly easier to
maintain.
Leo applied the patch. (Although it's not mentioned explicitly
elsewhere, Leo continues to keep up his astonishing productivity with
various other patches to Parrot)
http://xrl.us/ja6
Make mine SuperSized
Bryan C. Warnock continued to discuss issues of the size of Parrot's
various types, particularly the integer types that get used within a
running Parrot. Bryan argues that these should ideally use a given
platform's native types, worrying about guaranteed sizes only at the
bytecode loading/saving stage. Dan and others commented on this (Dan
essentially said that he understood what Bryan was driving at but wasn't
quite sure of the way forward, and outlined his options). Discussion
continues.
http://xrl.us/ja7
Call "invoke" call?
Jonathan Sillito submitted a patch which changes "invoke" to "call",
adds some PMC access macros and updates the tests. He and Leo Tötsch
discussed things for a while and I think the patch is in the process of
being rewritten as result of that discussion.
http://xrl.us/ja8
Constant Propagation/Folding
Matt Fowles had another bite at his Constant Propagation cherry. His
latest patch is rather more conservative, and actually has tests. Leo
changed one line and applied it.
http://xrl.us/ja9
Destruction order
One of the good things about a simple minded reference counting Garbage
Collector is that object destructors generally get called in a sensible
order; if you have a tree of objects, the various node destructors will
generally get called in such a way that a given node's children won't
have been destroyed already. Garrett Goebel asked if we could keep this
behaviour with the Parrot GC system. Dan was minded to say "Yes" as he's
been wrestling with issues of non deterministic destruction order in
another of his projects (So have I; it's a *very* long way from being
fun, if I had the C chops I'd be trying to fix Perl 5's 'at exit' mark
and sweep garbage collector to do something similar.)
http://xrl.us/jba
K Stol's Lua Compiler project
Klaas-Jan Stol announced that he's turned in his project implementing a
Lua compiler that targets Parrot. He hasn't actually finished the
compiler, his deadline being what it was, but he did post a link to his
project report and commented that "[Parrot is] a really cool project and
VM to target" and thanked everyone on the mailing list for their help. I
think the parrot-internals people will echo my best wishes to Klaas-Jan;
it's great to see someone who comes to a list with a project and,
instead of saying "Write this for me!", asks sensible questions and
makes a useful contribution to the ongoing task.
http://xrl.us/jbb
"joeijoei/parrot/report.pdf" in members.home.nl -- Project report
Meanwhile, in perl6-language
By gum, it's been quiet this week. I haven't seen any traffic in the
language list since Wednesday. Maybe everyone's waiting for Damian's
Exegesis to escape.
Multimethod dispatch?
Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
Thing (it's definitely *a* Right Thing) and suggested that it would be
more Perlish to allow the programmer to override the dispatcher,
allowing for all sorts of more or less cunning dispatch mechanisms
(which isn't to say we could still have MMD tightly integrated, but it
wouldn't be the *only* alternative to simple single dispatch). Luke
Palmer gets the "Pointy End Grandma" award for pointing out that Perl 6
is a '"real" programming language now' (as Adam pointed out, Perl's been
a 'real' programming language for years), inspiring a particularly pithy
bit of Cozeny. As far as I can tell, Adam wants to be able to dispatch
on the runtime value of a parameter as well as on its runtime type (he's
not alone in this). Right now you either have to do this explicitly in
the body of the subroutine, or work out the correct macromantic
incantations needed to allow the programmer to use 'nice' syntax for
specifying such dispatch.
Assuming I'm not misunderstanding what Adam is after, this has come up
before (I think I asked about value based dispatch a few months back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
It seems to me that if MMD is flexible enough to do this, then it
becomes easy to express any other set of dispatch rules as special cases
of this more general mechanism. (That said, I'm not sure how one would
go about expressing Smalltalk like message specifiers, which is a shame,
I like Smalltalk message specifiers).
http://xrl.us/jbc
Acknowledgements, Announcements and Apologies
Well, that's about it for another week. Next week's summary will be
coming to you from YAPC in Boca Raton. then there should be one from
chez Turoff in Washington DC (As far as I can tell the Washington
summary will the first summary of the second year of my summary writing,
if you're going to be in the Greater Washington area around that time,
consider getting in touch with either me or Ziggy and we'll see about
having a celebratory something or other that evening). After Washington
I'll be in Boston for the next summary, and at OSCON for the one after
that. I fully expect to be writing either enormously long summaries or
drastically curtailed ones while I'm over in the States. After OSCON,
there'll be a summary from Seattle and then I'll be off back home. If
you're in any of those localities at the appropriate times drop me a
line, we'll try and arrange meet-ups to wet the appropriate summaries'
heads.
If you've appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, photographic and writing commissions,
or a large collection of appropriately shaped tuits to
[EMAIL PROTECTED]
--
Piers
