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

Jun 8, 2003 by Piers Cawley

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

http://groups.google.com/groups

http://www.sidhe.org/~dan/blog/archives/000200.html - 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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

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://groups.google.com/groups

http://members.home.nl/joeijoei/parrot/report.pdf – 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://groups.google.com/groups

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 be 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:

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub