The Perl 6 Summary for the week ending 20030209
    Welcome to the latest Perl 6 summary, your handy cut out and keep guide
    to the goings on in the crazy world of Perl 6 design and development.

    It's been a rather quiet week this week; only 75 messages in
    perl6-internals and a mere 57 in perl6-language. So, at least it's
    palindromic.

    We start off, as is traditional, with perl6-internals

  The 2004 Performance challenge
    Dan announced that he'd made a bet with Guido van Rossum that Parrot
    would be faster at executing a pure python benchmark of some sort to be
    determined. The details of the challenge will be announced at OSCON 2003
    and the results at OSCON 2004. Dan stands to lose $10 and a round of
    beer for the Zope/Pythonlabs folks. (Dunno how many of them there are
    though...). We don't know what he stands to win yet, but I'd hope 'beers
    from each of the Zope/Pythonlabs folks' are included.

    For some reason nobody commented on this.

    <http://makeashorterlink.com/?K2C815C63>

  More Parrot Objects
    Jerome Quelin wondered how Parrot objects would handle property
    inheritance. Dan pointed out that properties don't get inherited and
    Jerome realised he meant to ask about attribute inheritance. Attributes
    *are* inherited but are mostly invisible to any methods but the methods
    of the class that defines the attributes (though they will be accessible
    (presumably through reflection)).

    In another subthread, we got confused by multimethods.

    <http://makeashorterlink.com/?O6D816C63>

    <http://makeashorterlink.com/?O4E822C63> -- Multimethods

  Bytecode Metadata
    James Michael DuPont wanted to know what had been decided about Bytecode
    metadata and outlined the things that he'd like to know about a given
    bytecode. Leo Tötsch reckoned that what James wanted was either in the
    bytecode right now, or was handleable by the framework that was in
    place. He pointed James to docs/parrotbyte.pod in the Parrot
    distribution.

    Further discussions centred on the *amount* of metadata and whether this
    would affect loading speed and efficiency, or get in the way of the
    desired 'mmap and go' principle. Jürgen Bömmels pointed out that we also
    had to be capable of passing meta data from a compiler 'through' IMCC
    and on to the final bytecode. There was also a touching reunion between
    James Michael DuPont and Gopal V. Ah...

    <http://makeashorterlink.com/?E41925C63>

  Multi programming language questions
    Phil Hassey has been lurking, fascinated on the internals list for a
    couple of months. This week he broke the silence by asking a couple of
    questions about cross language function dispatch, string compatibility
    and global scopes. For instance, PHP, Common Lisp and others are case
    insensitive about functions. Which is okay when you're calling such a
    function from a case sensitive language, but can be tricky if you call
    out from a case insensitive to a case sensitive language. Dan thought
    that there wasn't going to be much that could be done about this problem
    (at least, not transparently) but seems to think that the other issues
    raised shouldn't be too problematic.

    <http://makeashorterlink.com/?R32931C63>

  Random questions
    David popped up and, after remarking on the amount of progress Parrot
    had made since he last looked at it, had a few questions about various
    bits and pieces. Leo and Dan provided a bunch of good answers.

    <http://makeashorterlink.com/?X63912C63>

  A Scheme for extending core.ops
    Leo Tötsch seems to have got bored of 'just' being the Patch Monster and
    has been producing some discussion documents proposing all sorts of
    useful tricks for improving the design/speed/extensibility of Parrot's
    internals. This week he turned his attention to core.ops. His plan
    involves a way of reducing the size of core_ops, improving cache
    locality and generally solving a raft of problems I didn't even know
    Parrot had. His new scheme allows for a small core.ops, easy extension
    and no execution speed penalty for non core ops. As is usual with Leo's
    stuff, the scheme came with code. Gregor had a bunch of observations and
    suggestions and he and Leo thrashed out a slightly modified scheme for
    going forward.

    <http://makeashorterlink.com/?P54921C63>

  Week of the alternative runloops
    Leo Tö offered a couple of different core runloops this week. First up
    was the Computed Goto Prederefed (CGP) runloop which, essentially
    combined a two runloop optimization techniques to provide what can only
    be described as massive speedups. The -O3 compiled version ran
    parrot_mops 6 times faster than the basic 'fast_core' and more than 3
    times faster than the previous fastest core. People were impressed.

    A few days later, Leo reached into his bag of tricks and pulled out the
    CSwitch runloop that did predereferenced dispatch via a big C switch
    statement. This loop is about 50% faster than the basic fast_core loop,
    but slower than all the computed goto dispatched loops. At this point
    Jason Gloudon pointed out that predereferencing can cause problems in a
    multi threaded environment.

    Quote of the Parrot development process so far:

    "I'm a really bad C programmer" -- Leo Tötsch

    <http://makeashorterlink.com/?R15942C63>

    And that about wraps it up for perl6-internals this week. Dan's been
    busy in Sebastapol with the Perl 6 Cabal thrashing out the design of
    Perl 6 functions and other bits with Larry, Damian, Allison and
    chromatic, which probably explains why he's not been driving the mailing
    list for the week.

