This week's Perl 6 Summary

The Perl 6 Summary for the week ending 20030406
    Welcome my friends to the show that never ends. Yes, it's another of
    Piers Cawley's risible attempts to summarize the week's happenings in
    the Perl 6 development community. We start, as usual, with events in the
    perl6-internals world (not the perk6-internals world, obviously, that
    would be the sort of foolish typo that would *never* make it into any
    mail sent to the Perl 6 lists) where things have been quiet... too
    quiet. I think they're planning something.

  Documentation for PMCs
    Alberto Simoes posted some documentation for the Array PMC and suggested
    somewhere for it to be included in the Parrot distribution.

    <http://xrl.us/fp6>

  Extension PMC vs built-in
    K. Stol asked how to go about creating extension PMCs which he could use
    without having to recompile the entire Parrot VM. No answers yet.

    <http://xrl.us/fp7>

  Documentation problem with "set_global"
    K Stol reported a problem with parrot_assembly.pod, apparently there was
    a disagreement between the docs and the code about "set_global". Leopold
    Tötsch agreed that this was a documentation bug, but pointed out that it
    was far from being the only one. He suggested that parrot_assembly.pod
    should only have a general description of Parrot Assembly, with details
    of 'real' ops in generated docs like core_ops.pod and information on as
    yet unimplemented in the appropriate PDDs.

    <http://xrl.us/fp8>

  Building IMCC in Win32
    Clinton A Pierce's work last week to get IMCC building in a Win32
    environment was admired by Leo Tötsch, who promised to check the needed
    patches into the distribution.

    <http://xrl.us/fp9>

  Typos in rx.ops
    Cal Henderson submitted a patch to fix some typos in rx.ops, which were
    applied. Anton Berezin sent in a further patch to fix a few more errors.

    <http://xrl.us/fqa>

  Parrot regex engine
    Benjamin Goldberg praised rx.ops, commenting that he was 'amazed at how
    cool it is' and wondered if the work was based on something else. Steve
    Fink thought it was original to Brent Dax. Steve also pointed to an
    unfinished draft of his detailed description of how at least one of
    Parrot's regex implementations works.

    <http://xrl.us/fqb>

    <http://xrl.us/fqc> -- Steve Fink's description

  Dan Explains Everything
    Away from the internals list, Dan Sugalski has been doing some
    fascinating brain dumps about the 'whys' of Parrot in his weblog
    'Squawks of the Parrot'. Specifically, he's been addressing why JVM and
    .NET weren't chosen. In the course of this discussion he's come up with
    a rather neat one sentence description of continuations: "A continuation
    is essentially a closure that, in addition to closing over the lexical
    environment, also closes over the control chain."

    Anyway, I commend the whole blog to you.

    <http://sidhe.org/~dan/blog/>

