The Perl 6 Summary for the week ending 20030601
    Another Monday, another Perl 6 Summary. Does this man never take a
    holiday? (Yes, but only to go to Perl conferences this year, how did
    that happen?)

    We start with the internals list as usual.

  More on timely destruction
    The discussion of how to get timely destruction with Parrot's Garbage
    Collection system continued. Last week Dan announced that, for languages
    that make commitments to call destructors as soon as a thing goes out of
    scope, there would be a set of helpful ops to allow languages to trigger
    conditional DOD (Dead Object Detection) runs at appropriate times.
    People weren't desperately keen on the performance hit that this entails
    (though the performance hit involved with reference counting is pretty
    substantial...) but we didn't manage to come up with a better solution
    to the issue.

    http://xrl.us/iu5

  Bryan C. Warnock, patchmonster of the week
    Bryan C. Warnock seems to be attempting to outdo Leo Tötsch in the
    patchmonster stakes this week. He put in a miscellany of patches dealing
    with the Perl based assembler, opcode sizes, debugging flags and
    probably others. Most of them were applied with alacrity.

  The Perl 6 Essentials book
    Dan Sugalski gave a rundown of how the Perl 6 Essentials book came
    about, what's in it and all that jazz. He started by apologizing for not
    mentioning it before, but he thought he had. This led Clint Pierce to
    wonder if there was something up with Dan's Garbage Collection system.
    The existence of the book probably goes some way to explaining Leo
    Tötsch's relative silence over the last few weeks. Nicholas Clark
    wondered if it explains why Parrot doesn't have objects yet. Brent Dax
    wondered when it would be available (by OSCON this year apparently).

    http://xrl.us/iu6

  IMCC, PASM and constants/macros
    Clint Pierce had some big headaches with moving his BASIC interpreter
    over to IMCC owing to problems with ".constant" which is legal for the
    assembler, but not for IMCC. Leo Tötsch pointed Clint at IMCC's ".const"
    operator. Bryan Warnock wondered if IMCC and the assembler's syntax
    couldn't be unified. Leo noted that it wasn't quite that straightforward
    because ".constant" declares an untyped constant, but ".const" requires
    a type as well. It turns out that ".const" wasn't quite what Clint
    needed, so Leo pointed him at ".sym" and ".local" which do seem to do
    what he needs.

    http://xrl.us/iu7

  3-arg opens
    Bryan Warnock wondered if

        open I3, "temp.file", "r"

    was valid code. Answer, no, the right way to do it is the Perlish "open
    I3, "temp.file", "<"". Jürgen Bömmels promised more and better
    documentation for the Parrot IO system. Eventually.

    http://xrl.us/iu8

  Smaller PMCs
    Leo Tötsch's work on the new PMC layout continues apace. I'm afraid I
    don't quite understand what's going on in this area, which does make it
    rather tricky to summarize things. It seems to have a good deal to do
    with memory allocation and garbage collection... Leo thinks that it's
    the right thing, but there seem to be issues involved with good ways of
    allocating zeroed memory.

    http://xrl.us/ijt

  An experimental Wiki for parrot development
    Mitchell N Charity has put up an experimental Wiki for Parrot and primed
    it with a few things. Stéphane Payrard pointed out that it's rather hard
    to make a WikiWord from, for example, PMC. (10 points to the first
    person to email [EMAIL PROTECTED] with the expansion of PMC).

    http://xrl.us/iu9

  IMCC packfile bug
    While toying with pbc2c.pl, Luke Palmer discovered that it doesn't want
    to play with IMCC generated .pbc files. Apparently this is because we
    currently have two bytecode file formats. Leo Tötsch thought the problem
    lay with assemble.pl which is old and slow and doesn't produce 'proper'
    parrot bytecode. Leo also thought that the way pbc2c.pl worked wasn't
    actually any use. Dan reckoned the time had come to ditch assemble.pl
    too, and reckoned there was a case for renaming IMCC as parrot since it
    can run either .pbc or assembly files. Leo liked the idea, but is
    concerned about the state of the Tinderbox.

    http://xrl.us/iva

  Method Calling
    Dan tantalized all those waiting eagerly for objects in Parrot by
    discussing how to make method calls. This, of course, means a few new
    ops, called "findmeth", "callmeth" and "callccmeth" for the time being.
    Jonathan Sillito had a few naming consistency issues with the ops. Dan
    agreed there were issues and asked for suggestions for an opcode naming
    convention.

    http://xrl.us/ivb

  Simple Constant Propagation in IMCC
    Matt Fowles posted a patch to add simple constant propagation to IMCC.
    Essentially this means that, say

        set I0, 5
        set I1, 2
        set I2, I1
        add I2, I0

    would compile as if it were:

        set I0, 5
        set I1, 2
        set I2, 7

    Leo Tötsch liked the idea modified it slightly and added it to the code
    base, but disabled. Apparently there are problems with it, but it's a
    good starting framework. There need to be lots more tests though...

    http://xrl.us/ivc

  Make mine SuperSized...
    Bryan Warnock (in his own words) popped in to 'waffle on Parrot's core
    sizes'. He proposed a way of drastically simplifying Parrot's type
    system. He and Gopal V had a long discussion that I didn't quite follow.
    I think Leo thinks that what Bryan proposes is doable, but I'm not
    entirely sure whether he thinks it's a good idea...

    http://xrl.us/ivd

  Register allocation in IMCC
    Clint Pierce had some problems with IMCC's register allocation. He
    posted an example that gave problems and wondered if the problem was
    with him or with IMCC. Leo Tötsch confirmed that it was a bug. Luke
    Palmer pointed Clint at "find_global" and friends as the 'correct' way
    to solve the problem. For bonus points, Clint showed of a pathological
    example of why BASIC should not be anyone's favourite language.

    http://xrl.us/ive

