Another Monday evening. Another summary to write.
Starting, as is becoming tediously predictable, with perl6-internals.
Toward the end of the previous week, Leopold Tötsch posted something about the latest round of changes to the JIT core. Daniel Grunblatt was concerned that the current JIT wasn't doing the correct thing when it came to hardware register allocation and wanted to remove a some conditional logic. Leo didn't agree at first, but became convinced and Daniel's requested change was applied.
Many things happened with IMCC this week:
David Robins posted a list of minor niggles (For instance, it turns
out you can't
retearly from a
.sub) and suggested some remedies. Leo Tötsch mentioned that the IMCC Cabal (which would consist of Melvin Smith, Sean O'Rourke, Angel Faus and Leo if there were a Cabal. But, as everyone knows, There Is No Cabal) has been discussing several of these issues.
- Art Haas had problems building IMCC, apparently bison didn't like the imcc.y file. Leo tracked down the problem (when asked a second time; I think he might be slipping) and checked in a working fix.
Leo Tötsch made a pile of changes to IMCC to eliminate clashes
between Parrot's PASM language and IMCC's PIR syntax, which had made
it hard to mix the two. Full details of the changes are in his post.
Gopal V wondered whether there was any way of feeding code to IMCC beyond simply writing to a file and running IMCC. He'd had to make a bunch of changes to the IMCC files that he used, and wondered whether there was a better way. Actually, he didn't so much wonder as propose the aforementioned better way, lifting ideas from DotGNU's treecc. He and Leo discussed things, worked out an interface and Gopal went off to implement something. (Yay Gopal!)
Steve Fink posted a patch implementing a first cut at namespace
support in IMCC. He wasn't at all sure that what he'd implemented was
the right thing, but it supplied what he needed for the time being (if
that makes sense) in the regex engine. Leo reckoned that it looked
OK, and promised to apply it if nobody hollered. He also pointed out
some problems with the current regex implementation to do with
re-entrancy and memory leakage. It turns out that Steve was working on
languages/regex rather than the
rx_*ops, which are the ones that have the problems.
Gregor N. Purdy had some problems with IMCC's syntax, a fragment of
code that he thought should work fell over in a heap. Both Mr. Nobody
and Leo pointed out that IMCC expects subroutines, and you should wrap
your code in a
Once Gregor had that straight, he posted a Jako program and the IMCC code he thought the Jako compiler should generate from it and asked for any feedback before he went to change the compiler. Leo Tötsch provided some (I assume) useful feedback.
A little later Gregor posted again, and he was still having problems with IMCC not quite behaving as he wanted for the Jako compiler. He and Leo thrashed it out over a few messages and, to cut a long story short, IMCC looks like it won't be changing. I'm not sure whether Gregor is happy about this ... .
Mr. Nobody posted a patch to get IMCC to compile under
Windows. Apparently, the
OUTlabel clashes with something in the Windows header files. The patch was applied.
- Gregor N. Purdy got a little confused by how IMCC generates PASM code, and posted some sample code, interspersed with questions, which Leo answered. It's worth looking at this; it shows off the kind of optimization that IMCC gets up to.
Dan announced that he's finally stopped waffling and frozen the PMC structures `modulo the odd twiddling to it.' He's added a pmc.ops file, and has started adding in ops to manipulate PMC internals. Leo asked for some clarifications, got some, and then wondered what the final 'Parrot Object' would look like.
David Robins is having fun with
logical_not and Ruby. The issue is
that all integers in Ruby are true, whether or not they are zero
but that with some of the assumptions in other PMCs. Robin offered 3
suggestions for how to fix it. Dan noted that it's an issue for Perl 6,
too, since the truth or otherwise of a value can be modified by a
property of that value, coming up with a fix is on his to-do
list. David wondered whether this had been discussed before and offered
another possible way forward. Dan half liked the idea but noted that
the approach didn't work for
xor, at least where
Perl is concerned.
After a fortnight, during which nobody made any comment on Leon Brocard's patch adding a brainfuck subdirectory to the languages directory, Nicholas Clark committed it in CVS.
At which point, Andy Dougherty spoke up to say he wasn't happy about it, saying that he didn't wish to be associated with needlessly crude and offensive language. After some further debate, the subdirectory was renamed to bf in such a way that, if you ask CVS it will tell you that the brainfuck subdirectory does not exist now and never has existed. Which seems strangely appropriate somehow. Fnord.
Michael Collins asked about the structure of the Parrot development organization, and Dan provided some answers. My favorite Q&A:
Q. Is there any formal structure to this organization.
A. I [Dan] delude myself into thinking I'm more or less in charge ... .
to start using long file names with impunity, Mr. Nobody pointed out that a bunch of the files in the Parrot repository didn't play well with the MS-DOS 'filesystem's 8.3 naming rules. "So what?" asked Aldo Calpini. Mr. Nobody asked if DOS was an intended compilation target. Answer: "No". The consensus appears to be "Ha! We laugh at your crappy filename restrictions and will not be jumping through any hoops to deal with a faintly silly hypothetical target." Or maybe that's just my opinion dressed up as consensus. Ah well, if I'm wrong, then I'm sure someone will tell me.
The perl6-documentation team have been discussing String literals and
their discussion spilled over into perl6-language as there are
several things about them that are undefined and needed discussing by
the language crowd. It's all to do with how octal numbers and octal
string escapes are specified. Essentially, people don't like the
current Perl5/C style
0101 (octal number) and
\101 (octal string
escape), so James supplied a list of the other possibilities. (The
current Numeric literals doc say that
0c101 designates an octal
numeric literal, but then the consistent extension to string literals
\c101 clashes with the current method of specifying a
control-char). After some debate, Larry pulled one of
his gloriously clear posts out of the bag, sketching the issues and
coming up with a straightforward and obvious (but only with hindsight)
way forward. It's good to be reminded why we trust Larry. Anyway, it
turns out that an octal number will be specified using
0o101 and an
octal character escape will probably be one of
\c[0o101] (I like the second better...)
Once Larry had pulled
\c[0o101] out of the bag, it fell to David
Whipp to wonder what you could get up to with it. For instance, could
print "\c[71, 101, 108, 108, 111]" and have that print
"Hello"? Damian pointed out that Larry had already discussed some of
this in Apocalypse 5, but that the separator character would probably
be the semicolon. Then Nicholas Clark got evil, and wondered about
"\c[$(call_a_func())]", but Damian seemed to think that wouldn't be
such a good idea.
Miko O'Sullivan suggested a
purge command that would be to
unless is to
if. Nobody seemed to like the name that much,
though most seemed to think the idea was sound. Michael Lazzaro
divvy could be used to break a list into multiple
lists (he initially proposed just breaking the list into two lists,
but others extended the idea to more). Damian didn't like the name,
and initially proposed
classify, which would return a list of array
references. Discussion continued for a while until Ralph Mellor
part as the name for this putative function, which Damian
leapt on with a glad cry.
This went on for a while, with extra features being proposed and other explorations of the possibilities including some rather nifty proposed shorthand/DWIMmery.
Meanwhile, Ken Fox wondered why we couldn't just implement classify/part/divvy as a normal sub and why everything had to be built into the first version of Perl 6. So Damian implemented it, but commented that "then the thousands of people who are apparently clamoring for this functionality and who would have no hope of getting the above correct, would have to pull in some module every time they wanted to partition an array." Ken was impressed, and asked for some commentary on how it all worked, which Damian provided. BTW, this code is really worth looking at for an example of the kind of power that Perl 6 will provide.
David Wheeler wasn't over keen on calling the function 'part' because part has so many different possible interpretations. It turns out that that's why Damian likes the name so much.
http://groups.google.com/groups -- Damian implements
http://groups.google.com/groups -- Damian implements
part with sane
http://groups.google.com/groups -- Damian explains it all
Michael G. Schwern asked people to `explain how having indexes in Perl 6 start at zero will benefit most users. Do not invoke legacy.' Answers ranged from the silly to the sincere. The best answer was "Because I [Larry] like it" which, I think, trumps everyone.
Joseph F. Ryan kicked off a discussion of the stringification of objects and references and offered his suggestions. Joseph leans toward having the default stringifications of objects and references provide information useful to the programmer. I agree with him (so, if you spot any bias in the upcoming summary that'd be because I'm biased). Michael Lazzaro explicitly brought up the distinction between "stringification for output" and "stringification for debugging", and came down in favor of stringification for output (heck, he even wanted references to be invisible to stringification). Piers Cawley told him he was wrong and appealed to the authority of Kent Beck (a Smalltalk and Java programmer, possibly not the best authority to choose). Michael then proposed a scheme involving subclasses of String, to provide cues for different stringifications, which John Siracusa thought was going rather a long way too far, coming down in favour of the "stringify for debugging" position. I'm not sure anything has actually been decided yet though. Tune in next week.
Simon Cozens asked for a translation of some Perl 5 style OO code into Perl 6, and Luke Palmer had a go at the task, then Larry came through with something a little more definitive (but not actually definitive just yet, I get the feeling that a few things are still in flux ... .)
Luke Palmer posted a fascinating document presenting a "new way of thinking about some constructs." and proposed some changes to help with consistency. The document covered junctions and classes, recasting them as representations of finite and infinite sets. Only Damian responded with a few corrections and clarifications noting that one of Luke's proposed changes was rather fundamental, and that he wasn't sure he wanted to make that change without some deep reflection (from someone) on how that would affect the junction types that Luke hadn't considered. Discussion continues.
Steve Fink is toying with adding OpenGL ops to Parrot.
Leon Brocard has used the native call interface features to add curses support to Parrot and offered a version of life.pasm that makes use of it.
The perl6-language crowd are currently working on string literals and stringification.
I'm bumping this one up the questionnaire queue slightly. I felt the need for some controversy.
- Who are you?
- What do you do for/with Perl 6?
- Nothing, except for disliking languages that are white space sensitive.
- Where are you coming from?
- I've been coding Perl since 1995. Joined p5p in 1996 or so.
- When do you think Perl 6 will be released?
- A usable release? Given the current rate in which apocalypses are produced, I'd say 2008. Give or take a few years.
- Why are you doing this?
- I adore Perl. Perl5 that is. Programming in Perl5 is like exploring a large medieval castle, surrounded by a dark, mysterious forest, with something new and unexpected around each corner. There are dragons to be conquered, maidens to be rescued, and holy grails to be quested for. Lots of fun. Perl6 looks like a Louis-XVI castle and garden to me. Straight, symmetric, and bright. There are wigs to be powdered, minuets to be danced, all quite boring. I haven't been impressed by new features yet, but I'm disappointed by what will be lost.
- You have 5 words. Describe yourself.
- My mind is twisted. Backwards.
- Do you have anything to declare?
- One of the great things about Perl5 is that I don't have to declare anything I don't want to.
Another week of writing on the train and, for a change of scenery, at my parents' house, fuelled, as usual by large amounts of tea.
Proofreading was once again down to Aspell and me. Any errors this week are probably my fault, it's about time I started accepting my responsibilities.
Thanks to everyone who has sent me questionnaire answers, I've got a queue of about four left so, if you work with Perl 6 (or, like Abigail, hate it) please answer the same set of questions Abigail just answered and send them to me at mailto:5Ws@bofh.org.uk. Thanks.
I got some mail last week from someone praising me for the summaries (thanks), but wanting to know how he could contribute his time and energy, so this week the chorus has a few extra lines in it:
If you didn't like the summary, what are you doing still reading it? If you did like it, 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 6.
- Get involved with the Perl 6 process. The mailing lists are open to everyone, http://dev.perl.org/perl6 and http://dev.perl.org/parrot are good starting points with links to the appropriate mailing lists.
- Send feedback, flames, money and or lucrative employment in the Doncaster area to mailto:email@example.com (No, I'm not unemployed at the moment, I just want to work nearer to home...)
The fee paid for publication of these summaries on perl.com is paid directly to the Perl Foundation.