Perl 6 Summary

This week on Perl 6 ~(24-30 June 2002)
    By Piers Cawley, 020020702

  Notes

    Experimenting with a slightly different format this week (theft from
    NTKnow considered sensible...), I'll also be looking at some of the
    things that've been posted on use.perl.org (and I'd really appreciate
    some reports on the YAPC Perl6 chats from those who were there, so I can
    summarize them for the next issue or as an appendix to this one).

  System calls/spawning new processes

    A newbie seemed somewhat confused about the purpose of the
    perl6-language list and asked about spawning subprocesses... in Perl 5.
    Mark J Read demonstrated admirable tact and diplomacy in both pointing
    the newcomer at a better place to ask (perl-beginners@perl.org, a
    *great* mailing list) *and* providing some pointers toward an answer.

    The only reason this particular episode made the summary, by the
    way, is because of its rareity. I've been generally impressed by
    the 'on topicness' of the perl6-* lists. I hope it stays that way
    for a long time to come.

    Mailing list urls omitted to protect the innocent.

  Ruby iterators

    Ruby interators were the subject of Erik Steven Harrison's post, which
    also referred to 'pass by name' and 'the Jensen Machine', and wanted to
    know 'the Perl 6 stance on the matter'. Nobody has yet stepped up to the
    plate on this one and, speaking personally, I'm not entirely sure I've
    understood the question.

    http://archive.develooper.com/perl6-language@perl.org/msg10175.html has
    the whole question

  Fun with the Perl 6 Grammar.

    Sean O'Rourke asked us to "disregard my past shoddy attempt at a Perl 6
    grammar" and presented "a larger one that appears to capture much more
    of the syntax found in Apocalypses and Exegeses 1 - 4 (5 just scares
    me)." He promises bugs and missing elements, but still earns hero points
    from me.

    Later in the week, Dan asked how the perl 6 grammar was going and Ashley
    Winters responded that he isn't working on a grammar, but posted a list
    of variable forms (and a couple of other awkward constructs) with which
    he'd be testing each grammar. I particularly liked the last three
    entries in his list:

       ...
       # As a final sanity check, let's chain these things

       @.proc[$*PID].ps.{RSS};
       @proc.[$*PID].ps().{RSS};

       # And, just to make sure your parser doesn't pass this suite

       $foo{"Do you want to try $interpolated{"string"}?"};

    Sean O'Rourke responded with some comments on the legality of some of
    the examples, and offered his own "*@$*foo", a flattened, dereferenced,
    global "$foo", he thinks (and I concur). (Ooh... I just had a bad
    thought. @foo^.(), AFAICT it's the same as "map $_.(), @foo", but a good
    deal more evil).

    There was also some talk of overriding "[]" on hashes and "{}" on arrays
    to do surprising things. Personally, I reckon if you're going to do
    perverse stuff like that then you should add some rules to the grammar
    to make it legal, as well as writing the tie magic (or its perl 6
    equivalent), but laziness meant I didn't post that to the list.

    Oh yes. John Porter suggested that 'maybe Damian should write [the
    grammar]?'. Which leads me to postulate an analog to Godwin's Law,
    tailored to the perl 6 process, stating that at some point in any thread
    about the perl 6 language, someone will suggest that Damian do it. Or
    maybe Damian *will* do it. After all, Reports from YAPC seem to imply
    that he's come up with a cunning way of doing things in zero time (but
    I'm assuming he uses lots of space to compensate).

    This thread kicks off at
    http://archive.develooper.com/perl6-internals@perl.org/msg10705.html.

    Sean O'Rourke's parser is at
    http://archive.develooper.com/perl6-internals@perl.org/msg10692.html.

  The increasingly misnamed 'Perl5 humor' thread.

    Particulary, the branch that should be titled 'Porting XS modules to
    Parrot' rumbled on, mostly discussing how one would do it without
    implementing the entire perl 5 virtual machine on top of Parrot, with a
    small digression about achieving flight if you waved your hands fast
    enough.

    Dan, as usual, applied the scalpel very neatly. "Parrot's not going to
    have XS as an interface--that'd be insane", proposing instead an 80/20
    type solution and suggested that "If someone wants to start a list of
    *sensible* entries in perl 5's API that should be provided, we can work
    from there". Tim Bunce suggested starting "with a perl script that reads
    extension source code ... and spits out details of what perlapi/guts
    have been used", feeding it a bunch of popular extensions, and then
    profiling the results.

    The implementation of such a tool was left as an exercise for the
    interested reader.

    Dave Goehrig appears to have been that interested reader as he kicked
    off the 'Possibility of XS support' thread. He took at look at some
    sample XS based modules and reckoned that getting a minimal core of XS
    up would need about 50 functions to be ported. Dan thought that would be
    cool (no surprise there then, it *would* be cool) and Dave (the star)
    set off implementing an extension API for parrot. Dave also pointed at
    the Python and Ruby extension mechanisms as examples of good solutions
    to the general problem. Dan told us that he's "trying to kate the line
    between exposing the semantics of the internals and the actual
    internals." and commented that the semantics of what XS does are fine,
    but that the syntax is horrible. He also made it clear that any XS
    compatibility layer would live outside the Parrot core.

    See:
    http://archive.develooper.com/perl6-internals@perl.org/msg10672.html for
    the application of the scalpel.

    http://archive.develooper.com/perl6-internals@perl.org/msg10671.html has
    the start of the 'Possibility of XS support' thread. It's all worth
    reading.

  Stack performance

    Tom Hughes posted a patch to the stack code. His test figures are
    impressive: No overflow Overflow Integer stack, before patch 0.065505s
    16.589480s Integer stack, after patch 0.062732s 0.068460s Generic stack,
    before patch 0.161202s 5.475367s Generic stack, after patch 0.166938s
    0.168390s

    The test programs "push and pop 65536 times with the first column being
    when that loop doesn't cross a chunk boundary and the second being when
    it does cross a chunk boundary".

    Dan was impressed, and subject to a couple of caveats, it looks like the
    patch will be accepted.

    http://archive.develooper.com/perl6-internals@perl.org/msg10704.html has
    the patch.

  Small stuff

    http://archive.develooper.com/perl6-internals@perl.org/msg10703.html Dan
    added a "find_type" op to make working with non core PMC types much
    easier (no more modifying the assembler code every time...) And a
    "lookback" op for inspecting the user stack (in type safe fashion).

    http://archive.develooper.com/perl6-internals@perl.org/msg10682.html:
    Dan also took advantage of the new, mutable strings to write a
    "string_append" op, and doctored copre.ops to use it for "concat Sx, Sy"
    where x is both source and destination. The phrase "Order of magnitude
    or two" was used, so that's probably good then.

    http://archive.develooper.com/perl6-internals@perl.org/msg10702.html:
    Brian Wheeler gave us the "typeof op which returns the integer type or
    string type of a PMC." (Thanks. Applied. -- Dan)

    http://archive.develooper.com/perl6-internals@perl.org/msg10701.html:
    Simon Glover offers "more extensive tests for the mul_p_p op."

    http://archive.develooper.com/perl6-internals@perl.org/msg10700.html:
    Eric Kidder provided a "list of all the opcodes [...] that are not
    documented in docs/pdds/pdd06_pasm.pod", and a list of all the opcodes
    that are documented but not implemented.

    Peter Cooper pointed to his review of "Virtual Machine Implementation in
    C/C++", available at http://makeashorterlink.com/?T2EA32221

    http://archive.develooper.com/perl6-internals@perl.org/msg10708.html
    Leon Brocard offers a patch to escape strings when tracing.

    Leon also offers
    http://archive.develooper.com/perl6-internals@perl.org/msg10709.html,
    the latest version of his bravura mandelbrot set generator written in
    Parrot.

  Meanwhile, away from the mailing lists...

    Dan said in his use.perl.org journal that "Damian's [YAS/Perl
    Foundation] grant is up now, and not coming back. Mine ends the end of
    July, and barring a miracle (which means we gather more than $60K before
    the end of July), is also not being extended. A chunk of what's left is
    going to hire a professional grant writer, with everything after, up to
    $40K, going to fund Larry."

    I'd like to extend my heartfelt thanks and best wishes to Damian for the
    work he's done for Perl 6. Whilst the more visible parts of the work
    he's done have been *jeux d'esprits*b like Lingua::Romana::Perligata,
    Acme::Bleach and the scary talks like Time::Space::Continuum or whatever
    it's called, it's also apparent that the work that's gone on behind the
    scenes to help Larry make perl 6 be the best it can be has been
    unceasing, and his Exegeses have often been masterful examples of how to
    explain tricky concepts with clarity.

    Dan's work for Perl 6 has been more visible more often. Parrot is
    looking good, in large part because of Dan's efforts as programmer and
    project manager. Personally, I hope the miracle happens; having Dan full
    time can only be a good thing.

    http://use.perl.org/~Elian/journal/6101

  Colophon

    I'm not getting paid for this, and I don't particularly *want* to get
    paid for it. But if you find the summaries useful, please, please give
    some money to the Perl Foundation to support the ongoing design and
    development of Perl 6 and Parrot.



-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

• Perl 6 Summary by pdcawley