This week's summary, correctly formatted

The Perl 6 summary for the fortnight ending 2005-06-21
    Surprise! It's me again. You may be wondering what happened to last
    week's summary (I know I was) and where Matt had gone. Well, I'm not
    entirely sure where exactly he is now, but last week was moving week for
    him.

    Those of you reading this on the mailing lists may also be wondering why
    this summary is so late. Um... three words: World of Warcraft.

This week in perl6-compiler
    As a Summarizer, when you see the 'last fortnight' view of a mailing
    list containing 21 messages, several thoughts spring, unbidden, to your
    mind: Is my mail broken again? Has everyone given up? Phew, this group
    won't take long to do.

    It turns out that the answer to both of those questions is "No." What
    actually happened was that most of the stuff that normally happens in
    mail happened at the Austrian Perl Workshop and Leo Tötsch's house, with
    a side order of IRC conversation. Oh, and a bunch of spin off threads in
    p6l and p6i.

    So, in the last fortnight Pugs reached the point where it has a (mostly)
    working Parrot back end and BÁRTHAZI Andras wondered if we shouldn't
    start a perl6-general mailing list.

    <http://xrl.us/gicz> - Autrijus's Pugs development journal

    <http://xrl.us/gic2> - perl6-general anyone?

This week in perl6-internals
    140 messages in this one. p6c lulled me into a false sense of security.
    Again, you may notice a bewilderingly fast rate of change this summary.
    It turns out that they weren't just working on Pugs at Leo's house. Perl
    6 Hackathons give great productivity.

  This is not your father's Parrot
    There's been some serious work going on under the Parrot hood in the
    last two weeks. The calling conventions have been drastically reworked
    and now uses 4 new opcodes, "set_args", "set_returns", "get_params" and
    "get_results". At the time of writing, IMCC doesn't give you full
    syntactic help with them, but they're easy enough to use explicitly for
    the time being and the help is getting there. Check out the PDD for
    details.

    Also getting rejigged is the continuation/register frame architecture.
    Taking advantage of the fact that this is a *virtual* machine, we now
    have an unlimited number of registers per register frame. Combine this
    with the new calling conventions, in which arguments are passed outside
    the register frame and all of a sudden a full continuation becomes a
    simple pointer to the register frame and everything gets saved as if by
    magic. Which opens up a whole bunch of possibilities. Which has
    interesting implications for the register allocator.

    <http://xrl.us/gic3> -- The new calling conventions

    <http://use.perl.org/~chip/journal/> -- Chip's design notes

  New Generational GC scheme
    Alexandre Buisse posted his outline for a Google Summer of Code project
    to implement a shiny new Generational Garbage Collection scheme.
    Discussion of tunability and threading issues followed.

    <http://xrl.us/gic4>

  Ordered Hashes -- more thoughts
    Steve Tolkin helpfully provided a summary of his thoughts about ordered
    hashes: "An ordered hash that does not support deletes could cause a
    user visible bug. At a minimum it should support the special case of
    delete that is supported by the Perl "each()" operator." Dan pointed out
    that reusing the ordered hash code for anything other than the lexical
    pad it was specifically implemented for was just looking for trouble.

    <http://xrl.us/gic5>

  The thread that I really hoped Matt would be summarizing
    AKA "Attack of the 50 foot register allocator vs. the undead
    continuation monster". Piers Cawley and Chip had something of a
    disagreement about interactions between continuations and the register
    allocator. After discussion on IRC it became apparent that they were
    talking past each other. The new 'the register frame is the
    continuation' means that yes, the register allocator definitely can't
    rely on being able to reuse registers that persist over function calls,
    but that's all right because you can always grab more registers.

    <http://xrl.us/gic6>

  Missing MMD default functions
    Remember the missing Multimethod functions I mentioned last time. At the
    time Chip hadn't ruled on whether taking them out was the Right Thing or
    not. He has since ruled that it was.

    This is probably not quite the right place to suggest this, but what the
    heck. Maybe in future when user visible changes of this sort are planned
    they should spend at least one release period deprecated and throwing
    warnings when used.

    <http://xrl.us/gic7>

  PGE, namespaced rules
    William Coleda worried that PGE subrules appear to be globally scoped.
    It turns out that Patrick worries too, but is currently in the process
    of thrashing out how they should be scoped. He outlined his current
    thinking.

    <http://xrl.us/gic8>

  PMCs and Objects question
    Klaas-Jan Stol wondered about the possibilities of overriding PMC
    behaviour with Parrot classes. He outlined possibilities and wondered if
    he was correct. Chip thought that it should be possible to implement
    (for instance) Perl's datatypes in pure PIR, if only for debugging and
    fun. I'm still not entirely sure if it's possible to make a ParrotClass
    that inherits from a PMC though.

    <http://xrl.us/gic9>

  Software Transactional Memory
    It seems the design team have drunk deeply of the Software Transaction
    Memory (STM) Kool Aid. STM is, to quote Chip, a "wicked cool" way of
    doing threading. Expect a more fleshed out design document eventually.

    <http://xrl.us/gida>

  Parrot bc
    According to the configuration scripts, Parrot looks for the GNU version
    of bc solely for checking that Parrot bc is working. Which is all very
    well, but there is no Parrot implementation of bc in the SVN repository.
    Apparently there's a broken version of it sat on Bernhard Schmalhofer's
    local hard disk.

    None of which addressed the issue of why, even with a 'working' version,
    the tests needed to access GNU bc. Surely tests can be written
    statically, the only time you'd need an authoritative version would be
    when you were adding tests. Oops, editorializing again.

    <http://xrl.us/gidb>

  Substituting for PGE
    Will Coleda wondered if it was possible to do substitutions with PGE
    yet. Yes, sort of was Patrick's reply - you can substitute the first
    occurrence by grabbing the match data and using substr. Everything else
    is for another day.

    <http://xrl.us/gidc>

  Unexpected behaviour calling method
    Klaas-Jan Stol had some problems implementing delegated addition.
    Apparently it's because he got caught out by the signatures of the
    "__add method". Also, it's a really bad idea to delegate to a method
    called "__add" because Parrot expects some very particularly behaviour
    from it. Think about calling it "add" instead.

    <http://xrl.us/gidd>

  Parrot Goals and Priorities
    Chip's put the slides of his Austrian Perl Workshop talk on the Parrot
    project and it's priorities up on feather. Check them out, they're good.

    <http://xrl.us/gide>

     -- slides

  New TODOs
    Will Coleda's been busy injecting a bunch of handy TODO items in the
    Parrot RT system. Check 'em out, you might be able to do some of them.



  New list for pirate
    Michal Wallace announced the creation of a new list for work on pirate,
    a python compiler for parrot. So if python on parrot is your bag, I
    suggest you sign up.

    <http://xrl.us/gidf>

    <http://xrl.us/gidg>

  Adding methods to existing classes
    Patrick wondered how to add methods to existing classes. It turns out
    that the trick is to use "find_type" instead of "findclass". According
    to Leo, "findclass" is deprecated.

    <http://xrl.us/gidh>

