The Perl 6 Summary for the Week Ending 20020908 Well, what a week it's been eh people? Larry's been telling the Slashdot crowd about quantum god and big knobs, there's been a call for Perl 6 programmers on Perlmonks (http://makeashorterlink.com/?L51631EB1), and the Octarine parrot took flight.
So, let's start with perl6-internals, as is traditional. The Octarine Parrot flies! Jeff Goff (who deserves to suffer for his parody of *Eight Days a Week*) announced Parrot 0.0.8, available from the usual places. This release includes: Working Perl 6 rules/patterns Multidimensional keyed access JIT for ARM processors Lexical scope operators Many bugfixes and smaller subsystems Mere moments after announcing the new baby, Jeff realised he'd made a mistake with the tarball's MANIFEST, and announced the release of Parrot 0.0.8.1, which has all the same features as 0.0.8, but a MANIFEST error has been excised. MANIFEST seems to be a source of problems, Tanton Gibbs had problems with it later in the week too. http://makeashorterlink.com/?A16623DA1 -- Announcement http://www.cpan.org/src/parrot-0.0.8.1.tgz -- Tarball Goal call for 0.0.9 Soon after the 0.0.8 announcement Dan asked us what we wanted to see in 0.0.9 and offered his list. The list got rather long as Sean O'Rourke, Steve Fink and Nicholas Clark all chipped in suggestions. The `long' list ended up as: * Exceptions * Initial PMC freeze/thaw API * Sub indicators in bytecode * On-the-fly bytecode section generation * Methods (in PASM and C) * Implementation of some methods for the Perl classes * Stashes * Resolve the prompt finalization problem * PMC name, implementation cleanup(*) * Filename, line number tracking * Careful elimination of compiler warnings * Rationalization of bytecode generation (*) The PMC issue was brought up by Steve. He pointed out that, right now we have a situation where theoretically language independent PMCs often refer to, and create, Perl specific PMCs on the fly, which seems rather wrong. http://makeashorterlink.com/?S12652EB1 http://makeashorterlink.com/?I13662EB1 -- Steve's list Approximate string matching in regexes Sean O'Rourke discoursed on edit distances and approximate matching, and offered a patch implementing an "rx_amatch" opcode. http://makeashorterlink.com/?U24663EB1 More regex stack manipulations Sean also implemented a couple of opcodes for manipulating the regex engine's stack; "rx_stackdepth Ix" and "rx_stackchop Ix". Dan thought that the semantics of "rx_stackchop" were slightly off, and that the instructions were actually intstack specific and should therefore be called "intstackdepth" and <intstackchop> respectively. Dan is also `really, *really* close to tossing the last pretense of being a stack-based system and move all the way to routine-based frames instead, which would definitely make some things easier.' (Whatever that means). Sean and Steve Fink both seemed to think that that may be a step too far, at least for something as backtrack heavy as the regex core. Steve thought he would rather not create a few thousand Exception or Continuation objects. Steve also made noises about encapsulating intstack.c's functionality in an appropriately named PMC. Later in the week, Steve delivered his patch to provide an integer array PMC, but wondered if it shouldn't be called an integer dequeue (a double ended queue). John Porter voted for dequeue. Leopold Toetsch wondered why the patch needed a pair of new ops, and questioned the entire premise of the patch, so Steve mounted a sterling defence of his patch. http://makeashorterlink.com/?P25663EB1 http://makeashorterlink.com/?J16621EB1 core.ops ARGDIR Leopold Toetsch kicked off a discussion of `the intended meaning of ARGDIR_IN/OUT'. I'm afraid to say that, whilst I understand the individual words in his message, I don't really understand the posting as a whole. Which is my own fault, and makes life rather hard for a summarizer. However, Nicholas Clark and Angel Faus seemed to understand him, and discussion ensued. http://makeashorterlink.com/?D27621EB1 -- Thread starts here. Parrot: maximizing the audience Jerome Quelin put the cat among the pigeons when he made a few observations about the perlcentricity of Parrot, and wondered what the benefits of making Parrot more explicitly vendor neutral. Jerome wondered `what could *we* do in order to open parrot to non-Perl centric people?' Markus Lair suggested renaming perl6-internals to `something better like "parrot internals"'. Sean O'Rourke wondered what effect this would have, apart from breaking his procmail setup. Dan thinks we'll probably shift to a more neutral list name eventually. John Porter claimed that `some folks seem to think that sufficient reason [to change] exists now.', and Dan pointed out that John didn't have to convince `some folks', he had to convince Dan. John then attempted to invoke Larry. John Porter reckoned that changing the list name would have "a huge psychological effect, at least outside our tight little club. But if that's only as far as you can see...". Dan responded with admirable restraint. Steve Fink is surprised at how little Parrot is tied to Perl 6, and noted that Perl 6 `mostly provides evidence that this isn't just an exercise in intellectual masturbation', and came down in favour of renaming the mailing list. Ask Bjoern Hansen popped his head up to say that it would soon be relatively easy to change the list name to, say, '[EMAIL PROTECTED]'. Andrew Kuchling -- one of the python-dev crew popped to talk about parrot-gen.py and why it's not being heavily developed. (From his point of view, the mailing list name is an irrelevancy BTW). Andrew made some good points about the fun and benefits of Parrot from the point of view of a Pythoneer (It isn't much fun, mostly because of culture shock and there don't appear to be any real benefits apart from the possibly chimerical cross-language stuff), and worried about the amount of optimization that was going on before we'd got any real languages implemented. Andrew also suggested making Scheme one of the driving languages for Parrot, based on its simple syntax and fully specced semantics. As a result of all this, Dan posted his list of `Parrot long-term goals/prospects'; a 9 point list, with footnotes about where he sees things going. I'm not going to summarize it because it's already its own summary. Read it. There was some discussion about what the eventual `pure parrot' build environment will look like, including some optimistic copyright lines... http://makeashorterlink.com/?G48625EB1 http://makeashorterlink.com/?E59651EB1 http://makeashorterlink.com/?J2A632EB1 -- A Pythoneer speaks http://makeashorterlink.com/?B2B631EB1 -- Dan's list Implementation of Lists for languages/scheme Jügen Bömmels offered a patch implementing Scheme pairs, using simple Arrays. Dan was impressed, and wondered how far we were from 'real' scheme. Jürgen thinks we're quite some way away; we still need symbols, strings, lexicals, functions, macros, continuations... Piers Cawley outlined an OO way forward using (initially) hashes, and proposed a 'SchemeObject' PMC, which would hide a lot of the common structural code needed for dispatching methods implemented in any of C/Parrot/Scheme. John Porter, at his patronizing best pointed out that the hash bashed approach seemed to be reinventing the wheel. http://makeashorterlink.com/?O2C651EB1 Teasing notes Dan announced that he was about to go dark for a while as a deadline of his had just got a lot closer. However, he dropped a list of hints about what was forthcoming. Bryan asked for some clarification of a few hints (but they're *hints*, they're supposed to be a bit vague), and Dan went and spoiled the mystery by giving him some. http://makeashorterlink.com/?Q4D625EB1 Tinderbox turning green Andy Dougherty noted that the recent work on portability and general lint gathering meant that we were well on the way to a green tinderbox (ie: automated builds are mostly working, yay!). Dan thought that gave him an ideal opportunity to break things again by adding exceptions to the mix. *Andy* then went a bit red, for assorted, faintly embarrassing reasons, the patch that was meant to turn things green had been applied and then inadvertently backed out. There's a moral here somewhere. Actually there was a spate of inadvertent unpatching last week. People are embarrassed and hopefully putting procedures in place to avoid another spate. http://makeashorterlink.com/?E6E631EB1 Perl 6 miscellany Steve Fink offered a portmanteau patch for the Perl 6 compiler, including such delights as a '-e' flag to perl6 so the one line script folks could play. (First person to do the RSA one-liner in Perl 6 gets *much* kudos from me). Sean wondered about a few of the other fixes, and between them he and Steve found and squashed a bug with here docs, and discussed ways of getting working Perl 6 patterns up and running. http://makeashorterlink.com/?Z6F654EB1 Meanwhile, in perl6-language Garrett Goebel reopened the `auto deserialization' thread from last week (which ended up with the concept of "my Date $date .= new('June 25, 2002')" as the Damian approved idea). Garrett's confusion seemed to hang on whether "my Date $date" and "my Date $date = Date->new()" were equivalent. If they were, then a class which implemented its own "operator:=" method could arrange things so that the originally proposed "my Date $date = 'June 25, 2002'" would work. Miko O'Sullivan proposed that, in the absence of a method name, ".=" should automagically call a "new_from_[class of object being passed]", noted that golfers would love it. The consensus seems to be against this particular bit of DWIMmery. A subthread of this mammoth thread concerned multimethod dispatch. David Wheeler wanted to know what it was, so Dan explained, and Damian pointed at a Perl Journal article on the subject. This subthread ended up spawning its own thread, when Miko wondered if multi dispatch/overloading implied anything about runtime/compiletime. Dan thought not, it was dependent on the language. Quote of the thread: "I can still remember the precise moment I first fell in love with polymorphism." -- Damian, in the TPJ article referred to. http://makeashorterlink.com/?B10721EB1 http://makeashorterlink.com/?N61742EB1 http://makeashorterlink.com/?H12722EB1 -- multimethods? http://makeashorterlink.com/?X53743EB1 -- TPJ article http://makeashorterlink.com/?R24712EB1 Class aliasing The `auto deserialization' thread also spawned a discussion of Class aliasing, but declined to change its subject line, making the life of a summarizer *so* much easier... Last week, Damian had proposed doing "class Date is Really::Long::Package::Name::Ugh", ie. subclassing the long name into a handy short name. Everyone else seemed to think he was proposing aliasing a class name (which Damian later denied). Uri Guttman certainly thought that Damian was talking about lexical aliasing of classes (my mailer picks his post as this week's base for this particular subthread). Trey Harris thought that Damian was talking at about subclassing, and proposed "my class Date is Really::Long::Package::Name::Ugh" which introduces a lexically scoped subclass. Nicholas Clark wondered if "class Date := Really::Long::Package::Name::Ugh" would express aliasing of classes. Damian thought it probably would, but noted that Larry hasn't said a definite 'yes' to class name aliasing. Brent Dax wondered if classes weren't in danger of becoming the `"new filehandles" -- relatively limited entities with no sigils that confuse the syntax horribly.' and pointed out an ambiguous case. David Wheeler apologised to everyone for confusing inheritance and aliasing in the first place, and the thread wound down to a close. http://makeashorterlink.com/?D25752EB1 "@array = %hash" Another thread from last week that rumbled on into this one. The discussion of when hashes could have pairs as keys wouldn't go away. Damian says that the "%hash = (...)" case is syntactic sugar and that having a pair in an even slot of such a list would probably be an error. I assume that this also applies in the case of "%hash = @array". In a subthread, Piers Cawley told David Whipp that he hadn't actually been joking when he proposed implementing the entire Smalltalk Collection hierarchy and making it available in core Perl 6. Luke Palmer liked the idea too. Dan saw no reason why such a thing should be impossible either... http://makeashorterlink.com/?A36721EB1 http://makeashorterlink.com/?T37723EB1 Atomicness and "\n" Last week Damian reminded us of "$roundor7 = rx/<<roundascii>+[17]>/", and Brent Dax wondered how one could be sure that "<roundascii>" is a character class. Luke wondered if it mattered. The thread eventually led Aaron Sherman to make a few proposals about User defined character classes in regular expressions. Deborah Ariel Pickett wondered why we still used "?" for non-greedy quantifiers, citing teachability reasons for why we shouldn't. http://makeashorterlink.com/?F28722EB1 http://makeashorterlink.com/?Y29713EB1 http://makeashorterlink.com/?P2A752EB1 Hypothetical variables and scope Aaron Sherman announced that he was working on a library of rules and subroutines for dealing with UNIX system files, mostly as mental exercise to help with his understanding of Perl's new pattern features. He wondered, in particular, about the scoping of hypothetical variables in the presence of lexicals of the same name. For some reason this turned into a minor argument about whether "my $x; / (\S*) { let $x = .pos } \s* foo /", from Apocalypse 5, was a typo for "my $x; / (\S*) { let $x := .pos } /". I'm not going to try to summarize the argument. http://makeashorterlink.com/?U3B725EB1 Argument aliasing for subs Pete Behroozi wondered about syntax for `allowing subroutines to have many different names for the same argument', citing CGI.pm as an example of such code in Perl 6. Damian thought that, if it were allowed, it would be done with properties "sub hidden (..., int $force is aka($override) ) {...}", (well, he did after he realised that his first post on this issue was the result of posting after travelling 14,000 miles and giving 93 hours of talks in the space of 18 days, and was somewhat flawed). All this cunning use of "is" led Erik Steven Harrison (who should fix his mailer so it does References or In-Reply-To properly) to wonder if properties weren't being a little overused, and wondered if the is/but distinction was still around. Damian thought not, and reiterated the difference between "is" and "but" and when you would use each of them. Erik also wondered what was wrong with "sub hidden ( int $force := $override ) {...}". Damian pointed out that it didn't play well with the defaulting operator, "//=" in parameter declarations. Peter Behroozi got confused about the difference between "$foo is named('baz')" and "$foo is aka($baz)". ("named" changes the externally visible name of a parameter, "aka" adds another external name for the parameter). The thread then morphed into a discussion of runtime and compiletime properties. If you've not seen such a discussion before, the whole thread is worth reading. http://makeashorterlink.com/?R5C741EB1 Perl 6 parser, built in rules, etc. Erik Steven Harrison wondered about backward compatibility issues with changing Perl 6's grammar when the grammar rules are so exposed to the user. Sean O'Rourke didn't think it was an issue yet. Dan told us that the eventual Perl 6 grammar would be maintained in a backward compatible way, with documented places for adding changes, and that this would be maintained for as long as Larry say so. http://makeashorterlink.com/?A6D721EB1 regex args and interpolation David Whipp confused the heck out of me when he asked about `regex args and interpolation'. I confess I can't for the life of me see what the issue is that he's trying to get at. Ken Fox seemed to understand him though, but wanted to know what the rule was that he was using in his example code, and proposed a couple of implementations of it. Nicholas Clark wondered about a section of Ken's post: { use grammar Perl::AbstractSyntax; $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) } Specifically, what was that S-expression doing there? Piers Cawley pointed out that S-expressions were a concise way of writing out an AST's structure. Nick agreed, but pointed out that it was still in the middle of a stream of Perl, but worked out that the "use grammar Perl::AbstractSyntax" part of Ken's code meant that all bets were off. At this point Nick's head threatened to explode at the wonderfulness of it all. http://makeashorterlink.com/?K1E762EB1 Defaulting params (reprise) Miko O'Sullivan doesn't like "sub foo ( $arg //= 1 ) {...}" for specifying default values for function arguments. He would rather have "sub foo ( $arg is default(1) ) {...}". Damian pointed out that "is default(...)" would be a compile time only thing, which didn't necessarily make sense. http://makeashorterlink.com/?D2F712EB1 Hypotheticals again Jonathan Scott Duff wondered some more about hypotheticals and "let". He wanted to know whether hypothetically binding to a lexically scoped variable would also introduce that name into the match object. A strict reading of Apocalypse 5 suggests that that isn't the case, which, Jonathan points out, causes the programmer a few headaches. Damian agreed that he'd like to see $0 contain keys for all the hypotheticals used in a match, whether they came from the lexical scope or not. Damian would also like them to turn up in "$o{'$name_with_dollar'" as well. So, it seems that everyone's assumptions are aligned and we can carry on. http://makeashorterlink.com/?Z20821EB1 First crack at Builtins.p6m Aaron Sherman decided that what the world needs now is, at least, a set of function signatures for everything that's in perl5's perlfunc listing. He's even had a crack at implementing those functions where possible. Aaron points out that he thinks of this file as documentation, not code. People were impressed, and there's talk of using it to compile down to the IMCC input as a base for hand optimizing. Aaron also released a second version with more functions implemented and a slightly different organization. http://makeashorterlink.com/?U31821EB1 http://makeashorterlink.com/?E32812EB1 More A5/E5 questions Jonathan Scott Duff asked a bunch of questions about the pattern engine, and got a bunch of answers. http://makeashorterlink.com/?R33822EB1 In brief Leon Brocard wondered if the concatenation bug was fixed yet... Leon also offered a patch implementing "chr", reckoning that, if we have "ord" then symmetry demands "chr". Dan applied it, and Jerome Quelin found a bug in his Befunge-93 interpreter which he thought was a bug in the chr implmentation, but turned out not to be. The Perl 6 compiler now does interpolated strings. Kudos to Joseph Ryan. Josef Höök had a problem with "key_next" not behaving as expected within multiarray.pmc. Tom Hughes pointed where expectation and reality differed, and harmony was restored. Kevin Falcone patched the glossary to include a definition of ICU. Mike Lambert is having problems with the Perl 6 compiler under Windows. Sean O'Rourke can't duplicate the problem. Anyone else tried this? More information is welcomed. Ken Fox and Damian continued their discussion of how one would munge the current Perl 6 grammar. John Williams wondered about doing reduce with "^+=". Damian can't remember what side he argued when it came up last October, but is now of the opinion that John's suggestion is a good idea. Mr Nobody suggested some changes to the Apocalypse 5 pattern syntax for reasons of length. Consensus seems to be that these changes aren't a good idea. Who's who in Perl 6 Who are you? I'm Dan and... I design virtual machines. What do you do for/with Perl 6? I'm designing the virtual machine to compile and run it. Where are you coming from? A place about 70 miles east of here. I started fiddling with computers with an Atari 800 (fully decked out with a massive *48*K of RAM!) a long, long time ago. That lead me to Atari BASIC, then to 6502 assembly, then to Forth. Then (briefly) to college and Pascal and PL/I running under VM/CMS on an OS/370 system. From there I bounced to COBOL (on both RSTS/E and OS/370) and OS/370 assembly, and then to C under RSTS/E. I disliked C on first sight (so of course that's what I spend most of my life writing now), and it didn't get any better on my Amiga, though AREXX there was rather nice. Wrote an article on AREXX for one of the now-dead Amiga magazines, too. My first real job in the industry was maintaining a horrid app written in BASIC on RSTS/E (with the new bits written in BASIC/PLUS 2.6, which was a nice dialect of BASIC, and something I still like better than C) and helping write a new system in Progress on Unix boxen. (DG AViiON systems with the 88K series processor. Now there was a sweet, and alas now dead, RISC processor) That lead to writing C and SQL code on a VMS system, at which point my fate was sealed, and I've been doing VMS admin and programming sever since. I first encountered Perl when looking for a guestbook for a webserver we were running on one of the VMS boxes. It was, of course, written in Perl, which meant grabbing a copy of perl. It was one of the 5.003_9x releases and, since Dec C was significantly pickier than any other C compiler at the time, I started shooting patches for it to Chip. That lead to my first XS module, and then to the second, and third (and eighth, and tenth, and...). Oddly enough, I wrote my first piece of Perl code about six months after my first patch to the perl core (Charles Bailey wrote the Perl pieces for the first module I did, and chunks of the XS) I ended up with the VMS maintenance hat for a while, which has since been passed on, and I got snared by the fun that was the first threading attempt for 5.005. I ended up volunteering to coordinate the Perl 6 development at TPC 4, since everyone more competent had the good sense to run screaming away from the job, and I've had it ever since. When do you think Perl 6 will be released? When it's done. Why are you doing this? Beats the heck out of me. Someone's got to. You have 5 words. Describe yourself. Tall enough, under the circumstances. Do you have anything to declare? Yes, absolutely. Acknowledgments This summary is dedicated to the memory of Gizmo, a cat of great character, who we had to have put down on Saturday at the age of 17. Chris Ball and Mark Fowler helped with proofreading this week. Thanks chaps. Once again, if you like the summary, please consider giving money to the Perl foundation at http://donate.perl-foundation.org/, your money will go to help fund the ongoing development of Perl 6. This week's summary was, once again sponsored by the O'Reilly Network who are paying the publication fee for the article directly to the Perl Foundation. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?