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.
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.
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.
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).
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
.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
.const requires a type as well. It turns out that
.const wasn't quite what Clint needed, so Leo pointed him at
.local which do seem to do what he needs.
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.
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.
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 firstname.lastname@example.org with the expansion of PMC).
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.
Dan tantalized all those waiting eagerly for objects in Parrot by
discussing how to make method calls. This, of course, means a few new
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.
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...
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...
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
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://email@example.com/msg14771.html -- Austin Hastings on threads
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
::= 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.
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.
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.
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:
- A lifetime subscription to the Perl 6 summaries.
- 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 firstname.lastname@example.org.