This week's Perl 6 Summary

The Perl 6 Summary for the week ending 20030413
    Another week passes, another summary gets written. How does he do it?

    We start, as per usual with the still very quiet perl6-internals list.

  hey sexy where you been?
    The internals list's normally impeccable spam filters failed slightly
    this week and we actually saw a couple of spam messages sent via the RT
    system. The problem is being looked into.

  Support for true and false properties
    Stéphane Payrard posted a 'micropatch' to support the true and false
    properties that are Perl 6 needs.

  PMC "elements()" inaccessible from the assembler?
    Stéphane also wondered about how he should access a PMC's "elements"
    method via Parrot Assembly as there didn't seem to be a an appropriate
    operator defined in core.ops. Leo Tötsch said that it was known that
    there were inconsistencies between vtable definitions and the ops files
    and that a major cleanup was needed which would probably happen once it
    became clean which vtable methods will remain and how core.ops needed to
    change.

    <http://xrl.us/f8g>

  Parrot on Win32
    Clinton A Pierce announced that he'd built a Win32 Parrot distribution
    and had put a zip file up for downloading (and hopefully mirroring). He
    warned that it was very much a work in progress and the downloader
    should beware. But hey! Parrot on Win32! Bravo Clint!

    In the same vein, Mattia Barbon posted a couple of patches to improve
    Win32 support.

    <http://xrl.us/f8h>

    <http://xrl.us/f8i> -- Parrot on Win32!

    <http://xrl.us/f8j>

    <http://xrl.us/f8k>

  Dan's Blog
    Dan Sugalski continues to post interesting stuff on his weblog,
    including a discussion of the challenges he faces in writing Parrot's
    Object spec.

    <http://xrl.us/f8l>