Meanwhile, in perl6-language
    Hmm... 1242 GMT+1 on Thursday as I write this and there are... oh... 246
    messages in perl6-language. This could get sketchy...

  Reduce metaoperator on an empty list
    Wow! The 'Reduce metaoperator on an empty list' discussion is still
    going.

    <http://xrl.us/gidi>

  "return()" in pointy type blocks
    Much to my personal chagrin, it looks like "return()" inside a pointy
    block will use an escape continuation and will probably be picky about
    making sure that the pointy block is invoked from somewhere dynamically
    'below' the block it was created in. So no cunning tricks like:

      sub call_with_current_continuation(Code $code) {
        $code({ return $^cc })
      }

    Which is probably a good thing...

    <http://xrl.us/gidj>

  "caller" and "want"
    Gaal Yahas asked for clarification about the behaviour of the "caller"
    builtin. Larry provided it.

    <http://xrl.us/gidk>

  Musing on registerable event handlers for some specific events
    Adam Kennedy hoped that Perl 6 would have some sort of minimal set of
    hooks for handling events. (Personally I'd like a maximal set of hooks
    for anything that changes the runtime structure of Perl, but I'm greedy
    like that). Larry said that there would be such a thing, but that it
    wasn't designed yet. He appeared to volunteer Adam as an initial
    designer. Discussion ensued, but there's no concrete design yet.
    Slightly tangentially, Dan discussed his thoughts about a Parrot
    notifications manager on his blog, which might be useful to some.

    <http://xrl.us/gidm>

    <http://xrl.us/gidn>

  Speedbump placement
    In a thread discussing adding an "eval STRING" type behaviour to the
    right hand side of a substitution, Larry said that "Deciding where (and
    where not) to put the speed bumps is a pretty good description of my
    job. It's impossible to have a language without bumps, so I reserve the
    right to put the necessary bumps where I think they'll do the most good
    and/or least harm."

    Well, I thought that was worth reading by more than just the list
    subscribers...

    <http://xrl.us/gido>

  MMD vs. Anonymous parameter types referencing early parameters
    Chip threw up his hands and despaired of ever efficiently implementing:

      multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }

    Which is cute, but Chip claims you need Jedi Mind Powers if you want to
    make it work.

    The Thomas Sandlaß popped up to say that, actually there was already a
    language called Cecil that allowed you to do precisely that sort of
    thing (called Predicate Dispatch) and there were several efficient
    implementation strategies. After a nudge from Chip he even provided a
    link. Larry thought it eminently doable too and sketched out a strategy.

    That strategy (which applies almost everywhere in Perl when you think
    about) boils down to "If you can't do it at compile time, do it at
    runtime (and pretend you did it at runtime)".

    <http://xrl.us/gidp>

  State of the Design Documents
    Joshua Gatcomb worries about the state of the Synopses. He argued (quite
    persuasively) that the thing to do would be to put the synopses into
    public change control with global read access, but with write access
    limited to @larry. The community could then provide new documentation in
    the form of patches, which @larry would approve, reject or modify as
    appropriate. Which all hangs on whether @larry has sufficient tuits.

    Patrick pointed out that this already exists and that he had volunteered
    as gatekeeper and patch dispatcher, but that there were very few patches
    so far. But now you all know about it, right?

    Some discussion followed about how things would be fleshed out, but the
    important thing is the repository URL.

    <http://xrl.us/gidq>

    <http://xrl.us/gidr> -- That document repository

  How much do we close over?
    Piers Cawley wants to be able to write code like:

       sub foo { my $x = 1; return sub { eval $^codestring } }
       say foo().('$x'); # 1

    In perl 5 this would give warnings about an undeclared variable. Chip
    maintained that this is actually the Right Thing. Piers understood that
    it may not be the right thing in all cases, but he wanted to be able to
    make it work when needed, if necessarily with predeclaration. There was
    some discussion, but nothing from @larry yet.

    <http://xrl.us/gids>

  "BEGIN {...}" and IO
    Ingo Blechschmidt noted that that "BEGIN {...}" can be a little scary
    when you want to compile to bytecode. Consider:

      my $fh = BEGIN { open "some_file" err ... }

    Which is okay, until you have a version of perl that compiles that to
    bytecode. The response ran along the lines of "Don't do that then!".

    Personally I'd write that as

      my $fh = INIT { open "some_file" err ... }

    Assuming that my recollection that "INIT" blocks happen after the code
    is compiled but before it starts to run. Or do I mean a "CHECK" block?

    <http://xrl.us/gidt>

  Anonymous macros
    Ingo also wondered if anonymous macros (at compile time) were allowed.
    Larry had no problem with macros being first class objects during the
    compile. He also went on to wonder if they should be multidispatch
    too...

    <http://xrl.us/gidu>

  Perl defined Object, Array, Hash classes
    Whilst toying with pugs, Eric Hodges managed to overwrite the internal
    definition of the Object class. Which, obviously caused him pain. Larry
    reckons we'll have constructs like:

      class Object is augmented { ... };
      class Object is replaced { ... };

    (names up for grabs). My personally preference is for making 'augmented'
    the default behaviour, but I'll live if I can have a pragma that makes
    it that way.

    <http://xrl.us/gidv>

  "%hash1 »...« %hash2"
    David Formosa wondered about the behaviour of hyperops when applied to a
    pair of hashes. He wanted things arranged so that if you had a hash with
    keys in common then those would be kept together by the hypering
    process. Luke agreed that it would be useful (so do I for that matter)
    and then everyone started talking about inner and outer joins and my
    database comprehension head is swapped out at the moment...

    <http://xrl.us/gidw>

  Binding slices
    With a small correction for syntactical niceness, Piers wondered if

      my @y := @foo[0...][1]

    would bind @y to a 'column' of the two dimensional matrix represented by
    @foo[][] so that writing to @y would affect @foo and vice versa. @larry
    hasn't said anything yet.

    <http://xrl.us/gidx>

  "alias" the RubyMeter
    BÁRTHAZI Andras wondered if Perl 6 would have something like Ruby's
    rather lovely "alias". Larry thought you should be able to write a macro
    to do the job, but wasn't entirely sure how exactly it would be done.
    Further discussion centred on whether the feature was a good idea and
    whether it had the right name. One school of thought thinks it already
    exists and is called ":=", but I'm not quite so sure.

    <http://xrl.us/gidy>

  "&?CALLER::BLOCK" vs. any hope of efficiency
    Chip hopes that using &?CALLER::BLOCK as a general-purpose block
    promoter will be disallowed unless the calling block has already marked
    itself as callable. Larry thought that this would be okay, noting that
    he saw &?CALLER::BLOCK being mostly used for introspective purposes.

    <http://xrl.us/gidz>

  Creating a web templating engine
    Wow! Perl 6 isn't even finished and already Andras is talking about
    writing a web templating engine for it. He outlined his plan and
    wondered how to go about implementing it. Ingo and he discussed it.

    <http://xrl.us/gid2>

  Hyper concat
    Thomas Klausner has been playing with "»~«" and uncovered some
    weirdness. Said weirdness lead to a discussion of the default
    strings/patterns in "split" and "join".

    <http://xrl.us/gid3>

    <http://xrl.us/gid4>

  "sub my_zip (...?) {}"
    Autrijus worried that the current Pugs implementation of "zip" was
    signature less which, amongst other things, makes it uncompilable to
    Parrot. He wondered what it's function signature should be. Larry came
    up with the (admittedly slightly weird) goods.

    <http://xrl.us/gid5>

  Ignoring parameters
    Gaal Yahas wondered if he'd be able to write a class method as:

      method greet(Class undef:) {...}

    when his class methods made no references to the class object itself.
    Damian thought that the syntax should actually be:

      method greet(FooClass ::class) {...}

    and that subs and methods should complain about unused non-optional
    non-invocant parameters. There's more, see the sub for details.

    <http://xrl.us/gid6>

  Scalar dereferencing
    Autrijus wondered about the semantics of a scalar reference in the face
    of stringification and numification. He provided an example of Pugs'
    current behaviour that may, or may not be correct. Larry described
    broken behaviour before thinking again and describing the really correct
    behaviour along with a summary of his raccoon problems.

    <http://xrl.us/gid7>

  Taking "given" as read
    Piers wondered how to write a function that would look like a "given"
    block to any "when"s inside it. It turns out that you can't, yet. Damian
    thought that the right way to do it would be:

      sub factorial (Int $n is topic) {
        return 1 when 0;
        $n * factorial($n - 1);
      }

    Reading this again, I find myself wondering if the "return" is really
    necessary.

    <http://xrl.us/gid8>

  "./method"
    People don't like "./method". Other people don't like ".method" in
    methods. I think we have what we have on the 'least worst option'
    principle. But I would say that, I don't like "./method".

  "AUTOLOAD" and $_
    Sam Vilain wondered about the prototype of "AUTOLOAD". In the discussion
    that ensued it was felt that whatever happened, "AUTOLOAD" should return
    a code ref that *perl* would call.

    <http://xrl.us/gid9>

Th-th-the-that's All Folks!
    I remember now why I gave up writing summaries in the first place. First
    I started missing weeks, which meant that there was so much to write up
    in the fortnightly summaries, and then discussions got interesting,
    which meant writing them took so much longer because there were hard
    things to understand first.

    Still, once in a while is refreshing, but I really should stop putting
    things off until the last minute.

    Ahem.

    If you find these summaries useful or enjoyable, please consider
    contributing to the Perl Foundation to help support the development of
    Perl.

    <http://donate.perl-foundation.org/> -- The Perl Foundation

    <http://dev.perl.org/perl6/> -- Perl 6 Development site

    Or, you can check out my website. Maybe now I'm back writing stuff I'll
    start updating it.

    <http://www.bofh.org.uk/>

    Vaguely pretty photos by me can be found at:

    <http://xrl.us/giea>

• This week's summary, correctly formatted by The Perl 6 Summarizer