This week on Perl 6, week ending 2004-04-04

Wednesday? Why did I leave it 'til Wednesday to write the summary? I must have some reason. Or maybe not. I'll give fair warning that I won't be doing a summary for next week though, what with Easter and everything, but you'll get a fortnight's summary the week after, because I'm good to you like that.

We'll start this week's summary with perl6-internals.

MMD vtable functions in bytecode

Dan had announced that he was working on adding parrot bytecode support for multimethod dispatch, and outlined how they'd be used and got semi-Warnocked.

The discussion got going this week, Leo Tötsch was unsure about some of Dan's implementation choices. In particular, he wondered if MMD subs should use PMCs rather than the simple function pointer that Dan had used. Dan thought not.

http://groups.google.com/

Behaviour of PMCs on assignment

The discussion of what to do when assigning to PMCs continued. The issue is complicated because we are trying to be friendly to multiple languages (though, as far as I can tell, the really problematic issue is Perl Scalars; most of the other languages that spring to mind have variables that are 'simple' pointers to objects; Perl Scalars can hold (seemingly) a million and one different things, potentially all at once). TOGoS argued that, as things stand there's a disjunction between the way (say) integer registers work and the way PMC registers work. With Integer registers, if you do

    $I1 = $I2 + $I3

then $I1 gets a 'new' integer; there doesn't need to be a preexisting integer. However, if you were to do:

    $P1 = $P2 + $P3

