Picture, if you will a sunny garden, unaffected by power cuts, floods, plagues of frog or any of the other troubles that assail us in this modern world. Picture, if you will, your summarizer, sat in this garden with a laptop on his knee, cursing the inability of LCD display manufacturers to make displays that are legible in sunlight. Picture your summarizer returning to the comfortable chair in the shade of his book room casting around for a witty and original way to open another Perl 6 summary. Picture him giving up and starting to type. Here's what he writes:
We start, as usual, with the the internals list.
Leo Tötsch has started to work on getting IMCC to detect tail calls and optimize them to either a simple jump or an invoke. If you're not sure what tail call optimization is I can recommend Dan's ``What the heck is a tail call?'' article on the subject.
http://www.sidhe.org/~dan/blog/archives/000211.html -- What the heck?
Last week, Leo bundled up a bunch of outstanding questions for Dan,
and Dan answered them. Benjamin Goldberg queried Dan's answer about
find_method, which, if I'm reading things correctly is currently
implemented in the interpreter. Benjamin argued (convincingly I
thought) that, although the method hashes needed to be stored in the
find_method should be implemented on
default.pmc, allowing for different classes/languages to override
Michal Wallace wanted to know why
~ maps to both unary bitwise-not
and binary bitwise-xor in IMCC; he expected xor to be
^^. Leo explained that it was, at one point at least, the way Perl
6 did it but that he'd stopped keeping up with the developments in
perl6-language. He noted that, if the Perl 6 operator had been
settled, then IMCC should use that. A quick skim of my copy of Perl
6 Essentials tells me that Perl 6 now uses
for bitwise and/or/xor, with
~^ for stringwise
http://pc1.bofhadsl.ftech.co.uk:8080/archives/000011.html -- My review of Perl 6 Essentials
Michal Wallace's Py-Pirate project continues to exercise the edges of
Parrot as he implements more and more of Python's semantics. This
time he needed to know about raising (and catching) exceptions. In
particular he wanted to be able to catch an exception when
find_lex failed to find an appropriately named
variable. (Currently, a
find_lex failure doesn't raise an
exception, it just kills Parrot). Jos Visser told him that there were
plans to have
find_lex throw a real, catchable exception, or maybe
undef. See last week's summary for a pointer to that
Michal Wallace announced that he had just finished an all night coding spree and that Py-pirate could now handle:
- functions (closures, recursion, etc)
- Global variables
- tuples (but they turn into lists)
- list comprehensions
(At this point, I think we should all pause for moment of wild applause).
However, he was having a few problems with instantiating objects of a
class. (For those who don't know, Python instances are created by
calling the Class as if it were a function). Leo Tötsch noted
that almost nothing would work, since Parrot's classes and objects
weren't actually finished yet. He agreed with others in the thread
who reckoned that Python classes could be made to work by subclassing
the standard class.pmc to allow it to respond to an
by creating a new instance. Easy! Michal muttered something about
faking classes with closures but I don't think he went through with it.
So long assemble.pl, it's been good to know you.
Leon Brocard, Sean O'Rourke and James Michael DuPont looked on in awe as Bernhard Schmalhofer announced that he'd been working on implementing m4 in Parrot. According to Sean, the ``implications are staggering... Sure, plenty of compilers can bootstrap themselves, but how many can generate their own configure scripts via autoconf? With p4rrot, we may live to see this dream.''
One does worry about Sean's dream life.
TOGoS has been thinking about the workings of the Parrot calling conventions. He wondered if there was a case for making calling and returning look exactly the same, allowing for cunning stunts with fake continuations in P1. Luke Palmer really liked the idea. Leo seemed to think it was a good idea too. There has been no word from Dan yet.
Leo Tötsch has started to extend the
packfile functions to
handle multiple code segments and has been running into problems with
EXEC -- the tool that uses the JIT to generate a native executable from
Parrot assembly. Daniel Grunblatt checked in a 'temporary' fix, which
at least solved Leo's immediate problem.
Steve Fink thought, given the 'insane amount of work' on Parrot recently, that it was approaching time to cut another release. He asked if there was anything else coming up that people would like to see included in the release, and whether we had enough to call the next release 0.1.0. Luke Palmer really wanted to see objects finished, but wasn't sure how much would that would entail. Leo thought that the Parrot Calling Conventions (and more particularly the return convention) support needed fixing, and noted that PackFile is currently in a state of flux. Both of them thought 0.1.0 would be the right version number though.
TOGoS wasn't keen on the variable behaviour of add depending on whether its target was a PMC, or an integer/number register. Brent Dax thought that TOGoS needed to train his expectations and went on to explain why.
For reasons that I can't quite follow, this discussion morphed into a polite argument between Dan and Leo about the wisdom of having all those keyed opcodes.
Benjamin Goldberg pointed out that, since TOGoS's desired 'set' semantics could easily mocked up with an assign operator (but not vice versa), then maybe IMCC could handle mocking it up automatically.
Michal Wallace wondered if it is possible to serialize a Parrot function, or (slightly more tricky) if you could serialize a generator and its state. Answer: Yes, it's almost done (well, the function part anyway; Leo didn't' mention the generator thing).
I'm not sure if the support for this was fixed up in the packfile changes that Leo checked in a couple of hours after his answer.
Arthur Bergman popped over from ponie-dev to ask about a problem he'd been having with his parrot embedded miniperl. Apparently, if a caller closes STDERR, the program produces no output on STDOUT either. Leo found where the problem was happening -- Parrot was trying to open STDERR, failing, and dying with an error message. To STDERR. Jürgen Bömmels, the ParrotIO maintainer, outlined a few possible fixes.
Luke Palmer asked about calling a parrot sub from C and getting the return value. Leo gave a terse answer that covered the bases and pointed at classes/Eval.pmc for an implementation of something very like the general case of calling parrot subs from C.
Michal Wallace discovered that there seems to be no op to remove a variable from a lexical pad. Leo patched the scratchpad PMC so that you can now do:
peek_pad Pn delete Pn["foo"]
to delete variable names.
Michal Wallace announced the version 0.01 alpha of Pirate which he described as ``(almost) everything I can do for Python without jumping into C''. Which turns out to be an awful lot of stuff.
I've just looked back through my summary archive and, as near as I can tell, Michal's gone from thinking about doing this to having most of the Python syntax working in just under 3 weeks, which is really rather scary when you think about it. Well done Michal.
Right at the end of the week, Luke Palmer posted another attempt to come up with a neat solution to the timely destruction problem. I'm guessing we'll see it discussed in next week's summary.
A while ago now, Jonathan Worthington offered to start making regular binary builds of Parrot for those who use Win32 but who can't compile Parrot on it. This week he announced that he's done it. Thanks Jonathan.
http://www.jwcs.net/developers/perl/pow/ -- The POW site
Simon Cozens pointed the list at the nickle programming language and wondered if it might be a suitable language to implement on Parrot.
http://nickle.org/implement/html -- The Nickle site
Traffic was light. Very light.
Alberto Manuel Brandão Simões, noting that the Apocalypses and Exegeses were subject to later modification, wondered if anyone had any idea when we'd have a freeze on the syntax and features for Perl 6. The obvious joke -- ``Sometime after Perl 5's syntax and features freeze'' -- was cracked. The consensus was that the syntax is currently 'slushy', and will probably firm up in the next 6-12 months. There was also some discussion of Perl 6 Essentials, and Nicholas Clark pointed us all at a new book that Alan Burlison had found.
If anyone's following the 'moving to the North East' saga, last week's offer fell through, but that was actually a good thing as we're now buying my daughter's Tyneside flat instead, which does rather take some of the 'got to get everything sold by mid September' pressure off and replaces it with 'How on earth are we going to fit the contents of a 4 bedroomed house into a two bedroomed flat?' pressure.
In case you hadn't already spotted that I was impressed, much kudos goes to Michal Wallace for his sterling work on Pirate. Three weeks from concept to having a huge chunk of the language implemented is just amazing.
Check out http://pc1.bofhadsl.ftech.co.uk:8080/ for more of my writing.
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 some free time to firstname.lastname@example.org