This week on Perl 6 (week ending 2002-08-11)

by Piers Cawley
August 11, 2002

Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-eight million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think inventing programming languages is a pretty neat idea.

So, as one amazingly primitive life form to another, here's what's been going on in Perl 6 development this week. As is becoming tediously traditional, we'll start with the internals list...

Array vs. PerlArray

Way back in the mists of a fortnight ago (that's 'two weeks' for the unenlightened Americans among us.) Melvin Smith announced that he was thinking about copying some of the fixes that had been made to the PerlArray PMC over to array.pmc as well. This week, Steve Fink sent in a patch for an alternative approach, which makes PerlArray a subclass of Array. Being appropriately lazy, Steve also added some rather useful looking keywords to the PMC parser, which added some shiny looking OO features. He then delivered an extended, 3 post monologue in which he kept replying to himself and refining his explanation of what the patch did. When he finally stopped talking to himself Dan told him to just commit it.

Related Reading Perl in a Nutshell, 2nd Edition By Stephen Spainhour, Ellen Siever, Nate Patwardhan Table of Contents Index Sample Chapter Read Online--Safari

A side point in Steve's discussion with himself (and Sean O'Rourke off-list, apparently) was the idea of dramatically simplifying default.pmc so it just throws an exception for operations it doesn't know how to deal with, rather than trying manfully to satisfy the demands of an unreasonable programmer. Dan reckons he should go ahead and rip out the old, obsequious code.

http://groups.google.com/groups -- Start here

Unifying PMCs and Buffers for GC

Mike Lambert had stepped up to this task and gave us a brain dump of his plans. This week Jerome Vouillon wondered about the long term plans for the Garbage collector, and wondered if we knew how to implement a generational garbage collector when one has several pools. Dan's long term plan for the outside world is that 'GC is a black box that just works.' Internally, he doesn't care, so long as it satisfies the 'just works' criterion. Mike Lambert thinks that a generational collector shouldn't be too hard.

Josef 'how do I type "ö" again?' Höök wondered how/if this would affect his matrix implementation, and when/whether his code would be merged with the current tree. Dan answered that he was a little concerned about PMCs which add code to the core, and Josef explained that he wanted to be able to reuse some of the code in some future multiarray.pmc

http://groups.google.com/groups

http://groups.google.com/groups

Register allocation for the JIT

Nicholas Clark and Daniel Grunblatt held a learned discussion about this, with particular reference to the ARM and i386 architectures. There were diagrams. And discussions of hardware documentation. It was both scary and surprisingly easy to understand. And a consensus was reached, which is nice.

http://groups.google.com/groups

Stack mark ops & such

Dan announced that he was 'about half a step from putting pushmark, popmark, stack marks, and suchlike things into the core.' and that this was everyone's opportunity to tell him what a bad idea it was. Jerome Vouillon wondered how they'd interact with continuations and coroutines. Answer: 'Interestingly'. Jerome offered a code sample which may be surprising, and asked Dan a hard question. Which Dan hasn't answered yet.

Melvin Smith wondered if there was a real issue with continuations, since each continuation got its own copy of the call stack. There is an issue, but it'll likely be solved by documenting its existence.

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

Exceptions

Dan posted his road map to exception handling. Or rather, he described the two ops (push and throw) needed to do exception handling, but punted on what an exception object should look like.

Florian Weimer wondered if it wouldn't be possible to handle exception objects in the throwing context. Dan reckoned that this could be problematic, which is why we're not going to do it 'at the moment'.

Jerome wondered if we really needed the pushx opcode at all. Tanton Gibbs disagreed and there was some back and forth about that, and about whether it made sense to think of a return as an exception (it does, but only rarely, when you're writing your own control structures; Damian will explain more later).

Dan also thought that pushx would be necessary, and Jerome clarified his suggestion. Simon Glover wondered what happened when a program didn't define an exception handler and was reassured that there would be some kind of default (probably language specific) handler in place, and if an exception got past that then Parrot would handle it itself with a suitably 'big fit to STDERR' before dying in a fit of pique.

http://groups.google.com/groups

http://groups.google.com/groups -- Discussion of whether pushx is necessary starts here.

Pages: 1, 2, 3

Next Page