To see what is currently happening visit http://www.perl6.org/
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 right thing when it came 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.
Lots of things happened with IMCC this week:
ret early 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) have
been discussing several of these issues.Gopal V wondered if 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 if 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!)
rx_* ops, which are the ones
that have the problems..sub/.end pair.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, 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...
OUT label clashes with something in the
windows header files. The patch got applied.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' will look like.
groups.google.com[63.120.19.221]
logical_not issueDavid 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 todo
list. David wondered if 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 and, or and 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.
groups.google.com[63.120.19.221]
groups.google.com[63.120.19.221]
Michael Collins asked about the structure of the Parrot development organization, and Dan provided some answers. My favourite 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....
groups.google.com[63.120.19.221]
groups.google.com[63.120.19.221]
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 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 a certain amount of 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 \0o[101] or
\c[0o101] (I like the second better...)
\c[...]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
you do: 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 which would be to grep
as unless is to if. Nobody seemed to like the name that much,
though most seemed to think the idea was sound. Michael Lazzaro
suggested divvy which would 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
suggested 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 wondered 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 clamouring 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.
groups.google.com -- classify
groups.google.com -- Damian implements part
groups.google.com -- Damian implements part with sane
formatting
groups.google.com -- 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 towards 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 favour of stringification for output (heck, he even wanted references to be invisible to stringification). Piers Cawley told him he was very 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.
Abigail
Nothing, except for disliking languages that are white space sensitive.
I've been coding Perl since 1995. Joined p5p in 1996 or so.
A usable release? Given the current rate in which apocalypses are produced, I'd say 2008. Give or take a few years.
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.
My mind is twisted. Backwards.
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:
The fee paid for publication of these summaries on perl.com is paid directly to the Perl Foundation.