Welcome to the first Perl 6 summary of the new 'Copious Free Time enabled' era, which should mean that these summaries will get mailed out on Monday evening from now on.
We start, as usual, with perl6-internals
Leopold Tötsch continued to work on making
eval and its
associated operators work and asked for some opinions about a problem
he was having with jumps between code segments. Jason Gloudon played
sounding board and the two of them found a way forward.
Dan announced that Parrot was crashing big time under (at least) OS X, throwing segfaults in the NCI mark routine. Other people contributed reports of what was happening on their platform and Leo Tötsch tried to track down the error, working on the assumption that it was something to do with his eval patch as that was the last patch that had gone in.
Later in the week Dan realised that part of the problem with OS X was a problem with imclexer.c, an autogenerated file being generated with bad code. Leo reckoned it was a problem with something having been multiply defined, which had since been fixed.
Still later in the week, Steve Fink offered some analysis on the NCI mark routine and a patch which attempted to fix the problems he saw with it. Leo reckoned that the patch wasn't quite right, but the analysis was good and used that to fix the problem and discovered in the process that the parrot build process's dependency analysis wasn't quite up to the mark. (I don't think there's a fix for that yet, but at least we know the problem exists...)
K Stol is looking for a final project for his Bachelor's degree and would like to implement some language targeting Parrot and asked for suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested Java (though Gopal V wasn't sure that was such a good idea just yet). Dan suggested that, just because someone else was already working on a TCL compiler it didn't mean it wasn't worth trying anyway, but apparently it would have been unlikely to get approval as a Bachelor's project. There was some further discussion of Lua and whether there would be any real point in implementing it and the thread died down before Mr Stol told anyone what he'd decided to do, which was rather a shame I thought.
Some months ago, Jürgen Bömmels offered a patch to extend the Parrot packfile format whilst retaining backward compatibility. This week, after a little modification, Leo Tötsch applied it. James Mastros wondered if it didn't make sense (at least before parrot 1.0) to ignore backward compatibility issues and just make it right. Leo and Dan agreed, but Leo pointed out that, at least until the switch from assemble.pl to IMCC was complete, maintaining backward compatibility was the right thing. (So, if you're currently using assemble.pl to assemble your language, consider moving it to IMCC sooner rather than later).
Discussions continued. A good deal of time this week was spent discussing the overrideablility (there's got to be better word than that...) of OO method dispatch for different languages (and at a language level too I hope -- I like flexibility). Python for instance seems to require that every step in the process be subject to override. Dan pointed out that dispatch would end up being implemented as vtable methods on per language Object PMCs so that messages from one language's objects to another's would use the target language's dispatch rules. Which seems rather cute (in a good way).
http://groups.google.com/groups -- Christopher Armstrong talks about Python
http://groups.google.com/groups -- Dan on how it works.
Leo Tötsch added a new opcode for intersegment branches, called
branch_cs which was his implementation of the fix that he and Jason
Gloudon had discussed while talking about problems with
didn't think Parrot needed this and that we could just use a plain
jump. Leo pointed out that there were several places where this didn't
quite work, especially in the presence of JIT optimization. Dan didn't
think that didn't mean it wouldn't work, but reckoned that the cases
Leo pointed out were reasons he wanted to see intersegment jumps
mediated by subroutine calls. Leo followed up to this with an
example. I can't for the life of me tell if this was a counter
example, a suggestion or what though.
This reemerged as a new thread with the subject 'Transferring control
between code segments'. Dan opened the thread by discussing the design
perspective and laying down a few edicts. He went on to discuss the
issues that Leo's 'phenomenally cool'
compile opcode has exposed in
his earlier handwaving and replaced the handwaves with more detail.
People were generally happy to see this, but there were a few small issues with it which weren't explicitly resolved this week.
http://groups.google.com/groups -- Design issues
Dan responded to the earlier discussion of extending the packfile format by opening a discussion of the type of metadata that might be useful to have in either the on disk packfile or in memory bytecode. He reminded everyone that parrot may have to ignore (or at least mistrust) the metadata and opened the floor suggestions.
James Michael DuPont came up with a proposal involving RDF which Dan thought might well be overkill (albeit interesting overkill) since he had been thinking more about metadata that would be used by the engine itself or provided to programs running on it.
Various other suggestions were made, and it's apparent that one immutable design guideline is that any bytecode format for Parrot must allow for executable code to be mmapped in.
Leo Tötsch has a patch implementing a simplified API for generating packfiles and wondered if he should check it in.
http://groups.google.com/groups -- Opening remarks
http://groups.google.com/groups -- The RDF bazooka
Dan reported that examples/assembly/mops_p.pasm was running slower with JIT optimization than without under OSX, which doesn't seem right. Daniel Grunblatt pointed out that JIT cores that don't optimize many opcodes will always be slower than a Computed Goto (CG) core and there aren't many optimized opcodes for the PPC architecture. Bruce Gray pointed Dan at an introduction to PPC assembler in case Dan wanted to add to the score of optimizations. Anyone else is interested could take a look too, kudos awaits the heroic implementer.
There was a little more diversity of discussion this instead of concentration on a single massive thread, though that thread did, of course, continue on its path.
There was some discussion of implementing conditionals (
etc) as functions rather than special keywords. Personally I'm not
sure that anything that monkeys with Perl's normal order of evaluation
can strictly be called a function, but what the hey.
Buddha Buck showed off a rather neat implementation of if, then and
else which borrowed some of its implementation from a Smalltalk
like 'Bool' class with
isFalse methods and then used
multiple dispatch to get the rest.
In another subthread, Michael Lazzaro explained why he still wanted Right to Left pipelining, even though he was much more at ease with Perl 6's rules for when you needed a comma in an argument list. It appears to be mostly about teachability.
Damian popped up to make (at least) Graham Barr and me happy when he
said that he didn't think the Perl 5ish functional forms of
grep etc would be going away. Huzzah!
http://groups.google.com/groups -- Buddha's Smalltalk port of conditionals
http://groups.google.com/groups -- Michael Lazzaro on grep, map and explicit pipelines
http://groups.google.com/groups -- map/grep/etc still functions
Brent Dax proposed a solution to the problem of implementing
else as functions (the problem being that, unless you cuddle all
elses, perl will intuit a semicolon at the end of
block and things will get confused) by proposing that all code
blocks take an optional 'else', accessed by the
attribute, one of the side effects of which would be that
Austin Hastings wondered if supporting 'separable verbs' might be a better way forward. The idea certainly looks interesting, the best summary of the idea I can give you is to point you at Austin's original message though.
http://groups.google.com/groups -- All blocks are elseable
http://groups.google.com/groups -- Separable verbs
Rich Morin pointed everyone at Paul Graham's presentation at the first Little Languages conference about Arc, pointing out that Graham had some interesting things to say about language design. The discussion that followed was mostly off topic (in the sense that they weren't talking at all about Perl 6). Graham's paper is interesting though.
Michael Lazzaro wondered about the seemingly different meanings of colon in:
print $FH : $a; # $FH is an indirect object @a = 0 .. 10 : 2; # @a is (0,2,4,6,8,10)
and wanted to know when
: meant 'step' and when it designated an
indirect object. Brent Dax helped clear things up. Essentially
a 'supercomma' and different operators and functions interpret what
comes after the supercomma in different ways.
.. treats it as
specifying a step.
Piers Cawley wondered if it would be possible to specify a multimethod by context as well as by parameter types. Dan Sugalski managed to hole the proposal below the waterline with a neat set of multidispatch declarations that led to a horrible ambiguity. Thomas A Boyer pointed out that Ada can handle such ambiguities but that it was a complete pain to implement and voted against using return type for multiple dispatch.
Ah... um... I appear to be lacking an answer set this week.
I'm afraid to have to announce that, as of this week I can no longer donate the fee for these summaries to the Perl Foundation it's currently my only source of income. On the positive side, now that I don't have to spend 8 hours a day working for someone else I should be able to get the Summary mailed out to the Perl 6 lists on a Monday from now on.
Thanks to everyone who sent me mail about my redundancy. No matter how good it feels not to have to get up at 5.50 every morning with the prospect of not getting home again 'til at least 18.40 it's still a terrible shock to lose your job. Thankfully we look to be in a much better position this year than we were last time I was out of work; I'm hoping that, if I can get a few more freelance writing gigs and maybe a little consultancy I'm not going to have to go back to the 4 hour commutes for the foreseeable future.
Thanks too to everyone who's given me answers for the Who's Who section since this summary started. I'm sorry to be retiring it for now, but as new blood filters into the Perl 6 community I hope I'll be able to restart it some time further down the road.
If you 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, job offers or concrete proof either way about Iraq's weaponry to email@example.com