Meanwhile, in perl6-language
  Cothreads
    As if the Coroutine thread wasn't confusing enough, we now have the
    Cothread thread, in which Michael Lazzaro argued that we should blur the
    distinctions between coroutines and threads. Dave Whipp pointed everyone
    at 'Austin Hastings' draft for A17 (threads)' and argued that, whilst
    Coroutines, threads, closures, and various other things that Michael had
    argued were aspects of the same thing were related, they sufficiently
    different that bundling them all up behind a single class would lead to
    badness ("a bloated blob with a fat interface" was the phrase he used).

    This thread saw even more unrestrained speculation than usual and saw
    the first use on the Perl 6 lists of the adjective 'Cozeny', from Simon
    Cozens, possibly meaning "feeling that what is being discussed is over
    fussy and generally trying to take the language a *long* way from what
    Real Programmers need". This would seem to imply a verb form 'to Cozen',
    "To more or less forcibly express ones Cozeny feelings".

    I'm afraid this was another thread I had a hard time following. I reckon
    there's some interesting ideas in there, but I'm hoping that someone
    will pull it all together in an RFC type document so I can go "Remember
    that Cothreads thread last week? Leon Brocard summarized it all neatly
    in a single proposal, you can find it here." (Except it almost certainly
    won't be Leon Brocard, it'll be Mike Lazzaro, Leon doesn't seem to do
    perl6-language very much).

    http://xrl.us/ivf

    http://xrl.us/ivg -- Austin Hastings on threads

  Compile time binding
    In an effort to learn about Perl 6, Luke Palmer has been reading about
    Haskell. For reasons he doesn't understand, this set him to wondering
    what "::=" is supposed to mean -- it means 'compile time binding', but
    what does *that* mean?

    Damian Conway came through with the goods, summarizing his answer as
    "::=" is to ":=" as a macro call is to a subroutine call.

    http://xrl.us/ivh

  Threads and Progress Monitors
    Dave Whipp had some more thread questions, and wondered what would be a
    good Perl 6ish way of implementing a threaded progress monitor. Whilst
    the discussion of all this was interesting, I'm not sure that it's
    really much to do with the language, more something that one would
    implement according to taste and the particular requirements of a given
    project.

    http://xrl.us/ivi

  Exegesis 6 Status Update
    Damian announced that Exegesis six is mostly written, and should be
    undergoing final revisions while he and Larry are on the Perl Whirl.
    Hopefully we'll see the Exegesis before YAPC::America::North.

    http://xrl.us/ivj

Acknowledgements, Announcements and Apologies
    Thanks once again are due to all the good people on the Perl 6 lists.
    Apologies will almost certainly be due to the organizers of YAPC North
    America as I *still* haven't started writing the talks I'm supposed to
    be giving.

    As I noted last week, I'm awarding points (and points mean prizes) to
    those kind people who spotted the deliberate mistake. Smylers gets 100
    points for spotting the accidental mistake (last week was *not* in
    2004.) Sam Smith, David Wheeler, David Cantrell and Leon Brocard all
    earned 50 points for spotting the deliberate mistake of not mentioning
    Leon Brocard. But they've helped me make up for it this week by
    mentioning him twice, so the karmic balance is restored.

    The points I have awarded can be redeemed for the following, wonderful
    prizes:

    1   A lifetime subscription to the Perl 6 summaries.

    2   Er...

    3   That's it

    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 patches to Camelbones making it possible to make Perl classes
        that inherit from Objective C classes (heck, if Ruby and Python can
        do it) to [EMAIL PROTECTED]


-- 
Piers

Reply via email to