Meanwhile in perl6-language
    It's been even quieter on the language list. Mostly interesting though.

  Shortcut "?="
    Miko O'Sullivan proposed a new assignment operator, "$var ?= $x : $y",
    equivalent to "$var = $var ? $x : $y". It was pointed out that, for
    correctness that should be "??=". Deborah Ariel Pickett wondered what
    was the need for such an operator and couldn't imagine ever needing such
    an operator.

    <http://makeashorterlink.com/?V26962C63>

  Language Discussion Summaries
    Miko O'Sullivan proposed that members of the language list provide
    summaries of the discussions in the group [What's this? Chopped liver?
    -- Ed]. The idea being that each summary would describe a proposed idea
    and then summarizes the list's feelings on the idea, and would be posted
    on a website. The idea was basically well received, then the list fell
    to quibbling about format, whether summaries should be posted to the
    list where they could be picked up by the list summarizer, and whether
    we were just reinventing RFCs all over again.

    As of now, the only summary that actually exists is Miko's summary of
    the proposed "??=" operator. Which I hadn't even bothered to read until
    I came to write the summary.

    <http://makeashorterlink.com/?T27923C63>

    <http://www.idocs.com/perl6/> -- Summaries website

  Newline as a statement terminator
    Stéphane Payrard confessed that he would like newline to be a statement
    terminator everywhere it can be. Everybody hated it. Deborah Ariel
    Pickett came up with a neat example of why it was a really bad idea with
    a simple ambiguous piece of code:

      sub foo 
      {
      print "abcde"
      if $condition
      {
      print "fghij"
      }
      }

    which could mean either:

      sub foo {
        print "abcdef" if $condition;
    
        return sub {
          print "fghij";
        }
      }

    Or

      sub foo {
        print "abcde";
        if $condition {
          print "fghij";
        }
      }

    And disambiguating with indentation is way too Pythonesque for many.

    <http://makeashorterlink.com/?L18921C63>

  Arrays vs. Lists
    In his quest to exhaustively document what is known about Perl so far,
    Michael Lazzaro asked for a definitive answer to the question "What's
    the difference between an array and a list in Perl 6"?

    Various answers were given but I think Uri Guttman came up with the most
    succinct pair of definitions, which reduce to 'lists are read only,
    arrays are read/write'. (That's the data structure itself, not the data
    structure's contents, "($a, $b) = (1, 2)" doesn't modify either list,
    but it does modify the lvalues in the left hand list).

    <http://makeashorterlink.com/?J49912C63>

    <http://makeashorterlink.com/?I1A923C63> -- Uri's definitions

Announcements, Acknowledgements and Trip Planning
    This week's summary was prepared in the comfy chair with distractions
    from cats, irc, former employers, bugs and poring over maps of the
    Eastern Seaboard.

    We're coming to America. This year, making a virtue out of a necessity
    we're going to give ourselves a good long holiday in the States. We'll
    be flying out to Boca Raton for YAPC, then taking a road trip up through
    the Appalachians to New England, possibly swinging into Canada before
    coming down through Michigan to Chicago and taking a slow train to
    Portland, OR for The Perl Conference. If it looks like you might be on
    our route, drop me a line...

    Proofreading services were provided by Aspell and me. (I could lie and
    say that they were provided by Leon Brocard, enabling me to work his
    name into the summary somehow, but I think I'll do it in a parenthetical
    comment instead.)

    If you 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, job offers or the secret of eternal
        immaturity to [EMAIL PROTECTED]

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


-- 
Piers

Reply via email to