The Perl 6 Summary for the week ending 2004-06-27
    What's this? No! It can't be! It's a *weekly* Perl 6 Summary. What is
    the world coming to?

    Sorry, I can't answer that one, so I'll tell you what's been happening
    this week in perl6-internals.

  Bignums, licenses, pie
    As you are no doubt aware, Python has bignums. And that means that,
    unless we want Dan to get a face full of Pie at OSCON this year, Parrot
    needs bignums too. Work on several fronts continued towards getting a
    bignum implementation for Parrot. Ideally, we'd like to just include
    GMP, but the license seems to require that the full source of GMP sip
    with any Parrot binary. Which isn't good when you're writing a VM that
    you'd like to be able to install on, say, a Palm.

    Scott Bronson suggested getting in touch with the GMP developers to see
    if there was anything that could be done about it. He volunteered to be
    the liaison, assuming Dan was cool with it.

    Meanwhile, Uri Guttman offered his 'stillborn' bignum implementation as
    a basis for our own bignum library. Leo commented that it might be a
    good idea in the medium to long term, but the Pie-thon is looming...

    http://xrl.us/cbf7

    http://xrl.us/cbf8

  Ion's Strings
    Remember Ion Alexandru Morega's string pmc that got Warnocked? Well, it
    got un-Warnocked this week. Dan liked it, so he checked it in.
    Congratulations Ion, don't forget to send in a patch to the CREDITS
    file.

    http://xrl.us/cbf9

  Mmm... Pie-thon
    Dan reminded everyone of the URL of the benchmark that's going to be run
    for the Pie-thon. If Parrot doesn't run it faster than the C
    implementation of Python, then Dan's going to get a pie in the face and
    he'll have to spring for a round of drinks for the Python Cabal (is
    there one? Could be a cheap round...). Of course, the plan is to have
    Parrot be faster than Python so Dan'll get to chuck a Pie at Guido.
    Either way, if you're at OSCON this year it should be fun.

    Right now, Parrot is some way from, well, running it.

    Leo announced that he will start a series of postings discussing the
    main features (and requirements) of the various benchmarks. He started
    with some notes on b6.py.

    http://xrl.us/cbga

    http://xrl.us/cbgb -- Python needs exception objects

    http://xrl.us/cbgc -- Pie-thon and the recursion limit

  Class name hashes
    Leo wondered about the current implementation of class name hashes. We
    have two such hashes, one for PMC base classes and one for dynamic PMCs.
    Leo thought this was suboptimal (and liable to make one of the Pie-thon
    benchmarks problematic.) Dan agreed that unifying the hashes (and
    renaming PMC classes to have Parrot prefixes (ParrotFixedSizeArray
    anyone?)) was the way to go.

    http://xrl.us/cbgd

  Confusing parameter order
    Nicholas Clark was somewhat bemused by the choice of parameter order for
    the "Parrot_PMC_set_intval_intkey" function, which reverses the order of
    some parameters from the vtable version. He suggested unifying the two.
    Leo agreed that changing things round was the best bet and suggested
    that Nicholas go ahead and make the change to the extend.h interface.
    Dan didn't pipe up to say it was a bad idea. In fact, Dan didn't pipe up
    at all.

    http://xrl.us/cbge

  Perl 6 regex parser
    Jeff 'japhy' Pinyan announced that he was currently completing work on
    an extensible, regex-specific, parsing module. Once it's finished, he's
    going to start work on writing a subclass that parses Perl 6 rules. He
    thought it might come in handy for people implementing Perl 6.

    Luke Palmer thought it would be too; the grammar of Perl 6 is being
    specified in Perl 6 patterns. Initially it was hoped that Damian's
    Perl6::Rules module would be what was needed to bootstrap us, but
    'serious bugs in the Perl 5 regex engine having to do with executing
    code within regexes' meant that Perl6::Rules can't do the job for us.

    So, good luck Japhy, we're depending on you.

    But, you know, no pressure mate.

    http://xrl.us/cbgf

  Leo's tasks for the interested
    Leo asked for volunteers to implement a class to handle complex numbers
    (needed for Python) and to implement sort method(s) for the various
    *Array PMCs.

    http://xrl.us/cbgg