Meanwhile over in perl6-language
    The perl6-language list was where all the action was this week with the
    list attracting far more traffic than the internals list at the moment.

  How shall threads work in P6?
    Austin Hastings has 'been thinking about closures, continuations, and
    coroutines, and one of the interfering points has been threads.' Austin
    wants to know what the Perl 6 threading model will look like, and threw
    out a few suggestions. Matthijs van Duin thought that preemptive
    threading in the core would be unnecessary, arguing that cooperative
    threading would solve everyone's problems. Almost nobody agreed with
    him. Most tellingly, Dan disagreed with him. Parrot will be getting
    preemptive threads and that's not a point for negotiation.

    Larry popped up to point out that, at the language level, the underlying
    thread implementation (whether preemptive or cooperative) really didn't
    matter, what was more important to the user was how much information was
    shared between threads. Larry said he thought that both the pthreads
    (all globals shared by default) and ithreads (all globals unshared by
    default) approaches to threading were 'wrong to some extent'.

    <http://xrl.us/fqd>

    <http://xrl.us/fqe>

  Conditional "returns"s?
    Michael Lazzaro was concerned about the inefficiency of

        return result_of_big_long_calculation(...) 
            if result_of_big_long_calculation(...);

    and ugliness of:

        my $x = result_of_big_long_calculation(...);
        return $x if $x;

    He wondered if there was a less ugly way to do it in Perl 6. There is:

        given result_of_big_long_calculation(...) { return $_ when true }

    was the most popular solution, but Dave Whipp pointed out that it would
    also be possible to write:

        sub return_if_true ($value) {
            if $value {
                leave where => caller(1), value => $value;
            }
        }

    and then just do:

        return_if_true(result_of_big_long_calculation(...));

    You know, I like Perl 6 more and more.

    <http://xrl.us/fqf>

  == vs. eq
    Luke Palmer wondered if there was anything to be gained by getting rid
    of the distinction between "==" and "eq" and falling back to a
    polymorphic "==". Brent Dax pointed out that the "~~" 'smartmatch'
    operator did exactly that. Luke said that "~~" didn't meet his needs
    (its behaviour with hashes, for instance, isn't what you want when
    trying to find out if two hashes are equal). Smylers pointed out that
    Larry had already rejected (and had given good reasons why) the idea.
    Luke still wanted a 'generic equality' operator though. Marco Baringer
    threw a spanner in the works by pointing out that no such thing as
    'generic equality' exists. Luke also came up with a symbol for an
    identity operator, "=:=" defined as:

        sub infix:=:= ( $a, $b ) { $a.id == $b.id }

    Michael Lazzaro isn't convinced of the need for a universal .id method,
    but he does like the idea of an identity test operator. There was then
    some discussion of

        \@a == \@b;

    which, Michael claims would compare the lengths of @a and @b rather than
    their addresses. He backed this up with a quote from Larry where he said
    "But it's probably fair to say that $foo and @foo always behave
    identically in a scalar context". I think Michael's wrong because "\@a"
    is not the same as $a. By his argument it seems that even

        my $array_ref = \@foo;
        my $ary_ref2  = [1, 2, 3];

    won't work, which seems wrong somehow.

    Discussion continued with various different possible implementations of
    'generic' equality operators thrown up for consideration. One subthread
    even saw the return of Tom "I thought he'd got a life and left the Perl
    community" Christiansen in a thread that ended up talking about
    transfinite numbers and the cardinality of infinite sets (which was
    interesting, but rather beside the point). Andy Wardley got bonus points
    for making me laugh: "Gödel seems to think there is an answer, but he
    doesn't know what it is. Turing is trying to work it out on a piece of
    paper, but he can't say when (or if) he'll be finished." Okay, it may
    not make you laugh, but my degree is in maths.

    <http://xrl.us/fqg>

    <http://xrl.us/fqh> -- Why generic equality doesn't exist

  "is" is overoverloaded?
    Luke Palmer was concerned that "is" has too many meanings. It gets used
    for setting variable traits, defining base classes and setting up tied
    variables. Luke is concerned that these appear to be too varied in
    meaning, and proposed at least adding a new "isa" keyword for defining
    base classes. There was some discussion, but I'm not sure that either
    side is convinced of the other's rectitude.

    <http://xrl.us/fqi>

  Short-circuiting user-defined operators
    Joe Gottman wondered if there would be a way to write an operator which
    would short circuit in the same way as "&&" and "||". He wondered if
    this would be a function trait (suggesting "is short_circuit"), or
    something cunning to do with parameters. Larry thought Joe was trying
    too hard, proposing:

        sub infix:!! ($lhs, &rhs) is equiv(&infix:||) {...}

    He noted that if that couldn't be made to work you might have to declare
    the operator as a macro, but that it still shouldn't be too hard to
    implement. Dave Whipp wasn't too sure about Larry's assertion that
    declaring a parameter as &foo should force the RHS of that operator to
    be a closure. What, he wondered would happen with "10 !! &closure"?

    <http://xrl.us/fqj>

    <http://xrl.us/fqk>

  Ruminating RFC 93 - alphabet-blind pattern matching
    Yary Hluchan has been reading the Perl 6 RFC 93, which Larry discussed
    in Apocalypse 5 and discussed doing regular expression type matches on
    streams of 'things', where the things weren't necessarily Unicode
    characters. At one point though Larry popped up to say that the
    discussion seemed to run contrary to what he said about RFC 93 in
    Apocalypse 5.

    Further down the thread, Ed Peschko wondered about using the Regex
    engine 'in reverse' to generate a list of all the possible strings that
    a regular expression could match. Everyone politely assumed that when Ed
    referred to the rule "rx/a*/" he really meant "rx/^a*$/" and got stuck
    into the problem. Matthijs van Duin pointed out that to get a 'useful'
    list of productions you'd have to go about producing all possible
    matches of length 'n' before giving any possibilities of length n+1
    (where 'length' counts atoms I think...). Once Luke Palmer had that key
    insight he showed off an implementation that could generate such a list.
    Piers Cawley used Luke's cunning implementation to show a lazy
    "generate_all" method that would iterate through all the possible
    productions of a rule. Luke said that he hoped it wouldn't actually need
    such a wrapper to be lazy. Personally I think that might be a hope too
    far...

    <http://xrl.us/fql>

    <http://xrl.us/fqm> -- Luke's code, with explication further down the
    thread

  Named vs. Variadic Parameters
    This thread continued from last week. The problem is that, if you want
    to define a function that you would call in the following fashion:

        foo $pos, opt_nam => 'value', 'slurpy', 'list', ...;

    Then your signature needs to look like

        sub foo ( $pos, *@slurpy, +$opt_nam ) {...}

    which seems rather counter intuitive (though mixing positional and non
    positional parameters could be seen to be counter intuitive whatever
    happens...) Various people argued for longer forms to denote the
    differences between positional, named, optional etc arguments and
    proposed various solutions. Larry didn't sound all that convinced,
    pointing out that if you wanted to implement such parameter
    specification styles you could always use a macro and declared that
    "Perl 6 is designed to allow cultural experimentation. You may
    reclassify any part of Perl 6 as a bike shed, and try to persuade other
    people to accept your taste in color schemes. Survival of the prettiest,
    and all that..."

    <http://xrl.us/fqn>

    <http://xrl.us/fqo>

  Implicit threading
    The discussion of how to write short circuiting operators spawned a
    subthread (which, rather annoyingly shared the same subject...) trigged
    by a suggestion of David Whipp's to do lazy initialization of some
    variables by spawning subthreads. The idea being that one could do

       my $a is lazy := expensive_fn(...);

    or something, and Perl would immediately spawn a subthread to calculate
    the value of "expensive_fn(...)" then, at the point you come to use the
    value of $a, the main thread would do a thread join and block if the
    subthread hadn't finished. Austin Hastings liked the idea and went on to
    suggest other places in which implicit threading could be used. My gut
    feeling is that this is the sort of thing that will get implemented in a
    module on top of whatever explicit threading system we get in Perl 6.

    <http://xrl.us/fqp> -- Dave Whipp's cunning idea

    <http://xrl.us/fqq> -- Further discussion here

  Properties and Methods
    Luke Palmer was concerned about potential naming clashes between
    properties and methods. He thought that things would be safer if,
    instead of accessing properties using method call type syntax. He was
    also worried about method naming clashes between the methods of things
    in a junction, and of the Junction class itself. Nobody had commented on
    this by the end of the week.

    <http://xrl.us/fqr>

  Patterns and Junctions
    Adam D. Lopresto had a suggestion for using two different kinds of
    alternation in regular expressions. In Adam's proposal, alternation with
    "|" could ignore the order of the alternatives when attempting to make a
    match and alternation with "||" would do the kind of order respecting
    alternation we're used to. I confess that I wondered what on earth Adam
    was on about, but Luke Palmer liked the idea, pointing out a way
    something like it could be used for globally optimizing large grammars.
    However, he was unconvinced by the syntax and suggested that it would be
    better if we could mark rules as being 'side effect free' and thus
    capable of being run in arbitrary order.

    <http://xrl.us/fqs>

