Good evening. You find me typing away in a motel room on the edge of the Lake District on the shortest night of the year. I suppose, by rites, I should be spending the night by some stone circle drinking, dancing, and generally making merry, but as I'm a teetotalling, unfit, atheistical nerd with a mission to summarize, I'll skip that and plough straight into the activities of another arcane sect. Yes, it's perl6-internals again ...
Andy Dougherty sent in a patch adjusting the Parrot README so that it accurately reflected the toolset needed to build parrot. For some reason, as well as the requirement for a C++ compiler if you want to build the ICU library, we've moved to needing Perl 5.6.0 rather than 5.005. Nicholas Clark suggested that, rather than bumping the Perl version requirement, we bundle appropriate versions of modules Parrot required, but chromatic thought it better to check the for the correct versions of said modules at Configure time and bail out if they weren't there.
There was further discussion about whether going to Perl 5.6.0 as a requirement was the right thing to do -- the issue is that some OSes (FreeBSD and Solaris 8 were cited) still only ship with 5.005 family Perls. My feeling (which I didn't mention in the thread, more fool me) is that, as eventually the goal is to eliminate the need for Perl at all in the build process, requiring 5.6.0 rather than 5.005 isn't exactly the end of the world.
Someone finally summoned up the tuits to fix the OS X build. Step forward Nicholas Clark and accept your plaudits.
Dan announced that he was about to make some changes to the repository, including establishing a basic set of PMC classes. Matt Fowles wondered about Array PMCs, which seemed to be missing from Dan's list. Dan agreed that they should be rationalized as well.
Bernhard Schmalhofer suggested adding a complex number class to Dan's basic menagerie, but Dan was unconvinced.
Nicholas Clark was moved to growl by a section of include/parrot/string.h that used a #define to define a type. Actually, he was moved to 'swearing and cursing and time wasted grepping to find out what a STRING is'. Dan agreed that this was bad and decreed: 'Typedefs for types, #defines for constants and bizarre (temporary!) debugging things.'
During a lull while Leo Tötsch was away at a conference, Dan mused on the next release of parrot. His goal for that is a rejig of classes/, aiming to make sure that all the PMCs we want are in and working, and that the ones we don't care about are neatly deprecated.
Stretching the definition of 'small' somewhat, Dan asked for volunteers to implement the missing PMCs detailed in PDD 17. He reckoned it should be 'fairly straightforward'. A new entrant in these summaries, Ion Alexandru Morega took a crack at the String PMC and posted a patch to the list which was promptly ignored. Which seems a little unfair really.
Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up to the plate. Leo suggested that, rather than starting from types/bignum.c, it might be better to use an existing, maintained, maths (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will be a cold, cold day in hell when I start abbreviating 'mathematics' as 'math'. Ahem.) package. Dan worried about license compatibility; the proposed GMP package is licensed under the LGPL which may (or may not) be compatible with Parrots Artistic/GPL dual licence. After a closer reading he reckoned that GMP's license is definitely incompatible with Parrot.
Matt Fowles posted a patch implementing Fixed Array classes. Dan applied it. Leo wondered about the patch's use of malloc(3) instead of Parrot's memory management. Dan wasn't worried in the case of fixed size arrays.
Fresh from his Fixed Array triumph, Matt Fowles posted a patch implementing naive Resizeable Arrays. Leo thought it a little too naive, and worried about duplication of existing functionality. Dan wasn't worried about the naivete, or the duplication of functionality. He pointed out that it was more important to get something which could be improved and that the duplication was okay given that the idea was to get a standard framework in place and then eliminate the duplication. (I admit that I'm a little surprised to hear Dan, who's normally a strong advocate of up front design, preaching the refactorers creed...)
Nicholas Clark wondered how to go about making a PMC, pointing out that the documentation is rather sparse. He had a bunch of questions for the Men Who Know. Matt Fowles and Dan Sugalski came up with answers. Leo wrote a document and checked it in as docs/pmc.pod. If you're interested in implementing a PMC, you'd do well to read it.
Continuing his campaign to spec out more and more of Parrot, Dan set to work on defining and documenting Parrot's handling of slices and iterators. It appears that array slicing syntax is one of those topics where you can't please everyone; Dan's post generated a good deal of discussion.
Dan added more in a later post and, in later post still, threw up his hands and asked for a volunteer to define the iterator protocol.
Having a syntax is all very well, but you need to define what it means too. So Dan did.
Argh! Unicode! Run away!
Dan posted the rationale for his design for Parrot's strings, in particular the decision to defer conversion of strings to Unicode. Amazingly, there was no argument.
Dan posted "the official, 1.0, final version" of the Parrot Strings document. Modulo a caveat about the use of 'grapheme' it looks like this one might stick.
Having got a Strings spec that people seemed to agree on, Dan went on to discuss how parrot's strings should work internally. He and Mark A Biggar ironed out a few wrinkles.
Dan asked for volunteers to get build_tools/pbc2c.pl working and/or write a test suite for it.
Leo's extended Parrot's
open opcode to allow for opening a unix pipe rather than simply a file.
There were issues with passing arguments to the the program being piped to/from,
but Dan came up with a suggested
backtick opcode whose semantics were liked,
but whose necessity and name were called into question.
Leo pointed out that the major credit for the functionality belongs to Melvin Smith; Leo merely implemented a means to get at the functionality from parrot code.
Nick Glencross wants us all to look at his shiny SDL teapots; the poor man's wife is apparently underwhelmed, so let's all make with the "Wooo! Well done that man!".
Dan toyed with adding a couple of non-flowcontrol min/max ops along the lines of
min $P1, $P2, $P2 # Sets $P1 to the lesser of $P2 and $P3
He noted that such ops would make some of the code he was generating much simpler, but wasn't sure if that particular itch needed to be scratched with a new op. He was rapidly convinced that it wasn't a good idea (I wouldn't be surprised to discover that he was convinced of this about 10 seconds after he hit the 'send' button for the thread's root message).
Steve Fink attempted to resurrect the idea by proposing a single
choose operator, which looks rather neat, but is probably still unnecessary.
Given enough time, any thread on perl6-language will end up arguing the toss about Unicode operators.
Perl 6 will have Unicode operators. It will also have ASCII equivalents. You're highly unlikely to convince Larry to change his mind on this.
Ingo Blechschmidt made a convincing argument for making the subroutine wrappers discussed in Apocalypse 6 into first class objects. (Well, I was convinced.)
Later in the thread, Dan invoked "our Quantum Ninjas".
Aldo Calpini asked for assistance in coming up with a simple, yet impressive, example of Perl 6 grammars. I'm not sure anyone's come up with a suitably satisfactory example yet, but Garrett Goebel pointed out that Damian has released Perl6::Rules. And there was much rejoicing (well, in this summarizer's head there was).
In a message dated 28th of January 2004, Damian Conway addressed the issue of junctive lvalues.
This summary would have been a great deal trickier to write it if weren't for the efforts of Jeffrey Dik, Sebastian Riedel, Brent Royal-Gorden and Robert Spier, all of whom helped me fill in my message archive while my main server is away being fettled.
Computer menders and British Telecom willing, next week's summary will actually happen. If it doesn't, I'll be along in a fortnight.
If you find these summaries useful or enjoyable, you can show your appreciation by contributing to the Perl Foundataion to help support the ongoing development of Perl. Money and time are both appreciated. Or you could drop me a line at mailto:firstname.lastname@example.org; I'm always happy to get feedback.
http://donate.perlfoundation.org/ -- The Perl Foundation