The Perl 6 Summary for the fortnight ending 2005-11-13
    Welcome to another fortnight's worth of summary. We'll get back to a
    weekly schedule one of these fine days, you see if we don't.

This fortnight in perl6-compiler
    There was a surprisingly large amount of activity on the list, but
    again, the place to look for perl6 compiler news is the Planet Perl Six
    aggregator.

    <http://planetsix.perl.org/>

  PGE improvements and changes
    Patrick announced that he'd checked in some major changes to the PGE
    internals. The changes include a shiny new shift-reduce operator
    precedence parser which is used to parse the rules themselves. PGE
    finally has a "<p6rule>" parsing rule which can be used to parse a valid
    Perl 6 rule. There are other changes, but those two are the headlines.
    Patrick asked for the usual questions, comments, patches and tests.

    A couple of days later, he posted a more comprehensive overview of the
    new and shiny bits in PGE.

    <http://xrl.us/ifuy>

    <http://xrl.us/ifuz>

  PGE problem with non-greedy quantifiers
    Allison fell foul of some changes in the new PGE. This turned out to be
    a bug in PGE, so Patrick fixed it.

    <http://xrl.us/ifu2>

  The meaning of \n and \N
    Noting that Synopsis 5 says that '"\n" now matches a logical (platform
    independent) newline, not just "\012"', Patrick asked the list for more
    details about what that should mean so he could get on and implement it
    in PGE. He offered up a suggested matching rule. Larry thought that the
    suggested rule was close enough for jazz.

    <http://xrl.us/ifu3>

  "[]" and "()" on rule modifiers
    Patrick continues to work on the PGE. This time he asked about the
    behaviour of rule modifiers, with particular reference to the ":w"
    modifier. Larry had answers.

    <http://xrl.us/ifu4>

  Parrot 0.3.1 "Wart" released
    Leo announced the release of Parrot 0.3.1 "Wart", complete with shiny
    new features like variable sized register frames and no more spilling, a
    much better PGE (see above) and other goodies. The latest release has
    more than 3000 tests, and that's probably still not enough.

    <http://xrl.us/ifu5>

  Octal in p6rules (and strings)
    Patrick Continued his voyage of stringy discovery, this time asking
    about the black art of specifying glyphs/bytes/whatever using octal
    notation. He wondered about his assumption that the correct way to do it
    is with "\o123" by analogy with using "0o123" to specify a number in
    octal. He also wanted confirmation that the "\nnn" notation had been
    dropped. A surprisingly long discussion ensued as Larry did a good deal
    of thinking aloud and Patrick got on with implementing the nailed down
    bits.

    <http://xrl.us/ifu6>

