This week on Perl 6, week ending 2003-08-03

Aug 3, 2003 by Piers Cawley

“Ooh look, it’s another Perl 6 summary. Doesn’t that man ever take a holiday?” “I think he took one last month.” “Is it in Esperanto this week?” “I don’t think so.” “Does Leon Brocard get a mention?” “It certainly looks that way.” “Does is start with the internals list again?” “I think it does, in fact, here it comes now.”

Approaching Python

Discussions (and coding) of the Parrot implementation of Python continued this week. Michal Wallace is working on taking a preexisting (but incomplete, it’s a proof of concept only) python parse tree -> parrot code generator and rejigging it to generate code for IMCC. Assuming the initial rejig is doable, Michal surmises that getting a complete python compiler will be ‘just’ a matter of fleshing out the rest of the visitor methods, ‘and then dealing with the C-stuff.’

Actually, the main strand of this discussion dealt with ways of extending IMCC to help optimize the translation of stack based code to code that uses registers more efficiently (register unspilling as Benjamin Goldberg called it), which should help with any bytecode translator based efforts.

http://groups.google.com/groups

http://groups.google.com/groups

Semantics of clone for PIO-objects

Jürgen Bömmels’ work on the Parrot IO system continues to find edge cases in Parrot’s memory management subsystem. As initially written, a clone call adds a reference to a ParrotIO object, but that object is neither garbage collected nor refcounted, and it gets destroyed when its first reference is destroyed. The problem can be solved by allocating a new ParrotIO in the clone call, but Jürgen had some questions about how to handle various things like what to do with buffering or position pointers.

Jos Visser offered a suggestion involving indirection and reference counting which met with (at least) Melvin Smith’s approval.

http://groups.google.com/groups

Making ‘make’ less verbose

Leo Tötsch checked in a patch to make make’s output rather less verbose. After the patch, the make process only echos the name of the file being compiled, and doesn’t spam your terminal with the entire compiler commandline (the compiler warnings do that). Some people liked this. Others didn’t.

http://groups.google.com/groups

Don’t trace system areas in sweep ops

One of the things we discussed at the Parrot BOF was how to solve the ‘bogus objects’ problem when doing timely destruction sweeps (The ‘bogus objects’ problem is when the stack walk code detects chimerical objects through holes in the C stack (hmm… if anyone has a good drawing of this?)). After much discussion we came to the conclusion that the trick was to only walk the system stack during DOD (Dead Object Detection) runs that got triggered via resource starvation.

This works because “There is nothing unanchored and alive beyond the runloop’s stack”. Brent Dax was impressed, but then, he wasn’t at the BOF so he doesn’t know how long it took us to get to the answer.

http://groups.google.com/groups

User defined events

Klaas-Jan Stol wondered if there would be some way of generating and posting user defined events. Uri Guttman thought that there probably would be.

http://groups.google.com/groups

PHP/Parrot

The language implementation insanity continues!

Stephen Thorne announced that he’s working on implementing a PHP parser and is seriously considering targetting Parrot. He asked for pointers to good docs on how to go about doing so. He worried a little about bootstrapping as well.

Luke Palmer and Simon Glover were forthcoming with lots of useful answers and pointers.

http://groups.google.com/groups

Why Parrot uses Continuation Passing Style

In a delayed response to a question from Klaas-Jan Stol, Dan has posted a long message on the reasons for choosing Continuation Passing Style as Parrot’s calling convention. It’s definitely worth the read if you’re at all interested in the reasoning behind Parrot (and the reason that my copy of Perl 6 Essentials has a signed correction from Dan).

http://groups.google.com/groups

IMCC supports the Parrot Calling Conventions

Leo announced that IMCC’s brand of assembler, PIR (I can’t remember what it stands for, Parrot Intermediate Representation perhaps). Of course, there are things it doesn’t quite do yet (tail call detection, only preserving ‘necessary’ registers…) and it’s somewhat lacking on the test front, but it’s a start. Yay Leo!

http://groups.google.com/groups

Another task for the interested: Coverage

Dan threw out another ‘task for the interested’ this week. At present we don’t have a complete set of coverage tests for the parrot opcodes, nor do we even know why opcodes do have coverage. Volunteers to fix this state of affairs (start with a coverage report being generated as part of the make test run) would be very welcome.

It turns out that Leo already has an “unportable, ugly, slightly tested” script generating a coverage report of sorts which he posted. Josh Wilmes also has a coverage testing tool generating reports on the web, but he’d turned it off following some problems under testing.