Acknowledgements, Announcements and Apologies
    The schedules for both OSCON and YAPC::USA have been announced and
    there's a fair amount of Perl 6 and Parrot related content at both of
    them. I shall be attending both conferences (but only speaking at YAPC
    -- about refactoring tools and about Pixie; the object persistence tool
    I work on, neither of which are Perl 6 related) and driving from YAPC to
    OSCON with probable stops in Washington DC, Philadelphia, Boston,
    Burlington VT, Ottawa and Chicago (where we cheat and hop on a train).
    Hopefully I'll get to meet up with some of my happy readers at some or
    all of these stops and at the conferences.

    <http://www.yapc.org/America/> -- YAPC

    <http://xrl.us/fqt> -- OSCON

    I would like to apologize to Leon Brocard for failing to mention his
    name in this week's summary. Leon is offering a 'Little Languages in
    Parrot' talk at OSCON though.

    If you've appreciated this summary, please consider one or more of the
    following options:

    *   Send money to the Perl Foundation at
        <http://donate.perl-foundation.org/> and help support the ongoing
        development of Perl.

    *   Get involved in the Perl 6 process. The mailing lists are open to
        all. <http://dev.perl.org/perl6/> and <http://www.parrotcode.org/>
        are good starting points with links to the appropriate mailing
        lists.

    *   Send feedback, flames, money, photographic and writing commissions,
        or a few pounds of <http://www.puttyworld.com>'s products to
        [email protected]

    This week's summary was again sponsored by Darren Duncan. Thanks Darren.
    If you'd like to become a summary sponsor, drop me a line at
    [email protected]


-- 
Piers