This week on Perl 6, week ending 2003-10-26

Oct 26, 2003 by Piers Cawley

Where does the time go? It seems like only yesterday that I was sat hiding Leon Brocard in the first letters of the first 11 body paragraphs of the last summary. Now, here I am, on the train, typing away in a desperate attempt to get this mailed out before Wednesday. Let’s start with perl6-internals again.

Object Freezing

Whoever would have thought that freezing objects would be so controversial? Object freezing is when you take an object and generate a ‘frozen’ representation of it that can be used to make a copy of the original object. It’s what Storable, Data::Dumper and YAML (to name three Perl 5 modules) all do more or less successfully. (Most of the time there’s no problem, the tricky case is a composite object which involves a circular data structure. Consider this:

    Ring -> A -> B -> C -> D
            ^              |
            `--------------'

(It’s not quite a purely academic example, I can point to at least one text editor that uses a similar data structure).

When you come to freeze your ring, you need some way of detecting the cycle and generating a finite representation that works. This isn’t the only problem; thread safety is hard, for instance.)

Dan’s set some fairly stringent requirements on whatever mechanism is used for freezing. The most important/stringent is the requirement that (because freezing during object destruction will be a possibility) object traversal is not allowed to use additional memory for that traversal.

Dan is convinced that we can do this using the Garbage Collector’s object traversal system. Leo Tötsch is equally convinced that we can’t. The resulting thread is rather meaty and hard to summarize without massive amounts of cut and paste so I’ll just point you at the root message. The upshot is that we’re doing it Dan’s way; Glorious Leader continues to trump Pumpking Patchmonster.

In another subthread there was a good deal of misunderstanding about XML declarations and parsing, which got cleared up surprisingly quickly.

http://groups.google.com/groups

Object Instantiation

Dan had a moment of clarity and declared that the Parrot Way to instantiate an object in class Foo will be:

  new P5, .Foo

All we need now is a working implementation. And, apparently, knowing what class a class is a member of might be handy, but Dan’s punting on (``ignoring the heck out of”) that one.

http://groups.google.com/groups

A less controversial API addition

In the middle of the discussion about object freezing, Dan popped up another thread to discuss how to invoke Sub/Method PMCs from C code. So Leo implemented Parrot_runops_fromc_args(), but he’s not exactly happy about the name. Regardless of the name, having this implemented is rather spiffy.

http://groups.google.com/groups

Old Big Problems before New Big Problems

Melvin Smith popped up with a rant about the Parrot development effort’s tendency to rush off to implement new stuff before making double sure about the ‘old’ stuff is actually complete and robust. To which I can only say ``Hear! Hear!” Dan agreed, and threatened to give Melvin the pumpkin after Leo had finished with it.

http://groups.google.com/groups

Class metadata for PIR/assembly files

Donning his designer’s cap again, Dan posted a rough spec for class metadata declarations in PIR and pasm files. It looks pretty decent to me. Melvin Smith made a few telling comments though, so it looks like Dan’s post isn’t quite the final word on the matter.

http://groups.google.com/groups

Class creation in bytecode

Mere moments after the metadata post, Dan went on to spec out the assembly language needed to support it.

http://groups.google.com/groups

Open Patches

Leo pointed everyone at http://www.parrotcode.org/openpatches/, the list of open Parrot patches and asked for a volunteer to go through and make sure that the list is in agreement with reality.

http://groups.google.com/groups

Leo’s notes on objects and classes

Leo posted a list of thoughts about how classes and objects will work in Parrot and offered a suggestion about using OrderedHashes to handle things.

http://groups.google.com/groups

Unifying vtables and method invocations

Leo wondered if we should arrange things so that PMC vtables could be invoked in the same way as in methods on Parrot level objects are invoked. Dan answered that it won’t be quite like that, but it will be close. (Yay! A reflective programmer writes).

http://groups.google.com/groups

More fixed number assignments

So, it turns out that adding PMC classes to the core breaks binary compatibility. Which needs fixing. Dan asked for volunteers. I’m afraid I don’t know what fixing it would entail.

http://groups.google.com/groups

Plotz!

Plotz (the Pol(l)y-Lingual Opcode Translation for the Z-machine) is Amir Karger’s shot at Parrot immortality by getting Parrot to run Infocom adventures. Right now he’s prototyping his design in Perl and he’s apparently 10 opcodes away from a tool that will run around two thirds of all released Infocom games. He’s rather happy about this.

http://groups.google.com/groups

Halloween Release

Melvin Smith proposed a ``just for fun” Halloween release of Parrot. Dan christened the putative release ``The Screaming Pumpkin”, and Leo thought there was a little too much stuff in flux at the moment. Me? I think it’s going to happen. The codename is too good to resist.

http://groups.google.com/groups

IMCC leaves the languages ghetto

Melvin Smith checked in a large patch to move IMCC from parrot/languages/imcc/ to parrot/imcc, reflecting the intention/reality that IMCC is parrot. As the week progressed, various other directories got moved around in an attempt to make things a little more logical. Everything is now, roughly in its place, but at one point during the week it would have been, frankly, foolhardy to attempt to check parrot out of CVS.

http://groups.google.com/groups

IMCC, Classes & Metadata, oh my!

Melvin Smith, who has returned from his Parrot holiday with a seemingly enormous supply of tuits, announced that he’d started work on implementing the class syntax for PIR and had reached a decision point, so he asked for comments. The consensus was to go with a short term hack for the time being, just to get something working, with a big flag for the future.

http://groups.google.com/groups

PIR changes

For those of you who are implementing things in IMCC, Melvin announced that he’d added newsub and newclosure to IMCC, allowing implementors to simply write P0 = newsub <label> and P0 = newclosure <label> which is rather more efficient than the PASM equivalents.

http://groups.google.com/groups

PMC initialization

Dan decided that the time has come to allow PMCs to be created with initialization data rather than having separate creation and initialization phases. Hes proposal, pending a Better Idea(tm) was to have two init methods, one taking no arguments and simply creating an empty PMC, and another which assumes that its parameters are in the registers (using the standard calling conventions) and goes from there. Leo thought it was a little heavy. I like it though, the more things that use standard Parrot calling conventions, the less I have to remember and the happier I am – but I am a bear of very little brain.

http://groups.google.com/groups

Meanwhile, in perl6-language

Luke Palmer asked a question about named named return values and :=. David Storrs boggled slightly.

Next week, Damian Conway answers Luke’s question.

http://groups.google.com/groups

Acknowledgements, Announcements, Apologies

Looks like the Wednesday ship date of the last summary was a temporary aberration. Which is nice.

If you found this summary valuable, please consider one or more of:

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