Meanwhile, in perl6-language
  Command line like switches for functions and operators
    Michele Dondi proposed syntax for adding 'command line' type switches to
    functions and methods which look almost, but not quite, entirely unlike
    Perl 6's named parameters. Brent Royal-Gordon pointed out that Michele's
    proposed

        rename -v => 1, $orig, $new;

    could be written, rather more Perl6ishly as:

        rename $orig, $new :verbose;

    Luke Palmer pointed out that wrappers could be used to add such extra
    named arguments to built ins, so the proposed behaviour for "rename"
    could be implemented as:

        &*rename.wrap -> $orig, $new, *%opt {
            say "Renaming '$orig' to '$new'" if %opt{'verbose' | 'v'};
            call;
        }

    It turns out that neither of these were what Michele was driving at; it
    wasn't so much that new syntax was wanted, but that every built in have
    some kind of verbose version.

    Meanwhile, as the discussion drifted in typical perl6-language style,
    Larry talked about 'allowing (at least) a single closure parameter to
    come at the end after the list parameter'. Simon Cozens doesn't seem to
    be maintaining his Ruby-o-meter any more, but if Larry were to make this
    change, the needle would definitely swing further in Ruby's direction.

    http://xrl.us/cbgh

  User defined operators
    Michele Dondi wondered if Perl 6 would have a way of defining infix
    operators. Answer: Yes. The discussion pointed up some interesting
    scoping issues to do with macros too. But macros do that (as a look at
    any text on Common Lisp macros will show you).

    http://xrl.us/cbgi

  Definitions of truth
    Paul Hodges doesn't like the fact that a null character ("\0") is has a
    boolean 'true' value in Perl 5. He hoped that Perl 6 would change this.
    It appears his hopes are in vain. The consensus appeared to be that this
    kind of thinking is a (potentially) dangerous fossil from C type
    thinking. Jonadab the Unsightly One muttered something about 'comparing
    apples and orange leotards'.

    The actually discussion was a little more discursive, of course.

    http://xrl.us/cbgj

  Slicing
    Rod Adams wondered how hash slicing will work in 'the glorious age of
    Perl 6'.

    So do we all Rod. We hope it'll work really well. Apocalypse N will have
    detailed answers.

    http://xrl.us/cbgk

  Postfix modifiers
    The core Perl 6 language will allow one, and only one, postfix modifier
    per statement. Larry has said this several times. If you want more,
    modify the grammar yourself.

    If that was the last time I find myself having to say this before we get
    a Perl 6 beta then I'll gladly eat a hat at the appropriate OSCON. You
    can hold me to this (but you'll have to pay my travelling expenses).

  The ".bytes"/".codepoints"/".graphemes" methods
    Argh! Unicode! But for once it's not moaning about Unicode operators, so
    that's a result.

    Brent Royal-Gordon wondered about the behaviour of the ".bytes",
    ".codepoints", and ".graphemes" methods on the String object. He
    suggested that, in a list context, they return a list of the appropriate
    things in the string. Larry looked upon Brent's proposal and saw that it
    was good.

    http://xrl.us/cbgm

  "if", "loop" and lexical scope
    Alexey Trofimenko wondered about the lexical scoping rules associated
    with Perl 6's various control structures.

    If you're unsure about them yourself, Luke Palmer's reply is an
    excellent overview of how such scoping works and of some of the
    rationale behind it.

    http://xrl.us/cbgn

Announcements, Apologies, Acknowledgements
    Hopefully this summary marks a return to the good old days of weekly
    summaries, posted to the mailing lists near the beginning of the week.

    Well, we can always hope can't we?

    Apologies to those who read this on [EMAIL PROTECTED] for my
    foolish invention of the nonexistent [EMAIL PROTECTED] mailing
    list. Which is why I'm sending this again, but to the correct
    address.

    If you find these summaries useful or enjoyable, please consider
    contributing to the Perl Foundation to help support the development of
    Perl. You might also like to send me feedback at
    mailto:[EMAIL PROTECTED]

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

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

Reply via email to