{ "thumbnail" : null, "tags" : [ "internals", "parrot", "perl-6" ], "image" : null, "title" : "This Week on Perl 6, Week Ending 2004-06-27", "categories" : "perl-6", "date" : "2004-07-02T00:00:00-08:00", "authors" : [ "piers-cawley" ], "draft" : null, "slug" : "/pub/2004/07/p6pdigest/20040702.html", "description" : " What's this? No! It can't be! It's a weekly Perl 6 Summary. What is the world coming to? Sorry, I can't answer that one, so I'll tell you what's been happening this week in perl6-internals. Bignums, licenses, pie As..." }
What's this? No! It can't be! It's a weekly Perl 6 Summary. What is the world coming to?
Sorry, I can't answer that one, so I'll tell you what's been happening this week in perl6-internals.
As you are no doubt aware, Python has bignums. And that means that, unless we want Dan to get a face full of Pie at OSCON this year, Parrot needs bignums too. Work on several fronts continued towards getting a bignum implementation for Parrot. Ideally, we'd like to just include GMP, but the license seems to require that the full source of GMP sip with any Parrot binary. Which isn't good when you're writing a VM that you'd like to be able to install on, say, a Palm.
Scott Bronson suggested getting in touch with the GMP developers to see if there was anything that could be done about it. He volunteered to be the liaison, assuming Dan was cool with it.
Meanwhile, Uri Guttman offered his 'stillborn' bignum implementation as a basis for our own bignum library. Leo commented that it might be a good idea in the medium to long term, but the Pie-thon is looming...
http://groups.google.com/groups?selm=a0611040bbcefb9fb77e6@%5B10.0.1.3%5D
http://groups.google.com/groups?selm=Pine.LNX.4.58.0406231105390.10311@sprite.sidhe.org
Remember Ion Alexandru Morega's string pmc that got Warnocked? Well, it got un-Warnocked this week. Dan liked it, so he checked it in. Congratulations Ion, don't forget to send in a patch to the CREDITS file.
http://groups.google.com/groups?selm=20040620075716.37958.qmail@onion.perl.org
Dan reminded everyone of the URL of the benchmark that's going to be run for the Pie-thon. If Parrot doesn't run it faster than the C implementation of Python, then Dan's going to get a pie in the face and he'll have to spring for a round of drinks for the Python Cabal (is there one? Could be a cheap round...). Of course, the plan is to have Parrot be faster than Python so Dan'll get to chuck a Pie at Guido. Either way, if you're at OSCON this year it should be fun.
Right now, Parrot is some way from, well, running it.
Leo announced that he will start a series of postings discussing the main features (and requirements) of the various benchmarks. He started with some notes on b6.py.
http://groups.google.com/groups?selm=Pine.LNX.4.58.0406210949440.10788@sprite.sidhe.org
http://groups.google.com/groups?selm=40D82C8F.1010903@toetsch.at -- Python needs exception objects
http://groups.google.com/groups?selm=40D84647.40407@toetsch.at -- Pie-thon and the recursion limit
Leo wondered about the current implementation of class name hashes. We have two such hashes, one for PMC base classes and one for dynamic PMCs. Leo thought this was suboptimal (and liable to make one of the Pie-thon benchmarks problematic.) Dan agreed that unifying the hashes (and renaming PMC classes to have Parrot prefixes (ParrotFixedSizeArray anyone?)) was the way to go.
http://groups.google.com/groups?selm=40D85C12.8010502@toetsch.at
Nicholas Clark was somewhat bemused by the choice of parameter order for the Parrot_PMC_set_intval_intkey function, which reverses the order of some parameters from the vtable version. He suggested unifying the two. Leo agreed that changing things round was the best bet and suggested that Nicholas go ahead and make the change to the extend.h interface. Dan didn't pipe up to say it was a bad idea. In fact, Dan didn't pipe up at all.
http://groups.google.com/groups?selm=20040624140935.GH81272@plum.flirble.org
Jeff 'japhy' Pinyan announced that he was currently completing work on an extensible, regex-specific, parsing module. Once it's finished, he's going to start work on writing a subclass that parses Perl 6 rules. He thought it might come in handy for people implementing Perl 6.
Luke Palmer thought it would be too; the grammar of Perl 6 is being specified in Perl 6 patterns. Initially it was hoped that Damian's Perl6::Rules module would be what was needed to bootstrap us, but 'serious bugs in the Perl 5 regex engine having to do with executing code within regexes' meant that Perl6::Rules can't do the job for us.
So, good luck Japhy, we're depending on you.
But, you know, no pressure mate.
http://groups.google.com/groups?selm=Pine.LNX.4.44.0406262313030.28219-100000@perlmonk.org
Leo asked for volunteers to implement a class to handle complex numbers (needed for Python) and to implement sort method(s) for the various *Array PMCs.
http://groups.google.com/groups?selm=40DEF36A.3080101@toetsch.at
Michele Dondi proposed syntax for adding 'command line' type switches to functions and methods which look almost, but not quite, entirely unlike Perl 6's named parameters. Brent Royal-Gordon pointed out that Michele's proposed
rename -v => 1, $orig, $new;
could be written, rather more Perl6ishly as:
rename $orig, $new :verbose;
Luke Palmer pointed out that wrappers could be used to add such extra named arguments to built ins, so the proposed behaviour for rename could be implemented as:
&*rename.wrap -> $orig, $new, *%opt {
say "Renaming '$orig' to '$new'" if %opt{'verbose' | 'v'};
call;
}
It turns out that neither of these were what Michele was driving at; it wasn't so much that new syntax was wanted, but that every built in have some kind of verbose version.
Meanwhile, as the discussion drifted in typical perl6-language style, Larry talked about 'allowing (at least) a single closure parameter to come at the end after the list parameter'. Simon Cozens doesn't seem to be maintaining his Ruby-o-meter any more, but if Larry were to make this change, the needle would definitely swing further in Ruby's direction.
http://groups.google.com/groups?selm=Pine.LNX.4.56L0.0406221118150.1885@worf.pcteor1.mi.infn.it
Michele Dondi wondered if Perl 6 would have a way of defining infix operators. Answer: Yes. The discussion pointed up some interesting scoping issues to do with macros too. But macros do that (as a look at any text on Common Lisp macros will show you).
http://groups.google.com/groups?selm=Pine.LNX.4.56L0.0406241206170.2865@q.pcteor1.mi.infn.it
Paul Hodges doesn't like the fact that a null character ("\0") is has a boolean 'true' value in Perl 5. He hoped that Perl 6 would change this. It appears his hopes are in vain. The consensus appeared to be that this kind of thinking is a (potentially) dangerous fossil from C type thinking. Jonadab the Unsightly One muttered something about 'comparing apples and orange leotards'.
The actually discussion was a little more discursive, of course.
http://groups.google.com/groups?selm=2820B295B95836498EED98D7A065C4F104DBD5D4@bremocmg-55
Rod Adams wondered how hash slicing will work in 'the glorious age of Perl 6'.
So do we all Rod. We hope it'll work really well. Apocalypse N will have detailed answers.
http://groups.google.com/groups?selm=40DB63D1.4070804@rodadams.net
The core Perl 6 language will allow one, and only one, postfix modifier per statement. Larry has said this several times. If you want more, modify the grammar yourself.
If that was the last time I find myself having to say this before we get a Perl 6 beta then I'll gladly eat a hat at the appropriate OSCON. You can hold me to this (but you'll have to pay my travelling expenses).
Argh! Unicode! But for once it's not moaning about Unicode operators, so that's a result.
Brent Royal-Gordon wondered about the behaviour of the .bytes, .codepoints, and .graphemes methods on the String object. He suggested that, in a list context, they return a list of the appropriate things in the string. Larry looked upon Brent's proposal and saw that it was good.
http://groups.google.com/groups?selm=40DDCE2A.1080806@brentdax.com
Alexey Trofimenko wondered about the lexical scoping rules associated with Perl 6's various control structures.
If you're unsure about them yourself, Luke Palmer's reply is an excellent overview of how such scoping works and of some of the rationale behind it.
http://groups.google.com/groups?selm=opr99iqr0esspxk8@s
Hopefully this summary marks a return to the good old days of weekly summaries, posted to the mailing lists near the beginning of the week.
Well, we can always hope can't we?
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:pdcawley@bofh.org.uk
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site