http://groups.google.com/groups

http://web.archive.org/web/20050816082346/http://www.hitchhiker.org:80/parrot_coverage/ – Josh’s reports

Pirate (py…rrot)

Will the terrible jokes never stop?

Michal Wallace reported to the list on his attempts to retool amk’s parrot-gen.py to generate code for IMCC. It sounds like he’s making good progress, but his choice of codename – Pirate, from py…rrot – had at least one summarizer groaning.

Later Michal asked the list about the best way of generating subroutines and asked for some pointers about how best to arrange the generated code. He also let slip that Pirate could handle Lists, strings, and ints; assignments; control structures; maths; boolean logic; and comparisons…

Leo came up with a suggestion about code layout for Michal and spoke for everyone (I think) when he added:

“Wow.”

Luke Palmer offered a few performance tuning tips (the parrot of Python translation is currently running 3 times slower than python on euclid, but I’m sure we’ll get that fixed soon enough.

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

http://web.archive.org/web/20170621155426/http://jryan.perlmonk.org/images/jirate.tar.gz

Dynamic PMC Classes

Leo announced that he’s started working on dynamic PMC classes. The idea is that PMCs could be loaded on demand, in a similar fashion (though hopefully with a nicer interface) to Perl 5’s DynaLoader tricks. He already has something working, and asked for comments.

Dan responded by outlining his thoughts on the interfaces and requirements for dynamic PMC loading, which weren’t quite the same as what Leo had implemented, but they don’t call it software for nothing.

Christian Renz wondered if there were any plans to allow PMCs to be implemented in Parrot assembly. Dan confirmed that there were.

http://groups.google.com/groups

Question about interpreter == NULL

Jürgen Bömmels wondered which functions allowed the caller to pass in a NULL pointer in place of the interpreter. Some functions allow this, others fall in big segfaulty heaps. He and Leo thrashed out the details of what is and isn’t allowed, hopefully this will make it into documentation at some point.

http://groups.google.com/groups

Adding yield semantics to IMCC

Kenneth A Graves has been experimenting with the .pcc_* directives for implementing function calls, and wants to add coroutine support by implementing .pcc_begin_yield and .pcc_end_yield which would be analogous to the current .pcc_*_return directives. He supplied a patch implementing what he was after. Leo liked the patch and applied it.

http://groups.google.com/groups

IMCC objects speed, .include, file-scoped vars et cetera

Now that Parrot nearly has objects, Jerome Quelin has started work on a new version of Befunge in IMCC. This meant he had a pile of questions about speed, file scoping of variables, problems with line numbering within included files, and fragility in the absence of newline termination.

Melvin Smith opined that the time had come to start putting together a nice web based set of docs for IMCC, and volunteered to start work on it himself as soon as he’d caught up with the current state of the IMCC art.

Leo Tötsch meanwhile answered most of Jerome’s questions.

http://groups.google.com/groups

IMCC’s call vs first class functions

If you were still not sure of the virtues of Continuation Passing Style in Parrot, then Michal Wallace’s problems with making first class function objects in Pirate might help convince you of their virtue. As far as I can see, just switching to a CPS style should mean that anonymous functions in Pirate become almost automatic. (I could be wrong of course)

http://groups.google.com/groups

David Adler Scares Himself

For reasons best known only to himself Dave Adler has implemented an hq9+ interpreter in pasm. Quite what an hq9+ interpreter is was left as an exercise for the interested reader. Having just now done the Google search for the language, I think it’s best if I leave it to you to do the search yourself, but quite frankly, I wouldn’t bother.

http://groups.google.com/groups

Upcoming backwards incompatible changes to IMCC

Leo Tötsch announced some changes to IMCC which will mean it is no longer backwards compatible. What’s changing is that from now, all code outside of compilation units will be ignored, which means that nested subroutines will no longer be supported. He will also be adding a new .globalconst directive for declaring file scoped constants.

http://groups.google.com/groups

Embedding Parrot

Jeff Horwitz is interested in embedding parrot in other programs, and wanted to know if there was any prior art, or even a road map. So far there’s been no response.

http://groups.google.com/groups

Meanwhile, in perl6-language

Things are starting to warm up a little in perl6-language following the publication of Exegesis 6 (take a look, you’ll find it at http://www.perl.com/pub/2003/07/29/exegesis6.html, there’s much good stuff in there; Perl 6 is starting to look like a real language I tell you). The volume’s not got up to post-Apocalypse 6 levels yet, but it’s early days yet.

Perl 6’s for() signature

John Siracusa referred back to an earlier summary where I had wondered if either of two for implementations had got the signature quite right. Luke Palmer (perpetrator of one of the for implementations) thought that it wasn’t quite possible to come up with an accurate signature for for (or at least, not one that could tell the compiler enough to detect errors at compile time.) because you essentially needed a slurpy list followed by a block, but slurpy lists have to be the last parameter in the signature.

John countered by quoting from Exegesis 6 “An important goal of Perl 6 is to make the language powerful enough to implement all its own built-ins”, which doesn’t exactly contradict what Luke said, as there’s always the possibility of implementing something for-like using a macro, but that doesn’t feel too comfortable.

Rod Adams proposed “non-greedy slurpy arrays” which would be analogous to non-greedy regex matches and proposed *?@ as the sigil combination for such a parameter. (Perl? Line noise? Never!)

Damian Conway tweaked Simon Cozens’ “Soylen^WPerl 6 is Ruby!” detector when he mentioned that Larry was considering adding a special case for allowing a single &block parameter after a slurpy parameter, but that both Larry and Damian weren’t entirely happy with the idea.

Larry offered words of wisdom. As usual.

http://groups.google.com/groups

http://www.perl.com/pub/2003/04/p6pdigest/20030427.html – the earlier summary

http://groups.google.com/groups – Larry dispenses wisdom

Exegesis 6: Assume nothing

Referring to Exegesis 6, Trey Harris wondered how one could curry a subroutine to always use the default value for the ‘assumed’ parameter. He wanted to be able to created a curried function in such a way that, if the original function’s default value changed, the curried function would reflect that.

I don’t think this thread has been resolved to anyone’s satisfaction yet, and I can’t quite tell where it’s headed. My gut feeling is that this is a sufficiently rare requirement that Damian’s solution of not using .assuming at all and just writing a simple wrapper function by hand may be the way forward.

http://groups.google.com/groups

Mandating name-only parameters

Mark J. Reed wondered if the new parameter declaration syntax meant it was possible to declare a mandatory name-only parameter. Damian thinks it will probably be doable, but only by using traits rather than the single character prefixes.

http://groups.google.com/groups

Small Junctions

Exegesis 6 describes a junction as “a single scalar value that can act like two or more values at once”. Dave Whipp wondered how junctions with 0 or 1 members would behave. As Dave said, the case of a single member junction is relatively easily to understand, but he’s unsure as to the semantics for a 0 member junction.

Luke Palmer gave a good answer, and pointed at Damian’s message about “Perl 6 and Set Theory” for more detail.

http://groups.google.com/groups

http://groups.google.com/groups

Macros and is parsed

Abhijit A Mahabal asked for some clarification about the workings of macros, in particular how/when macro arguments were parsed. The answer from Larry appears to be that macros get a default parsed trait, which can be overridden by is parsed when the macro is declared, so macro arguments are parsed by the macro’s parsed trait.

http://groups.google.com/groups

Macro arguments themselves

Luke Palmer wondered what macros do about being passed variables, with a supplementary question about recursive macros. Larry answered that macros dealt with their arguments in the way that Luke hoped (it’d be a disaster if the didn’t, frankly), but that to get a recursive macro you would probably have to write a helper function.

http://groups.google.com/groups

Another macro question

Abhijit A. Mahabal wondered what

    macro foo() { return { my $x = 7 } }
    foo;
    print $x;

would be equivalent to. According to Larry, the answer is probably:

    do { my $x = 7 }
    print $x;

Which would throw an error under use strict. It seems to me that the way to get expanded code that looks like:

    my $x = 7;
    print $x;

would be to declare foo as:

    macro foo() { return 'my $x = 7' }

http://groups.google.com/groups

grep EXPR, LIST

John Williams wondered if the Perl 5ish grep EXPR, LIST would still work in Perl 6. Larry thinks not. I think it should be possible to declare an appropriate macro version of grep, but the margins of this summary are too narrow to contain my solution.

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

Thanks to Damian for Exegesis 6, Perl 6 may be slow in coming, but I like it more with each revelation.

Ooh look, another plug for http://pc1.bofhadsl.ftech.co.uk:8080/.

As ever, 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, requests for consultancy, photographic and writing commissions, or suggestions for something else to ask for in this bit to p6summarizer@bofh.org.uk