Meanwhile, in perl6-internals
  SWIGging Parrot
    John Lenz is one of the developers a SWIG, which started off as the
    Python equivalent to Perl's XS. He had some questions about writing a
    SWIG module for parrot and asked if there would be interest in having
    SWIG be one of the 'official' ways of doing native calls from Parrot.
    Leo thought not, pointing out that Parrot's NCI is fully dynamic and
    groovy.

    <http://xrl.us/ifu7>

  NCI using ffcall library
    Garrett Goebel joined in the ongoing discussion of using ffcall to
    implement the Parrot NCI (Native Call Interface) by pointing back to an
    earlier discussion of using libffi to implement the Parrot NCI. Last
    time round, Dan had pointed out that, because libffi is an external
    library, there still needs to be a supported (if possibly hackish) way
    of doing NCI that comes with Parrot, but that configure could probe for
    external libraries to use where they are available.

    <http://xrl.us/ifu8>

  Heredocs in function calls
    Patrick wondered if there might be a convenient way to support heredoc
    parameters in PIR function calls. Nicholas Clark wondered why one would
    bother since most PIR code should be generated code.

    Later on, Leo implemented them. About the only place they don't work now
    is in macro arguments.

    <http://xrl.us/ifu9>

    <http://xrl.us/ifva>

  Simple register allocation
    Summarizing a discussion on IRC, Patrick noted that it would be nice if
    the PIR compiler had a way to use a very basic register allocation for
    .subs that only use a small number of registers. After all, there's
    little point in doing a complex analysis of control flow if a sub uses
    (say) 5 registers at most. The problem is that this analysis gets harder
    as the subs get longer (O(n) on the length of the sub). In the case of
    PGE (for instance), the subs can get very long, with lots of control
    flow statements, but use a maximum of 10 PMC, 9 int and 4 string
    registers for the whole thing.

    Warnock applies.

    <http://xrl.us/ifvb>

  Careful with that "bsr" Eugene
    Leo noted that, with the introduction of variable sized register frames,
    it is no longer legal to "bsr" into a different ".sub".

    <http://xrl.us/ifvc>

  Reconfiguring configure
    Joshua Hoblitt sketched out a route map for getting from our current
    'built to throw away' configuration system to the sunny uplands of the
    miniparrot based config system. Everyone who commented sounded positive.
    Now, if someone could just implement it...

    <http://xrl.us/ifvd>

  Shifting right by more than the width of int
    Joshua Isam had problems doing a right shift of more than the width of
    an integer. Which is no surprise really as the behaviour is officially
    undefined in the C spec, which is the implementation that Parrot uses.
    There was some discussion, but the consensus is that it's best to stick
    with the C semantics for integer registers and if the need arises for
    more complex semantics, it's always possible to write a new PMC.

    <http://xrl.us/ifve>

  Suspend and resume opcode
    Tomo sent in a patch implementing "suspend" and "resume" opcodes. After
    a certain amount of kerfuffle involving the mailing list software
    stripping troff attachments and dodgy software deciding that a .t file
    full of tests was actually a troff source, Leo rejected the patch and
    pointed Tomo in the direction of coroutines.

    The mailing list will now accept troff attachments. Hurrah.

    <http://xrl.us/ifvf>

  Creeping up on ffcall NCI
    Nick Glencross posted another update of his work on getting NCI to use
    the ffcall library. He's now added config smarts to detect the ffcall
    and other handy features.

    <http://xrl.us/ifvg>

  Removing unmaintained languages from parrot tree
    Jerry Gay noticed that there were an awful lot of unmaintained languages
    in the Parrot tree. He recommended getting in touch with their last
    known authors and eventually removing the dead languages.

    <http://xrl.us/ifvh>

  Testing non-core PIR libraries with Parrot::Test
    Allison outlined some of the problems she'd been having testing her tree
    transformation engines outside of the parrot tree. It turns out that
    Parrot or the Test tool require absolute paths to various libraries,
    which is no fun at all. She suggested fixing Parrot::Test up so as to
    try and divine (and set) a sensible load path for Parrot. Meanwhile,
    chromatic continues to beaver away at implementing Test::More in PIR.

    <http://xrl.us/ifvi>

  Updating parrotcode.org
    Will Coleda announced that he'd been doing some tidying up of the
    parrotcode.org website and asked for suggestions for an updated 'where
    we are' section. Various answers and suggestions were provided.

    <http://www.parrotcode.org/>

  "find_type" considered dubious
    Roger Browne was puzzled by the behaviour of the "find_type" opcode,
    which works for both PMC types and native Parrot types. He thought that
    this was both confusing and counter productive. Leo didn't seem to agree
    with him.

    <http://xrl.us/ifvj>

  Unicode strings and encodings
    Leo announced that he's going through the various string functions to
    make them usable with all the string encodings we know about. He
    outlined what he proposed to do solicited comments in case of insanity.

    <http://xrl.us/ifvk>

  Legal names for PMCS
    Roger Browne (whose name I keep wanting to use as a Clerihew) wondered
    what the rules were for naming PMCs. Leo reckoned that, unless someone
    rejigs pmc2c.pl to mangle non word characters appropriately, a PMC name
    should follow the same rules as C identifiers.

    <http://xrl.us/ifvm>

  "string_bitwise_*"
    Noting that, with ICU installed, parrot has 'rather complete support for
    Unicode string manipulation', Leo wondered about making the bitwise
    string manipulations work. In particularly, he wondered how they should
    behave in the face of charset and/or encoding mismatches. According to
    Leo, it seems to boil down to a choice between throwing an exception or
    simply mashing everything together and marking the 'resulting bit mess'
    as binary. Warnock applies.

    <http://xrl.us/ifvn>

  Parrot fink
    Will Coleda passed on a query from the #parrot irc channel. Someone had
    wondered if there was a Fink build of Parrot available. (Fink is an OS X
    open source package manager along the lines of, well, pretty much every
    other package manager). There isn't, so Will wondered if there was
    anyone on the list who could help put one together. Leo noted that
    Parrot is already Debianized (yay!) which might help with the fink
    approach too. Joshua Isam worked on the task.

    <http://xrl.us/ifvo>

  Changing default STDOUT/STDERR Filehandles for PIR code
    One of the things that chromatic needs in order to write a pure PIR
    version of Parrot::Test is a way to redirect STDOUT and STDERR within a
    section of PIR code. He's looked at the implementation of the ParrotIO
    PMC and the print opcode, but can't see where to begin. So, he asked for
    help. At close of play on Sunday there had been no answer, but I'm sure
    someone will be along soon.

    <http://xrl.us/ifvp>

  PDD20: An idea: Call frames as PMCs
    Chip led the applause for Leo's implementation of the new lexical scheme
    in all of a week. He then went on to outline an idea for turning call
    frames into PMCs. Leo wasn't sure, pointing out that the call frame
    would have the same issues as promoting a continuation. I have to
    confess that I'd tended to assume that the PMC that Chip's proposing
    already exists, and it's called a continuation.

    <http://xrl.us/ifvq>

  ":outer("foo")" is working
    Leo announced that ":outer("foo")" now works, with a couple of caveats.

    <http://xrl.us/ifvr>