Meanwhile over in perl6-language
    The internals list is still very quiet, seeing all of 28 messages.
    Meanwhile perl6-language saw over 200 messages. Maybe it had something
    to do with Allison and Damian's Synopsis being posted on perl.com

    <http://xrl.us/f8m>

  Incorporating WhatIf
    David Storrs had wondered about the CPAN module WhatIf which provides
    rollback functionality for arbitrary code. He wanted to know if support
    for this rollback capability could be added to the Perl 6 core. Luke
    Palmer liked the idea, and pointed to Larry's discussion of "let
    subcall()" in one of the appendices to Apocalypse 6. Simon Cozens
    thought that 'that way lies madness' and wondered if we weren't already
    a long way down that road. The thread got a little bit meta at this
    point, discussing what was and wasn't a valid rationale for adding
    something to the core rather than just implementing it in a module.
    Austin Hastings rule of thumb (which seems to be a good one) is that
    something belongs in core if it 'enables a paradigm', citing rules,
    continuations, multidispatch, thread support and the new object system
    as examples of paradigm enabling stuff that belongs in core. Dan
    Sugalski's rule of thumb is 'does it provide extra utility at marginal
    cost?' Spot the implementer.

    It turns out that Larry's rule of thumb is pretty much the same as
    Austin's and he thinks we should add "let funcall()" to the core because
    'management of hypotheticality is the essence of logic programming'.

    <http://xrl.us/f8o>

    <http://xrl.us/f8p> -- The WhatIf module

    <http://xrl.us/f8q>

  "==" vs "eq"
    The discussion of the meaning of

        \@a == \@b

    continued. In particular, does it return true if @a and @b are bound to
    the same array, or does it return true simply if @a and @b have the same
    number of elements. John Williams noted that he was looking forward to
    Apocalypse 8, on references which would hopefully clarify a lot of these
    issues.

  The Over overloading of is
    Piers Cawley pointed out that the three different behaviours of 'is'
    that Luke Palmer had worried about the week before were all just
    examples of setting traits on containers and provided some code in an
    attempt to show what he meant. Luke Palmer wasn't convinced (and I'm not
    entirely convinced myself) but thought it was probably best to reserve
    judgement until the Objects and Classes Apocalypse has been done.

    <http://xrl.us/f8r>

  Properties and Methods and Namespaces, oh my!
    Piers Cawley tried to put Luke Palmer's worries about clashes between
    method and property names to rest, and failed to do so. Luke wanted to
    have lexically and dynamically scoped properties, but that gave Dan
    Sugalski the screaming abdabs. Luke Palmer came up with anonymous
    properties, an idea which I particularly like:

        my $visited = Property.new;

        sub breadth_first_traversal($root can LinksInterface, &code) {
            my @queue is Queue = $root;
            for @queue {
                next if .$visited;
                $_ = $_ but $visited;
                code($_);
                push @queue: .links;
            }
        }

    I don't think any of the design team have commented on this particular
    idea but I think it's lovely and I hope it gets rolled into the
    language.

    <http://xrl.us/f8s>

  globs?
    Paul showed a lump of Perl 5 code that depended on globs to do bulk
    setting of attributes in hash based objects and wanted to know how one
    could do the same thing in Perl 6. Responses were along two lines, the
    first being that you wouldn't be able to do that sort of thing at all
    with Perl 6 objects, and others pointing out that you didn't really need
    a glob to get the example given to work. Paul was enlightened.

    <http://xrl.us/f8t>

  alphabet-blind pattern matching
    The discussion of how to match streams of objects as well as simply
    strings of characters using the grammar engine continued with a new
    subject line. And it continued to make my head hurt. I particularly
    liked Larry's observation that in 'treating patterns as too powerful for
    just test [...] we run the risk of making patterns to powerful for
    text'. Larry seemed to think that the idea of matching streams of
    objects with the grammar engine had merit though, which led to one of
    his wonderful 'thinking aloud' posts where he went through the various
    possibilities.

    <http://xrl.us/f8u>

    <http://xrl.us/f8v> -- Larry thinks out loud 'til his brain hurts

  Synopsis questions
    Angel Faus incurred the potential wrath of the summarizer by bundling up
    a whole host of questions relating to Synopsis 6 in a single post. Larry
    earned my undying gratitude by answering each question in a separate
    post with a new subject. Yay Larry.

    As it happened the answers provoked very little in the way of discussion
    so I don't really need to handle each question separately in this
    summary. Larry answered all the questions.

    <http://xrl.us/f8w>

  Variable/value type syntax
    Ralph Mellor wasn't keen on the syntax for declaring the types of values
    and variables and proposed a new syntax. People weren't keen. I have the
    really strong feeling that whoever writes the Perl 6 introductory texts
    will have an interesting time explaining the difference between variable
    and value types. At least Luke Palmer had a moment of clarity when he
    realised why using "is" for tying made sense...

    <http://xrl.us/f8x>

  Currying questions
    Ralph also wondered if currying assumptions could be overridden by
    passing the relevant argument by name when the curried function is
    called. Luke Palmer didn't think it should be allowed. No call from the
    core design team yet.

    <http://xrl.us/f8y>

  Multimethod Invocants
    Paul got confused by multimethods with multiple invocants and asked for
    clarification. Luke Palmer clarified things for him. The rule for
    multimethods is that multidispatch is only done on the invocants.
    Therefore a pair of declarations like:

        multi foo($me : Int $i)    {...}
        multi foo($me : String $s) {...}

    would probably throw a compilation exception or at the very least a
    warning because of the collision between invocant types. If you really
    wanted to dispatch on the type of the second argument you'd have to
    write the method declarations as:

        multi foo($me, Int $i:)    {...}
        multi foo($me, String $s:) {...}

    Larry pointed out that one generally calls multimethods as if they were
    subroutines, calling "$obj.foo(1)" would first try and find a *method*
    called foo, only falling back to multiple dispatch there were no such
    method to find. All of this engendered confusion in Michael Lazzaro (and
    in me if I'm honest, but now it's been made clear, it makes sense).

    <http://xrl.us/f8z>

  Change in "if" syntax
    Buddha Buck was caught out by the fact that, in Perl 6 you don't need
    parentheses 'round the test in an "if" statement and wondered when
    things had changed. Luke Palmer pointed out that they were now optional,
    a convenience bought by prohibiting whitespace between a variable and
    its subscript (so "%foo {bar}" does not look up the value associated
    with 'bar' in the %foo hash). Brent Dax hoped that this no whitespace
    rule was a simple tiebreaker, but Damian dashed that hope. The
    whitespace rule means that an opening brace after whitespace *always*
    denotes the beginning of a block or an anonymous hash. Some people don't
    like this.

    <http://xrl.us/f82>

  Named parameters are always optional?
    John Siracusa wanted a way of creating a subroutine that would only
    accept named parameters, some or all of which are required. With Perl 6
    as it stands, this appeared to be impossible without adding extra code
    to the body of the sub. Luke Palmer thought that what John wanted was
    silly, and suggested that if John really wanted the ability he should
    just write a module to do it. After a few posts back and forth on this,
    Austin Hastings pointed out that this discussion was analogous to the
    earlier discussion about WhatIf and what should and shouldn't be in the
    core.He argued -- by the 'enables a paradigm' rule of thumb -- that
    there was no need for core support for requiring named arguments because
    it could be added easily with a module. John thought that adding this
    with a module meant that there would be no way to check parameters
    successfully at compilation time (actually, I think you could, with a
    suitably clever macro...).

    By the end of the week John still wanted compulsory named arguments, but
    nobody else (who participated in the thread) seemed to be convinced that
    they were important enough to be implemented as part of the language.

    <http://xrl.us/f83>

  Aliasing operations in Perl 6
    Mark Jason Dominus asked for some clarification of the binding operator
    ":=" and how it interacted with autodereferencing. Given code like:

        my $zero = 0;
        my $zeroref = \$zero;

        my $bound := $zeroref;

    He wanted to know whether the value of $bound was 0 or "\$zero". Damian
    answered that references only autodereferenced themselves in an array or
    hash context, so the $bound would be "\$zero".

    <http://xrl.us/f84>

Acknowledgements, Announcements and Apologies
    Leon Brocard does not make his traditional appearance in this summary as
    he is on holiday. Normal service will hopefully be resumed soon.

    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 free entry to this year's OSCON and tutorials to
        [email protected]


-- 
Piers