what actually happens (assuming we're using straightforward PMCs here...) is more like:

    $P1.value = $P2 + $P3

In other words, you need a preexisting $P1. Leo agreed with TOGoS's argument, but worried that implementing it would blow core size up to an insane value. Dan didn't agree with TOGoS though, but I'm afraid I didn't quite follow his reasoning (probably because I'm being dumb this morning).

http://groups.google.com/

In which your Summarizer asks dumb questions

In an extended moment of stupidity, Piers Cawley asked why we had distinct register and user stacks. Leo explained it to him, very politely I thought.

http://groups.google.com/

Stalking the wily Garbage Collector bug

Jens Rieks's projet du jour -- an EBNF parser in Parrot -- tweaked a garbage collection bug so he posted appropriate debug traces and Leo set to work on it. He didn't get it working fully, but it takes longer to crash now (but it crashes in the same bit of C code). Jens thinks it's a problem with Parrot's handling of strings.

http://groups.google.com/

New SDL Parrot bindings underway

That stalwart of Portland.pm, chromatic, announced that he's in the process of porting the existing SDL Parrot bindings to use our shiny new Object system. Jens Rieks wondered why he was prefixing his method names with underscores (you only need underscores for globally visible functions, methods can have straightforward names). Tim Bunce wondered why chromatic wasn't using nested namespaces. Leo pointed out that nested namespaces haven't been implemented just yet.

http://groups.google.com/

Some new classes

Dan checked in some stub code for PMCArray and StringArray. Eventually they'll be auto-resizable, PMC or String only arrays, but right now they're simple wrappers for PerlArray. He suggested that rewriting them so they were real, efficient arrays would be a Good Thing (and, I suggest, a relatively gentle introduction to Parrot hacking if anyone reading this is interested.)

Jens Rieks offered up a patch for his data dumper so it could take them into account, which Dan applied.

http://groups.google.com/

Points of focus

Dan went all Managerial on our collective donkey and posted a nice bulletted list of things that need sorting out for a 0.1.1 release. The general thrust of the message is bug fixing and documenting, which is good.

http://groups.google.com/

Fun with non deterministic searches

One of the canonical illustrations of things to do with continuations is non deterministic searches. Imagine that you could write

    $x = choose(1,3,5,9)
    $y = choose(1,5,9,13)

    assert $x * $y == 15
    
    print "$x * $y == ", $x * $y, "\n"

and have "3 * 5 == 15" printed out. (Okay, so in Perl 6 you're going to be able to do that with junctions, but this is about an underlying implementation). Piers Cawley translated a simple non deterministic search algorithm from scheme to Parrot and posted the (initially failing) code to the list and pointed out that, even if he tweaked IMCC to generate full continuations instead of RetContinuations and turned of garbage collection, Parrot fell over with a bus error.

Once he'd explained how it worked (in a post made on April Fools' Day no less) and Leo had wrapped his head round it, the work went on to make it work. It turns out that Parrot had a few too many assumptions about how call stacks would work (starting with the assumption that you could simply reused a stack frame once you'd returned through it; in the presence of a full continuation you have to let stack frames be garbage collected). Leo fixed things so that you can now make a 'full' continuation simply by cloning the current continuation in P1 and there should only be a performance hit for the call chain that leads to the continuation (and that hit should be a one time cost you pay when cloning the continuation). Way to go Leo.

Oh yes, and $P0(...) doesn't throw a syntax error in IMCC any more.

http://groups.google.com/

http://groups.google.com/ -- Continuations made simple

Collision of running jokes

Once upon a time, I endeavoured always to mention Leon Brocard in these summaries, which got increasingly difficult (not to mention tortured) as his posts to the mailing lists became more and more infrequent. However, on the first of April (aka the oldest running joke in Christendom) he posted a couple of patches. Sadly, we didn't manage to get a triple running joke collision, for it was Leo Tötsch and not chromatic who applied the patches.

http://groups.google.com/

Stream library

Okay, if Leo Tötsch is the Patchmonster, then Jens Rieks shows every indication of becoming the Libmonster. Not content with implementing Data::Dumper in pure Parrot, he's working on an EBNF Parser and, on Friday he released his first working development version of a Stream library which wraps all sorts of sources of strings behind a simple interface (suitable for parsers, for instance). Leo had a few issues with some of the implementation choices that potentially make it a little tricky to subclass streams (and then the week ended, but a little bird tells me that Jens took these comments on board and redid the library).

http://groups.google.com/

Subroutine calls

Leo announced that he's added a pmc_const opcode to parrot. The idea being that, in general subroutines don't vary that much so instead of having to call newsub every time you make a function call (IMCC usually does this), you would instead fetch a preexisting Subroutine PMC from the PMC constant pool.

http://groups.google.com/groups?selm=406D85DA.6090003@toetsch.at

Named attribute access

In a very short (but useful) post, Leo announced that you could now do

    getattribute $P0, anObject, "attribute"
    setattribute anObject, "attribute", $P0

For which I personally thank him profusely.

http://groups.google.com/

Meanwhile, over in perl6-language

Things were pretty quiet. But not utterly quiet

Default Program

Extrapolating from the general Perl principle that, in the absence of any indication otherwise, Perl should use a sensible default, Brent Royal-Gordon proposed that Perl 6 should extend this principle to entire programs. He proposed that, when the whole program was an empty string, Perl 6 should substitute a sensible default program. Based on extensive research on the Internet and printed Perl documentation, he proposed that the default program should be:

    print "Hello world!\n"

Apart from those who quibbled with his punctuation, the general response was positive. However, always one to take a good idea that one step further, Austin Hastings suggested that a more sensible default would be to have a naked invocation of perl launch an editor (or other script development environment). He proposed that, to this end, the Parrot team should be focusing on implementing elisp in Parrot rather than worrying about winning the Piethon.

Richard Nuttall thought that Austin hadn't gone far enough, he proposed that Perl 6 should load the DWIM::AI module and provide as output the script you were intending to write.

A quick glance at the calendar was in order at about this time.

http://groups.google.com/

Can colons control backtracking in logical expressions?

Gleefully ignoring Larry's stricture that "I [Larry] get the colon.", Austin Hastings wondered about using :: to mean something special in conditional statements. Quite what his proposal offered over and above

    if specific_condition() ?? detail() :: general_condition()
      { ... }

perplexed Damian somewhat (though he did forget that ... ? ... : ... has become ... ?? ... :: ... in Perl 6. Elsewhere in the thread, Larry reminded everyone that Perl 6 will not be confusing statements and expressions.

http://groups.google.com/

Announcements, Acknowledgements, Apologies

No announcements this week, apart from the one earlier about the next summary being due in two weeks because of Easter.

If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:pdcawley@bofh.org.uk or, if you find yourself at Miskin Folk Festival this Easter weekend, you could always buy me a drink.

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

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

http://www.miskinfolk.cjb.net/ -- Miskin folk festival

Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en