Meanwhile, in perl6-language
  Ways to add behaviour
    The problem with summarizing an ongoing thread that you've not really
    been following is getting the context again. I have to confess that,
    when I returned to the 'Ways to add behaviour' thread this week I was
    somewhat stumped. Thomas Sandlass and Larry appeared to be having fun
    with terminology and type algebra. I'm sure that we'll end up with a
    more robust language as a result of all this, but it doesn't mean I
    could follow the discussion as it was happening.

    <http://xrl.us/ifvs>

  $_ defaulting for mutating ops
    Remember last time? Juerd had proposed that mutating ops like "++"
    default to mutating $_ in the absence of a left hand argument. It seems
    that the discussion convinced Juerd that it wasn't a good idea after
    all. But, this being perl6-language, it also seemed to convince others
    that it is a good idea.

    <http://xrl.us/ifvt>

  Role method conflicts and disambiguation
    Discussion of how to handle conflicting role methods and their
    disambiguation continued. Unless I'm going soft in the head, I could
    have sworn that the original Smalltalk 'Traits' paper (they're called
    Roles in Perl 6 because we already have Traits) dealt with
    disambiguation in a fairly straightforward fashion. I continue to be
    reminded of the same joke as last week.

    <http://xrl.us/ifvu>

  Co/contra variance of roles/factories in theory.pod
    Err... I haven't the faintest idea what Luke and Thomas Sandlass are
    talking about here. Luckily, it seems that Larry did understand it.

    <http://xrl.us/ifvv>

  Perl 6 perlplexities
    Michele Dondi worries that the increase in complexity of some aspects of
    Perl 6 is much bigger than the increase in functionality that the
    complexity buys us. In particular Michele is concerned that the Perl 6
    parameter passing and signature stuff is going to be a big loss. People
    mostly disagreed with him. Rob Kinyon made a remark that chimed strongly
    with me, pointing out that Ruby's OO system is substantially more
    complex than Perl 5's, but that it's also a great deal easier to use.
    (Rob's not alone in this, I am writing most of my new OO code in Ruby. I
    fully expect to switch back to Perl 6 as soon as it becomes good enough
    though).

    Lots of good discussion here. I was convinced once again that Perl 6's
    signatures are going to be the best thing since sliced bread. Even if I
    do still like Smalltalk method selectors best of all.

    <http://xrl.us/ifvw>

  Implicitly doing a role
    If a tree falls in a forest with no one to hear it, does it make a
    sound? If a class implements the same interface as a role without saying
    that it does, does it still do the role? One of these philosophical
    questions was asked by Austin Frank. The other is a timeless wossname.
    Can you guess which is which?

    Rob Kinyon thought that the answer to the second question was 'no'. So
    did chromatic, citing the usual Dog/Tree problem with 'bark'. After
    further thought, chromatic proposed that a class *should* create an
    implicit empty role of the same name to make things easy for people
    writing mock objects and other entertainingly different variants of the
    original class.

    Decorated Dog anyone?

    <http://xrl.us/ifvx>

  The new class sigil
    Remember when the new class sigil was going to be ¢? Well, we're still
    getting one, but it's called ^ now. I think.

    <http://xrl.us/ifvy>

  Private methods and role composition
    Jonathan Lang wondered if there was a way of declaring a method as
    private to a role, and a role could reclassify a composed method as
    private. Larry answered 'yes' to the first question and 'no' to the
    second.

    <http://xrl.us/ifvz>

  "=>"'s container and binding semantics
    Ingo Blechschmidt had some questions about modifying pair keys and
    values and about the semantics of binding to a pair value. Larry had
    answers. And interesting implicit questions.

    <http://xrl.us/ifv2>

  Default values for instance variables
    Gaal Yahas thinks it'd be nice to supply default values to instance
    variables at declaration time. Luke pointed out that it is actually
    legal to do just that in Perl 6, but that pugs doesn't yet implement it.

    <http://xrl.us/ifv3>

  Proposal: rename 'subtype' declarator to 'set'
    Undeterred by the fact that the OED has eight distinct headword entries
    for 'set', covering four different parts of speech and a prefix form,
    Thomas Sandlass proposed changing the "subtype" declarator to "set".
    Larry agreed that it might be a way forward, but worried about
    interference between the declarative form and the verb 'to set'. Stuart
    Cook thought that 'subset' might be slightly less confusing, but Eric
    the Surnameless thought that that would be more confusing.

    <http://xrl.us/ifv4>

  Test case: Complex numbers
    Jonathan Lang posted a skeleton implementation of complex numbers and
    their associated arithmetic to the list as a possible test case of
    various Perl 6 goodies. Luke and Larry both offered comments and
    suggestions.

    <http://xrl.us/ifv5>

  Given too little
    Gaal Yahas seems to have found a possible bug in pugs when using "when"
    with an expression that returns a boolean. It turns out that this might
    be a bug in the spec. Getting the semantics of "~~" nailed down so that
    "when" always does the Right Thing is Hard. Larry's working on it. One
    fix seems to be to shove the conditional code into a block. The block is
    then evaluated (possibly with the $_ as an argument) and "~~" returns
    true if the block returns true.

    <http://xrl.us/ifv6>

  What's the latest on Iterators
    Joe Gottman is worried that the various synopses make plenty of
    references to Iterators, but that Iterators aren't actually defined
    anywhere. He asked for clarification. Larry supplied some, and, after
    some prompting from Stéphane Payrard declared that Perl 6's would do
    lazy evaluation by default, would guarantee some kind left to right
    evaluation, and that, if all else failed the "**" steamroller would make
    things eager again.

    <http://xrl.us/ifv8>

Acknowledgements, apologies and everything else
    Matt Fowles was on holiday last week, and didn't have time to write a
    summary. Hopefully he was having a fabulous time instead. We hope to be
    back on a weekly schedule from next week.

    Thanks to the people who contacted me last week. I am still looking for
    work, but I also have some leads to follow up on, which is a start. The
    summaries are still looking for a sponsor though; if you're interested
    drop me or Matt a line, we'd be delighted to hear from you.

  Help Chip
    <http://geeksunite.org/> -- Chip still needs help.

  The usual coda
    If you find these summaries useful or enjoyable, please consider
    contributing to the Perl Foundation to help support the development of
    Perl.

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

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

    Check out my website, it's lovely.

    <http://www.bofh.org.uk/>

    Vaguely pretty photos by me can be found at:

    <http://xrl.us/ifv9>

-- 
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/

Reply via email to