This Week's Summary

The Perl 6 Summary for the week ending 20030511
    PEPPERPOT 1: Ooh look! It's another Perl 6 summary!

    PEPPERPOT 2: Well I never did! What's in it this week?

    PP 1: Ooh, I don't know. Shall we have a look?

    PP 2: Ooh yes.

    Following a convoluted animation sequence involving surreality, fig
    leaves, classical statuary, and a cardboard cutout of an orange Leon
    Brocard, the camera pulls back to reveal a large bearded man, sat in a
    leather chair with a huge Apple PowerBook on his lap. PIERS looks from
    the screen to the camera and says

    PIERS: I never wanted to be a summary writer. I wanted to be a
    lumberjack, leaping from tree to tree as they float down the mighty
    rivers of Briti... Ah... *ahem*.

    PIERS comes to a stammering stop as he realises that quoting Python is
    *so* 20 years ago and that this year all the cool London.pm kids are
    quoting *Buffy the Vampire Slayer* instead.

    Anyhoo.

    As you may have gathered from the above introduction, it's been fairly
    quiet this week. However, design, development and discussion continues.
    As usual we'll start with perl6-internals.

  Long option Processing
    Towards the end of April, Luke Palmer had posted a patch implementing a
    long option processing subsystem for Parrot. After wondering if
    "getopt_long" was a standard function (it isn't), Steve Fink applied the
    patch.

    <http://xrl.us/hh8>

  Excessive memory usage?
    Leo Tötsch responded to Peter Gibbs' question of the week before about
    Parrot's apparently excessive memory use for a simple program. Leo and
    Peter batted the issue back and forth a few times in the process of
    tracking down the source of the problem. I think they got to the root of
    the problem, but I'm not sure if they've worked out a fix just yet.

    <http://xrl.us/hvq>

  NCI and handling of generic buffers of stuff
    Last week Clinton A. Pierce had wondered about allocating blocks of
    'generic' memory within Parrot for use as targets for native functions
    (in his case for calling Win32 functions). Piers Cawley wondered if it
    wouldn't be possible to implement a scratch buffer PMC to manage such
    blocks of memory. Dan pointed out that this was exactly what the
    'unmanagedstruct' PMC type was intended for, but Clint wasn't sure that
    this did quite what he wanted and asked for more advice.

    Later in the week Clint announced that he'd got UnManagedStruct PMCs
    doing some useful work, including allocating arbitrarily sized buffers
    from parrot assembly. People were impressed (In fact, Dan went so far
    as to call Clint his hero in his 'Squawks of the Parrot'
    weblog). However, Leo Tötsch pointed out that a good deal of the work
    that Clint had done on UnManagedStruct probably belonged on
    ManagedStruct instead.  Apparently Clint (and Dan) hadn't noticed that
    ManagedStruct existed. Hopefully now he's had it pointed out to him,
    things will become a little more logical.

    <http://xrl.us/hid>

    <http://xrl.us/hvr>

    <http://xrl.us/hvs>

  Calling convention changes
    After Dan's last set of changes to the Parrot calling conventions, Brent
    Dax wondered why we still had a user stack now that it was no longer
    being used for argument passing. Klaas-Jan Stol reckoned it was still
    useful and it would make targetting Parrot easier. Luke Palmer wondered
    if the user stack wouldn't make it harder to implement an exception
    system.

    Interestingly, Dan seems to be toying with having Parrot use
    Continuation Passing Style function calls at some point in the future.
    Who knows, maybe the next final calling conventions will mandate CPS (I
    confess, I rather like the idea myself...)

    <http://xrl.us/hvt>

    <http://xrl.us/hvu>

  Building Parrot on windows
    Getting Parrot working well in a Win32 environment seems to have been a
    Parrot theme over the last few weeks. This week Cal Henderson popped up
    with some problems getting things to link. The problem was tracked down
    quite quickly, and Cal ended up offering to do regular windows builds
    for the tinderbox system, though it looks like that's not yet as easy as
    it could be. Apparently the standard Win32 make targets don't quite
    build enough. I'm sure someone's working on fixing this; getting Win32
    into the tinderbox will be really handy.

    <http://xrl.us/hvv>

  IMCC vs. Parrot assembler

    Zellyn Hunter wondered about how to choose between IMCC and the native
    parrot assembler. (Zellyn also presented me with a dilemma about which
    personal pronoun to use, which I solved by going and looking at his
    website. Unless 'Leah' turns out to be a chap's name I think I'm
    safe). He also asked about the state of the documentation within CVS,
    and wondered which documents were still valid and which (if any) had
    been caught out by the march of development, suggesting a small meta
    document with information on the validity of the various docs (which
    begs the question of how one knows that the metadoc is up to date.)

    The answer to the first question was "Well, it depends", with the rider
    that, unless you enjoyed doing your own register allocation, IMCC looked
    like the saner choice. Jerome Quelin pointed out that the Ook! compiler
    targets PASM, which seems to be in agreement with the whole sane/unsane
    thing.

    <http://xrl.us/hvw>

  More on stack walking
    David Robins read Dan's blog entry about stack walking and had a few
    questions about the details. He wanted to know what was done about false
    positives (ie, how do you *know* that something that looks like a
    pointer *is* a pointer), and what was done about object destruction. Dan
    replied that, in one of the Parrot GC system's few conservative choices,
    Parrot GC took the view that if something in the system stack looks like
    a pointer then it's safest to assume that it is a pointer and proceed on
    that basis. He also noted that, if a language required a specific order
    of object destruction then it was down to the language to handle that.

    The usual spectre of timely closure of IO handles was raised again --
    Perl 5 guarantees that objects get destroyed (and therefore handles get
    closed) as soon as an object goes out of scope. This is somewhat harder
    to guarantee in a system that doesn't use reference counting for
    garbage collection. Graham Barr commented that "Anyone who depends on
    GC for the closing of file handles asks for all they get.", which is
    certainly one way of approaching the issue, but it does rather fly in
    the face of the Perl 5 Way.

    <http://xrl.us/hvx>

    <http://xrl.us/hif> -- Dan explains stack walking

  PIO work
    Jürgen Bömmels continued his sterling work on the Parrot IO system
    (PIO), fixing up the problems with buffering and double frees etc that
    were mentioned last week.

  "sysinfo" op
    Dan added a "sysinfo" op which allows a running program to at least get
    some information about the machine it's running on. Things are
    apparently somewhat spotty for various architectures that Dan didn't
    have immediate access to, but there's a framework in place now and
    patches are welcome.

    <http://xrl.us/hvy>

Meanwhile in perl6-language
    The language list was again busier than the internals list this week,
    but only just. Maybe we're all waiting with bated breath for the next
    exegesis. Or maybe everyone's exhausted. It can't last though.

  "bool" Type
    Discussion of the hypothetical/non-existent "bool" type continued. I
    tried really hard to care.

  Coroutine calling convention
    As Luke Palmer continued to argue that Coroutines were a
    useless/dangerous bit of syntactic sugar and we'd be better using
    explicit iterator objects. Meanwhile, others discussed the various
    options for calling semantics in the case where Coroutines continued to
    look like coroutines instead of iterators. Damian Conway proposed
    another form of Coroutine calling convention. Damian proposed that
    "yield" return the 'new' arguments with which you 'resumed' the
    coroutine. This gives the programmer the option to handle different
    arguments however she likes. Piers Cawley liked the idea and posted a
    few snippets of code for implementing these semantics using
    continuations. He also suggested that it might be handy to be able to
    declare 'Blocklike' subroutines that were 'return transparent'. I think
    the continuations scared people off because there has been no comment,
    even on the Blocklike subs idea.

    <http://groups.google.com/groups?threadm=ygcvfwtici9.fsf%40babylonia.fla
    tirons.org>

    <http://xrl.us/hvz> -- Damian's proposal

  Include macro
    Uri Guttman, may his name be forever mispronounced, responded to last
    week's summary (instead of the original thread, *bad* Uri!) by pointing
    out that the simple minded include macro referred to in that summary was
    inefficient and proposed an optimization. This turned into a discussion
    of whether file reads should be 'slurpy' by default (Michael Lazzaro
    thought they should be, almost everyone else disagreed with him).

    Then Damian popped up with his proposed Grand Unification of HERE docs,
    POD, and general file slurping, which looks very cool, but
    unfortunately, the unary "<<" operator that Damian proposes to hang all
    this off seems to clash with Larry's proposed use of " <<list of
    words>>" as a replacement for "qw/.../". The idea was well received, and
    people started casting around for a sensible operator and adding other
    neat ideas to go with it. Damian won the 'evil, evil, evil' prize when,
    after "<<<" had been proposed as the file slurp operator, he came up
    with the idea of vectorizing it, which would lead to such delights as

        my($stdout, $stderr) = >><<<<< open 'grep foo * |';

    Or, for the avoidance of headaches:

        my($stdout, $stderr) = >> <<< << open 'grep foo * |';

    (I hate to think how one would write that in a POD C<...> escape).

    This then turned into a discussion of whether "<<...>>" made sense as a
    replacement for "qw<...>", especially given the perceived utility of
    Damian's proposal.

    Towards the end of the thread, Michael Lazzaro withdrew his contention
    that slurpy reads should be the default.

    <http://xrl.us/hv2>

    <http://xrl.us/hv3> -- Conway's Unified Here Theory

Acknowledgements, Announcements and Apologies
    The camera pulls back from observing a computer screen on which the
    words "The camera pulls back from..." are being typed and swings around
    to focus on the typist who looks up from the screen and addresses the
    camera.

    PIERS: And so, by some extraordinary coincidence, fate, it seemed, had
    decided that you, my readers, should keep your appointment with the end
    of this summary. But what of the new technologies that had been spoken
    of?

    AUDIENCE: Where *BLEEP*?

    PIERS: In an empty house?

    AUDIENCE: When *BLEEP*?

    PIERS: In the middle of the night?

    AUDIENCE: Best time!

    PIERS: What diabolical plan had been shaped by Damian and Larry's crazed
    imaginations? What indeed? From what had gone before it was clear that
    this was going to be...

    AUDIENCE: a picnic?

    PIERS: no picnic.

    AUDIENCE: Awwwww!

    The lights dim, the screen fades to white and the following words scroll
    up the screens of browsers the world over:

    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 better framing device than terrible pastiches of Monty Python
        and the Rocky Horror Show to [email protected]. People
        suggesting an MST3K version of this summary can jolly well do it
        themselves.


-- 
Piers