develooper Front page | perl.perl6.internals | Postings from July 2002

Perl 6 Summary for week ending 20020714

July 15, 2002 04:24
Perl 6 Summary for week ending 20020714
Message ID:
Here you go folks

Perl6 Summary for week ending 20020714
    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.

  Still waiting for Exegesis 5?

    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.

  Is Parrot a second system?

    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.

  Don't mix labels and comments

    Simon Glover had a problem with

        A:              # prints "a"
            print "a"

    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.
    Tom's initial fix. And
    the second.

  Perl 6 grammar, take 5

    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

  So, what is IMCC then?

    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 name check 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.

  Vtables and multimethod dispatch

    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) is
    a good 'root' to start at.
    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?

  Building support for non-native bytecode

    Dan mapped out what would be needed to implement a non-native JVM. 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.

  Mutable vs immutable strings

    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
    (re)start here.

  Adding the system stack to the rootset.

    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.
    Mike's patch.

  Making keyed aggregates really work.

    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.

  Parrot: copying arrays

    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.

  coders: add doco

    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:

    *   FAQ writing should be a collaborative effort. The questions that an
        experienced Parrot head has, or thinks are important, are probably
        not the questions that a newbie would ask.

        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.

    *   The Parrot IRC channel is a good place for some stuff but has no
        'journal of record'. Something like's very lovely
        'scribot' bot could prove really useful. (I'm deliberately not
        putting pointers to the IRC channel, if you need to know, read the

    *   Why questions, and their answers are often really important.

    *   We really should be maintaining the .dev files associated with each
        source file, as mentioned in PDD7.

    *   Dan tries to be on IRC regularly from 1300-1700EST Wednesday. "While
        it's no substitute for e-mail, and not as good a realtime
        communication method as face to face communication, it's better than
        no realtime communication at all."

    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

    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.
    Ashley's background post.
    Ashley's questions Tom
    Hughes on keyed access

  More docs

    Stephen Rawls submitted, 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.

  Type Morphing

    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.

  Glossary requests

    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

  Meanwhile, in perl6-language

    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.
    Mike's 'maze' analogy.
    Dan's "Continuations are just the stack, you know?" version.

  What's MY.line

    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.
    Thread starts here. Pretty much all worthwhile.
    Quote in context
    Richard Clamp's bombshell

  In brief --
    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. -- Dan pointed us
    at an explanation of CPU caches

    Robert Spier pointed everyone at, specifically
    the Development Resources.

    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
    Tanton Gibbs sent a patch that adds documentation and a .dev file for

    Nicholas Clark is trying to eliminate compiler warnings.
    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. Luke
    Palmer has a vim highlighting file for Perl 6.

  The return of "Who's Who in Perl 6"

    This week, Allison Randal answered the new standard "5Ws questionnaire"

    Who are you?
        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.

    What do you do for/with Perl 6?
        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.

    Where are you coming from?
        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.

    When do you think Perl 6 will be released?
        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.

    Why are you doing this?
        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.

    You have 5 words. Describe yourself.
        Extreme Geekiness in Unusual Packaging.

    Do you have anything to declare?
        Perl "rule"s!


    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 YAS, 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.


   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen? Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About