| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Well, what a week it's been, eh sportsfans? Without much more ado here's a rundown of all the excitement in the Perl 6 development camps.
The week before last saw a couple of fantastic postings on Perlmonks dealing with the fun stuff in Apocalypse 5. I'm sorry I missed them last week. Damian is still beavering away on the Exegesis but these (shall I call them Apocrypha?) are well worth reading.
John Porter worried about the second system effect, and about whether the movement to implement a bunch of 'foreign' VM ops on Parrot was just going to add bloat and inefficiency. Dan assured him that "These 'add-on' bytecode interpreters don't get any special consideration in the core." John was reassured.
I think it was decided that Parrot is a second system, but that we're working to avoid the classic problems associated with them.
Simon Glover had a problem with
A: # prints "a"
print "a"
end
Which kills the assembler because of the presence of the comment. Tom
Hughes posted a patch to fix than, and Brian Wheeler pointed out that
the patch means you can't do print "#", which would be bad. Tom
reckons he fixed that with his second patch.
archive.develooper.com Tom's initial fix.
archive.develooper.com And the second.
Sean O'Rourke is my hero. He's still beavering away on writing a Perl
6 grammar. The latest incarnation is apparently "Turing-complete, if
you have a parrot engine and a bit of spare time." The grammar is
still incomplete (of course), and someone pointed out that it had a
problem with code like { some_function_returning_a_hash() }. Should
it give a closure? Or a hash ref. Larry hasn't commented so far.
Sean comments: "The fact that I've been able to whip this up in a couple thousand lines of code is a remarkable testament to Parrot's maturity, and to the wealth of tools available in Perl 5. In particular, without The Damian's Parse::RecDescent, Melvin Smith's IMCC, and Sarathy's Data::Dumper, it never would have been possible."
Quote of the thread: "What, this actually runs? Oh, my." -- Dan Sugalski
I asked, they answered. Apparently Reading TFM would have been a good place to start, though Melvin Smith didn't put it quite so bluntly when he told me. Essentially, the IMCC is the Parrot intermediate language compiler. It's a bit like an assembler but sits at a slightly higher level and worries about the painful things like "register allocation, low level optimisation, and machine code generation." and everyone gets to share that wealth, Perl6, Ruby, Python, whatever, they all need the same facilities that IMCC provides.
The idea is that, instead of worrying about registers, you just provide a string of temporaries or named locals, so you can write:
$I1 = 1
$I2 = 2
$I3 = $I1 + $I2
$I5 = $I3 + 5
And IMCC will notice that it only needs to use 2 registers when it turns that into:
set I0, 1
set I1, 2
add I0, I0, I1
add I0, I0, 5
Melvin finishes by saying " If people don't get anything else, they should get this. Implementing a compiler will be twice as easy if they target the IR instead of raw Parrot. At a minimum, they implement their parser, generate an AST, and walk the tree, emitting intermediate expressions and directives."
Leon Brocard, who I am constitutionally required to namecheck in every perl 6 summary, tells me "imcc is the coolest thing... Please don't quote me verbatim." Tee hee.
The fine manual is at languages/imcc/README in the parrot source tree.
This continued from last week. For some reason this ended up with a discussion of Pythagoras' Theorem and Manhattan Distance (this was to do with the idea of dispatch based on distance in type space...)
John Porter worried about the cost of generating full MM dispatch tables, quoting some scary numbers. Dan reckoned that the numbers weren't that scary, and that the problem was limited quite neatly.
Quote of the thread: "I'm not sure I want an algorithm that drives on the sidewalks, runs red lights, and chases pedestrians..." -- Dan Sugalski (again)
archive.develooper.com is a good 'root' to start at.
archive.develooper.com Quote of the thread, in context.
Can I put out a plea for someone, once the dust has settled, to summarise the state of multi dispatch?
Dan mapped out what would be needed to implement a non-native VM. I think he just wants to play Zork using parrot, but I'd never actually say that. He also said he'd have the specs for dynamic opcode and PMC loading out within 24 hours, but I think events may have intervened.
Clark C Evans reckoned that we'd need both strings and buffers and argued that all strings should start off as mutable, but that it should be possible to 'freeze' them. He also pointed out that there should be no corresponding 'thaw' operation. He wondered too if these semantics might be useful for more than just strings. Florian Haeglsperger wondered if Copy on Write didn't solve the problem at a stroke, to which the answer appears to be 'Not Really'. Dan thinks that readonliness should probably hang off PMCs rather than strings and buffers. Dan also commented that we need to nail down some semantics about when things can and can't be modified.
The discussion slowly morphed into a discussion of types in Perl and other languages. Melvin Smith noted that "we've built this register based VM upon which Perl will probably be the most non-optimised language. Things like exposing your lexical pads, eval, etc. blow optimisation out of the water.", but reckoned that Perl itself would probably still see a massive speedup.
Ashley Winters got scary. A paragraph that begins "Whenever the compiler runs across an eval, take a continuation from within the compiler." is always going to be worrying. Actually, he proposed it as a topic for a CS master's thesis, and Dan pointed out that one Damian Conway is looking for students...
Quote of the thread: A tie between Ashley's paragraph opener above and "[Parrot] will have reflection, introspection, and Deep Meditative Capabilities." -- Who else, Dan Sugalski
archive.develooper.com (re)start here.
One of the weird things about a system that can do continuations is that stack frames need to come out of managed memory, you can't just use the C stack. And if you *don't* manage stack frames using garbage collection, then you end up with memory leaks 'cos the stack frames don't get released. Which is where we stood.
Dan is in the process of making sure that system stack frames get properly garbage collected. Mike Lambert also stepped up and did some/most of the implementation.
archive.develooper.com Mike's patch.
Melvin Smith put out a call for someone to do an audit of the keyed aggregate handling code and find out which methods are missing, which ones aren't handled by the assembler and generally to fix them. Sean (Her)O'Rourke has apparently done the deed.
Alberto Simões wondered about copying and cloning of arrays and other aggregates. How deeply should one go when making a copy as opposed to just taking a reference? This one is still awaiting an answer.
The internals list came close to a flame war over this one. John Porter opened with the somewhat incendiary "I have to say that I am extremely disappointed at the paucity of internal documentation." and went on to make some good points, but in a tone that rather annoyed several people.
Productive stuff that came out of this, and the subsequent 'Parrot contribution' thread include:
So, if you have a question that you think belongs in the FAQ, send a message to the list with a subject line of 'PARROT QUESTION' and we'll try and produce some sensible answers and add them to the FAQ.
In the end, I think we ended up generating more light than heat, but it was touch and go for a while...
Sadly, the first PARROT QUESTION post didn't contain any actual questions. Ashley Winters pointed out that 'test_main.c' is a rather weird place to find parrot's main loop and wondered why parrot.c is empty.
His followup contained the actual questions, most of which got well answered in the following thread, which is still ongoing.
Tom Hughes told us he was trying to make sense of the current status of keyed access at all levels, from assembler through the ops to the vtables and is getting more confused the more he looks. Which can't be good. Melvin Smith agreed that things were confusing, but thought that things might get a little less confusing when he'd committed Sean's patches. Discussion is ongoing.
archive.develooper.com Ashley's background post.
archive.develooper.com Ashley's questions
archive.develooper.com Tom Hughes on keyed access
Stephen Rawls submitted rx.dev, an overview of the regular expression code. Brent Dax added some clarification.
Alberto Simões unveiled a pile of documentation for the Array, PerlArray and PerlHash PMCs, earning himself a few Hero Points from me.
I'm not entirely sure I understood this thread. Sean O'Rourke submitted some patches to fix up Parrot's PMC type morphing. Mike Lambert pointed at some ambiguities and then Sean showed some code that seems rather counter intuitive to do with type morphing and comparisons. He also provided a test file which shows some places where Perl 5 and Parrot seem to disagree on semantics.
Mike Litherland made some suggestions about what should go in the Glossary. Patches were welcomed, and Dan added some terms to the glossary, which is visible at www.parrotcode.org
The game of 'find a good description of continuations' rumbled on for a bit. I liked Mike Lambert's description involving a traveller in a maze (that's why Dan wants a Z-machine interpreter running on Parrot. Continuations are the 'maze of little twisty passages all similar').
Anyway, Dan also posted a splendidly clear and lucid explanation of
continuations. (Oh frabjous day! Calloo! Callay!) Peter Scott wondered
about serialising continuations, which is a tough problem because some
state really can't be serialised (filehandles for instance), which
lead Ted Zlatonov to suggest FREEZE {...} and THAW {...} blocks.
archive.develooper.com Mike's 'maze' analogy.
archive.develooper.com Dan's "Continuations are just the stack, you know?" version.
Chip Salzenburg asked some hardish questions about MY, %MY and
the difference between them. Piers (continuations everywhere) Cawley,
proposed $a_continuation.the_pad, which should probably be
$a_continuation.MY on further reflection, which Dan seemed to think
wasn't utterly insane.
It was also proposed that things like
[localhost:~] $ perl
my $foo = 12;
print $foo;
my $foo = 'ho';
print $foo;
12ho[localhost:~] $
which is legal (with -w a warning) in perl 5 should be illegal in perl 6. This was left as Larry's call.
Quote of the thread: 'And side effects like "I call you, you modify me invisibly...." seems more like taking dangerous drugs than programming.' -- Melvin Smith
On seeing the quote of the thread, Richard (madman) Clamp popped up to point out that, with the aid of Devel::LexAlias you could already do that in Perl 5. Which is nice.
archive.develooper.com Thread starts here. Pretty much all worthwhile.
archive.develooper.com Quote in context
archive.develooper.com Richard Clamp's bombshell
archive.develooper.com -- Mark M. Adkins announced a perl script that hunts down all the POD files in the Parrot directory tree and uses that to generate an HTML tree in a new subdirectory. It looks rather handy.
arstechnica.com -- Dan pointed us at an explanation of CPU caches
Robert Spier pointed everyone at www.parrotcode.org, specifically the www.parrotcode.org
Sean O'Rourke proposed ripping a bunch of set_* ops out of core.ops
now that we've got 'proper' keyed access in the assembler. Dan
concurred.
archive.develooper.com Tanton Gibbs sent a patch that adds documentation and a .dev file for byteorder.c
Nicholas Clark is trying to eliminate compiler warnings.
archive.develooper.com
Steve Purkis has a patch to add usleep(int) and sleep(int) to
the Linux version of Parrot. Dan likes the idea, but the patch won't
go in until it can be made to work on Win32 as well.
archive.develooper.com Luke Palmer has a fibonaci.babylonia.flatirons.org for Perl 6.
This week, Allison Randal answered the new standard "5Ws questionnaire"
I'm on the IT staff at the University of Portland. In my spare time I enjoy working on Perl 6. In my spare-spare time I like to swing in a hammock and read and ponder the ineffability of 42.
I dream in Perl 6... ;)
On the Perl 6 design team I'm the other linguist, or Damian's clone, or the assistant cat-herder, or sometimes the Devil's Advocate. It depends on the day, really.
Perl 6 will be an incredible jump in power and flexibility. But it's also a lot easier to use. I think that fact is often missed. People see a flurry of changes, but they can't see the forest for the trees. It's not just about making the hard things more possible, it's about making the easy things easier. That's the message I want to carry.
February 17, 2004 at 13:42 GMT. ;) Okay, no. :) But the current estimates of 12-18 months sound pretty reasonable, especially with the progress we've seen in Parrot.
Life's too short to settle for weak coffee.
No, really, for the most selfish reason imaginable: I want to use Perl 6. Anything I can do to make it a better language or to help it reach production faster is well worth the effort.
And it's incredibly fun.
Extreme Geekiness in Unusual Packaging.
Perl rules!
Thanks to the denizens of #perl and #parrot for their, ahem, 'mad proofreading skeelz'. To Melvin Smith and Leon Brocard for their explanations of imcc.
This summary was brought to you with the assistance of GNER tea, and the music of Waterson:Carthy and Gillian Welch.
Once again, if you liked it, give money to donate.yetanother.org if you didn't like it, well, you can still give them money, maybe they'll use it to hire a better writer. Or maybe you could write a competing summary.