This week's summary

The Perl 6 Summary for the week ending 20030504
    Welcome my friends, to the show that never ends. Yes, another week,
    another Perl 6 Summary, chock full of condensed goodness, Leo Tötsch
    admiration and a smattering information about the design and development
    of Perl 6 and its target virtual machine, Parrot.

    A quiet week this week. Even the hotbed of discussion that is
    perl6-language saw fewer than 100 messages. However, in accordance with
    tradition, I'll start with perl6-internals, which saw all of 47 messages
    this week, none of them from Leon Brocard.

  External Data Interfaces draft PDD
    Discussion of the External Data Interfaces PDD continues. Hopefully
    we'll see the first 'real' version soon.

  PMC Keys
    Alberto Simões asked for a good description of PMC Keys. No answer yet.

    <http://xrl.us/hh7>

  Long option processing
    Luke Palmer sent a patch to do long option parsing. Again, Warnock's
    Dilemma applies.

    <http://xrl.us/hh8>

  Problem with "readline"
    Will Coleda announced that he was dusting off his TCL project and found
    that it threw lots of bus errors. He tracked the problem down down to
    the "readline" op. Benjamin Goldberg realised that what was happening
    was that a filedescriptor was being used as a pointer to a FILE
    datastructure. Which is never going to be good. (This would never happen
    in a language with typed values. Well, it might, but the error would be
    caught before the bus error). No fix yet.

    <http://xrl.us/hh9>

  Read buffering in PIO
    Possibly prompted by Leon Brocard's nudge the week before, Dan Sugalski
    took another look at Jürgen Bömmels' rejected patch to add read
    buffering to the Parrot IO subsystem. Apparently there's a problem with
    a double free introduced by the patch. After some discussion (including
    a contribution from Melvin Smith, PIO's original author) of how to
    address the issue, Jürgen submitted another patch.

    <http://xrl.us/hia>

  Excessive memory usage?
    Peter Gibbs 'showed off' a short piece of PASM code that managed to use
    some 60Mb of memory and to allocate 1.5 million headers. He thought this
    a little excessive. No comment yet.

    <http://xrl.us/hib>

  Extending "pop"
    Klaas-Jan Stol wondered if it would be useful to have a variant of pop
    which could pop multiple items off the runtime stack. Dan thought it as
    a good idea and added a bunch more useful tricks involving stack marks
    and things, and asked for volunteers to implement it. Nobody has
    explicitly stepped up to that particular plate...

    <http://xrl.us/hic>

  Clint Pierce shows off his 'mad NCI skeelz'
    Clinton A Pierce has been playing with NCI on Win32 and has now got his
    Parrot BASIC calling Win32 functions natively. "Mua-hahahaha", as he so
    eloquently put it. He's now looking for a generic way to allocate a
    generic memory area in PASM for use as the target of a function, which
    should allow him to make even more Win32 calls without having to write
    an adaptor library in C first.

    <http://xrl.us/hid>

  Dan changes the calling conventions again.
    Dan released the final set of calling conventions again. He thinks he
    won't have to do this again. Again. The changes are all in PDD03
    (docs/pdds/pdd03_calling_conventions.pod in the CVS version of the
    Parrot distribution). The big change is that we no longer use the stack
    at all for passing parameters, we use an overflow array instead. The
    smaller change is that the PDD has been clarified somewhat.

    <http://xrl.us/hie>

    And that about wraps it up for the internals mailing list. However, Dan
    has been publishing some handy stuff in a new "What the heck is ...?"
    series on his 'Squawks of the Parrot' website.

    <http://xrl.us/hif> - Walking the stack

    <http://xrl.us/hig> - Coroutines

  Meanwhile, over in perl6-language
    There was lots more about types. And some new stuff too...

  "I thought there was no "bool" type?"
    Towards the end of last week, Smylers queried the 'bool' entries in the
    latest draft of Michael Lazzaro's Type Conversion Matrix. The thing is,
    Larry has said that there won't be boolean type. Smylers was not the
    first person to make this comment, he probably won't be the last. The
    stock response is along the lines of "There's no "bool" type, but there
    is "bool" context." but according to Synopsis 6, this appears not to be
    the case anymore.

    Then it all got a bit weird. Nobody *quite* asked "What is truth
    anyway?" but it was touch and go for a while as people discussed what
    the value of a "bool" would be in a numeric context. (I had a good deal
    of sympathy for the view that there should be some kind of warning...).
    We eventually ended up in a discussion of multistate logic (which, it
    seems to me is a candidate for 'something you implement in a module'
    status.), who knows where we'll end up this week.

    <http://xrl.us/hih>

  Headers
    Paul Hodges wondered if it would be possible to write something in Perl
    6 that worked in a similar way to the C Preprocessor's "#include"
    directive, allowing him to push a common set of "use" statements and
    other compile time declarations into a header file, which could then be
    shared by multiple bits of code. Various people suggested more or less
    tricky options, but Marco Baringer won the 'simplest thing that could
    possibly work' prize from your summarizer with:

        macro include ($file) {
          join '', <open $file>;
        }

    which does the job very straightforwardly.

    <http://xrl.us/hii>

  Type Conversion Matrix (Take 3)
    Michael Lazzaro posted his third attempt at a type conversion matrix.
    This triggered some discussion on the difference between primitive (int,
    float, etc) and 'full' types (Int, Float). Michael worried that some of
    the discussions were bloating primitives leading him to wonder what
    would be the point of using them if that happened.

    It's apparent from the discussions here that the distinction between
    storage and value types enables a good deal of magic, but that scares
    people too.

    <http://xrl.us/hij>

  Property Inheritance
    David Wheeler popped up with something of a head scratcher. He wanted to
    know whether, when a method is overridden in a subclass, the overridden
    method inherits the traits (he said properties, but he meant traits I
    think) of its SUPER method. Luke Palmer thought it probably depends on
    the trait, but his guess was that traits would be inherited. Which led
    David to wonder if that meant you could override traits in a child
    class.

    <http://xrl.us/hik>

  OO-overhead
    For some reason, a discussion on structuring OO code in Perl 5 has been
    running in perl6-language for a while. It's handy for spotting issues,
    but not exactly on topic. It is to be hoped that Perl 6 will lose a lot
    of Perl 5's function and method call overhead though.

  Chaining postconditionals
    Michael Lazzaro asked for the rationale behind disallowing stuff like:

        return if <expr> for <list>

    Short answer: Because Larry said so.

    Supporting evidence (from the thread that developed anyway):

        foo $_ if baz for @list unless quux.next() while 1;

    or:

        if $X {...} if $Y

    <http://xrl.us/hil>

  Coroutine calling convention
    Luke Palmer kicked off some discussion of the various coroutine calling
    conventions that Dan had discussed on his Squawks of the Parrot website.
    Luke though that coroutines should return iterator objects instead of
    the yielded value. Which would mean they weren't actually coroutines...

    <http://xrl.us/him>

    <http://xrl.us/hig> - Dan talks Coroutines

Acknowledgements, Announcements and Apologies
    So, another summary draws to a close on a glorious May afternoon. Here's
    to the next one. Thanks to those people who sent the proof I asked for
    in the last summary. No thanks to the gits who outnumbered them by
    sending spam to the same address.

    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 year's supply of Ben & Jerry's to [email protected]


-- 
Piers