The Perl 6 Summary of the week ending 20031026
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://xrl.us/y99
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://xrl.us/zaa
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://xrl.us/zab
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://xrl.us/zac
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://xrl.us/zad
Class creation in bytecode
Mere moments after the metadata post, Dan went on to spec out the
assembly language needed to support it.
http://xrl.us/zae
Open Patches
Leo pointed everyone at http://xrl.us/zaf, 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://xrl.us/zag
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://xrl.us/zah
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://xrl.us/zai
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://xrl.us/zaj
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://xrl.us/zak
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://xrl.us/zal
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://xrl.us/zam
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://xrl.us/zan
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://xrl.us/zao
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://xrl.us/zap
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://xrl.us/zaq
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:
* Donating time to the project. We need more programmers, documenters
language implementers and generally useful people.
http://dev.perl.org/perl6/ and http://www.parrotcode.org/ have
details of mailing lists etc.
* Donating money to the Perl Foundation
(http://donate.perl-foundation.org/) to help support Larry, Dan
and Damian and enable them to spend more time working on Perl 6,
rather than petty things like making sure they're earning enough
money to feed themselves.
* Donating feedback to your summarizer ([EMAIL PROTECTED]).
