This week on Perl 6, week ending 2004-03-14
Another week, another summary. It’s been a pretty active week so, with a cunningly mixed metaphor, we’ll dive straight into the hive of activity that is perl6-internals.
Benchmarking
Discussion and development of Sebastien Riedel’s nifty Parrot comparative benchmarking script continued. Leo suggested a handy config file approach which would allow for adding benchmarks in other languages without having to change the script itself.
The initial results don’t look good if you’re name’s Dan and you want to avoid getting a pie in the face at OSCON though, as Dan pointed out, there’s a few tricks still to be played in this area. Anyway, benchmark.pl is now in the CVS tree if you want to play with it.
Speeling mistacks
The ever helpful chromatic applied Bernhard Schmalhofer’s patch to fix up an endemic speling mostake in some tests. Apparently DESCRIPTION isn’t spelt “DECSRIPTION”.
Dates and Times
Discussion of parrot’s handling of dates and times continued this week too. Joshua Hoblitt who works on DateTime.pm (a very handy base for doing date/time handling in Perl 5, you should check it out) said that the DateTime people really, really want is “an epoch that’s absolutely fixed across all platforms.”
There was also some discussion of where the opcode/library boundary should be placed, with some arguing that the likes of strftime should be implemented as opcodes. Melvin Smith responded to this with what seems to me to be a very telling point: “If we cannot provide a decently performing VM that makes people want to write stuff in bytecode (or compiled to bytecode) we have failed anyway”.
Toward the end of the week, Dan announced some decisions and questions. Larry had a few quibbles, but otherwise there have been no other comments. Personally, if I never hear the phrase “leap second” again, I’ll not be unhappy.
http://groups.google.com – Dan’s decisions
Alternate function calling scheme
Dan has come to the view that we need an alternative, light weight, calling convention for calling vtable opcode functions; the idea being that this should speed up objects a tad. He asked for suggestions.
Leo Tötsch wasn’t convinced that we really need special calling conventions, arguing (with numbers) that it would be best to concentrate on speeding up object instantiation by optimizing object layout. Simon Glover agreed with him, noting that simply changing the Array that used to store class, classname and attributes gave him a speedup of around 15% on the object benchmarks.
Summary Correction
Last week I said that we can’t yet do delegated method calls for vtable functions with objects. Leo pointed out that, actually, we can now. Leo also disclaimed any responsibility for helping Brent Royal-Gordon (né Dax?) fix up the support functions for Parrot::Config, though Brent later claimed that he was merely the person doing the typing…
Jerome Quelin noted that parrotbug has already reached version 0.2.1 (I wonder what its version will be when Parrot 1.0.0 gets released).
Dead Object Detection improved
Not content with his work on everything else this week, Leo has revisited the Garbage Collector and tracked down a couple of bugs including a really nasty sounding one that caused disappearing continuations. He even isolated the problem with a test.
Rejigging trace output
Leo’s rearranged the output of parrot -t slightly in an effort to make it more readable. Jens Rieks was impressed and pointed out a couple of issues, which Leo quickly fixed.
Namespaces in IMCC
Dan’s day job continues to be a handy driver of Parrot development. This time he needs to make use of namespaces and, whilst namespaces themselves aren’t completely nailed down yet, there’s enough there that the time has come to work out the syntax for working with them in IMCC. He proposed
.namespace [foo; bar; baz]
as a way of setting the current namespace to foo::bar::baz (in Perl style, your language may vary). Leo was okay with that as far as it went, but pointed out that things were slightly more complicated than Dan’s proposal implied. He suggested that the time was right to sort out the duties of the PIR assembler towards variable names, name mangling, lexical scopes, namespaces, globals and all that good stuff. Dan punted slightly on this latter part, saying that, in general it shouldn’t be the assembler’s job to track them. The current namespace would simply be used as the namespace in which to place any subsequently defined functions. There was the sound of a hand slapping a forehead from Austria, and Leo went off and implemented it.
New library, objecthacks.imc
In the process of redoing the Parrot Data::Dumper to use objects, Jens Rieks built a library of helper functions to make object usage easier, so he submitted it to the list as a standalone library. Leo checked it in, you can find it at library/objecthacks.imc
Implementing stat?
Leo Tötsch proposed a stat opcode for finding out about things in the filesystem. He outlined a proposed interface. Dan agreed that we’d need something, but that Leo’s proposal was far too unix-centric to work for a cross platform platform like Parrot. He suggested going back to first principles and working out what information would be needed (and possibly available). He also said that one of his guiding principles for Parrot was that he would “rather not re-implement and expose 35 years worth of ‘Whoops, that turned out to be a bad idea’ crud.”
Josh Wilmes took this opportunity to remind everyone of the proposed miniparrot and pointed out that, if we want it to work again, there needs to be a smooth way to exclude opcodes or PMCs that won’t work in miniparrot’s environment. Dan agreed strongly, reminding everyone that miniparrot is intended to be the basis of Parrot’s eventual build system. (The process will go: Platform specific shell script -> miniparrot -> parrot).
http://groups.google.com – Don’t forget the miniparrot!
IMCC and method calls
Leo announced that he’d expanded IMCC’s PIR parser a bit, allowing you to write:
obj.method(args)
ret = obj.method(...)
(retvals) = obj.method(...)
where method is a label.
A couple of hours later Dan posted a design spec for how he wanted method calls to work in IMCC:
object.variable(params)
object."literal name"(params)
Methods would be declared like:
.pcc_sub foo prototyped, method
.param pmc foo
.param pmc bar
...
.end
Declaring a method in this way would also create a local self which points to the object PMC register. What do you know, Leo implemented it all. There is also a more ‘explicit’ way of making method calls for those occasions when you need more control. Check the docs/examples for details.
http://groups.google.com– Leo implements at 3pm
http://groups.google.com – Dan designs at 5pm
Data::Dumper test version
The excellent Jens Rieks posted a test version of his object oriented version of library/dumper.imc and asked for comments. (Mine was “Wow!” but I didn’t post it to the list ‘til now). Leo wondered if he should add it to the repository or wait for it to get rejigged to take account of all the improved object syntax changes that had gone into IMCC. Jens told him to hold fire until he’d converted everything to the new syntax.
Months that Do The Right Thing
Dan’s rejigged the date decoding logic to return months in the range 1-12 instead of 0-11. And there was some rejoicing.
Problems calling methods on self
Jens Rieks discovered that he couldn’t call self."method"(...), or even compile it for that matter. It turned out to be a problem with the grammar. Steve Fink provided a grammar fix, Leo tracked down a problem with registers not getting preserved properly, and there followed some discussion about the ambiguity of . being used for both method calls and string concatenation. Luke Palmer suggested (and Melvin Smith agreed) that it was probably better style to use the concat op anyway.
Object instantiation/initialization
Dan’s currently seesawing about how to customize object creation by passing arguments to the constructor function. At present, you create an object by calling the class’s init method, which doesn’t take any arguments, and then call an object method with appropriate arguments to do any other setup that’s dependent on the arguments if you want to. Dan outlined three ways forward and asked for opinions.
Ponie problems
Nicholas Clark posted to say that Ponie was having problems when built using Parrot’s garbage collection. After some encouragement from Leo, he managed to write a short test case that showed the issue in a few lines of C. Leo proposed a solution, but Nicholas and Arthur Bergman (Ponie’s core team) weren’t happy with either option. This hadn’t been resolved by the end of the week.
Why does Parrot have so many opcodes?
Matt Greenwood wondered why Parrot had so many opcodes, and what the criteria are for adding or deleting ops. Various rationales were offered. Dan’s explanation was probably the most comprehensive though. Apparently, Parrot has opcode explosion issues because there’s no runtime op variance and if you want to know what that means, read Dan’s post.
http://groups.google.com – Dan explains it all
Parrot grabs SIGINT
Arthur “Poniemaster” Bergman noticed that Parrot grabs SIGINT, which makes some of Ponie’s signal handling code break. He wondered if this was something that needed fixing, or a deliberate design decision. Dan says that, eventually and by design, Parrot will grab all the signals, though not necessarily in the embedded case (which is what Arthur is using of course.)
Ponie gets a development release
Arthur Bergman has made the second development release of Ponie, the Perl5/Parrot hybrid. The initial response was positive.
Per-class attribute offsets
Peter Haworth had a bunch of questions and worries about using numeric offsets to get at class attributes. Dan tried to reassure him, but Oli came up with a worrying corner case. Dan didn’t think it was that big an issue, but confessed that it’s still a worry.
Using Ruby Objects with Parrot
Poor old Dan; once you’ve got some bits of objects done, it just means everyone wants more from you. Mark Sparshatt wondered how to handle languages like Ruby, where a class is also an object, which seems to run counter to Parrot’s scheme using ParrotClass and ParrotObject PMCs where a ParrotClass isn’t a ParrotObject. He suggested three ways forward.
Summarizing this stuff is Hard. One one level you can reduce the issue to a couple of sentences, but understanding those sentences involves rather a lot of underpinning knowledge that I’m not sure I have. I just know that life’s an awful lot easier if I can treat classes as objects.
Dan tried to wrap his head ‘round things and posted a summary of his initial understanding of what a metaclass is. He wondered if we’d need to have a ‘call class method’ operation. Paolo Molaro pointed out that most of this stuff only becomes a real issue when you have to deal with objects implemented in one language calling methods on objects implemented in a different one. Leo Tötsch explained Parrot’s current (somewhat confusing to these eyes) hierarchy where:
- A ParrotClass isa delegate PMC
- A ParrotObject isa ParrotClass
- A HLL class isa ParrotClass and a low-level PMC object
- A HLL object isa all of above
Piers Cawley thought that having ParrotObject inherit from ParrotClass rather than vice versa seemed somewhat perverse. He also argued that method dispatch should be decoupled from method lookup. I think he and Leo failed to communicate.
Mitchell N Charity was good value on all this as well; definitely worth reading if you’re into the theory behind OO should work.
http://groups.google.com – Mitchell N Charity on Objects, Classes and MetaClasses
Configure changes
Brent announced that he’s been making some significant changes to Configure in the last week or so. He posted a big list. Leo liked what had been done so far, but thought the process needed more steps to probe for more stuff.
PIR changes
Leo announced that he’s added some syntactic sugar to PIR; you can now write:
$N0 = sin 0
$I0 = can $P0, "puts"
$I0 = isa $P0, "scalar"
etc, and they’ll be magically converted to
PARROT_OP lhs[, args]
which is rather handy (with some ugly cases: P1 = invoke being the example Leo came up with).
OO version of Data::Dumper
On Sunday, Jens Rieks released his OO version of Data::Dumper, along with a couple of helper libraries, including a rewritten objecthacks.imc, now called objects.imc. Leo committed it (and a followup bugfix) promptly and Parrot now has its first OO application/library. Yay Jens!
Meanwhile, in perl6-language
Magic blocks
Remember last week I implied that magic UPPERCASE blocks for things like BEGIN, CHECK, INIT etc were being replaced by properties on variables? Well, I was wrong. We keep magic blocks but we also get handy properties for attaching actions to variables.
In fact, the handy properties were first discussed in April last year, as Larry pointed out.
Mutating methods
Juerd wondered about the possibility of mutating and non mutating methods in Perl 6. Consider the Perl 5 functions chomp and lc. chomp potentially modifies its argument, whereas lc returns a new string. Juerd liked the idea of having mutating and non mutating versions of both chomp and lc (and other such string methods). He proposed using
$aString.lc; # Non-mutating
$aString.=lc; # Mutating
The general response to this was favourable.
The thread sparked a discussion of Perl 6 Rules and hypothetical variables (which just makes me hope Damian gets Perl6::Rules written really soon).
Larry posted a chunk of stuff from the forthcoming Apocalypse 12 that looks rather neat. Then he and Simon Cozens started talking Japanese and my head started spinning.
http://groups.google.com – Larry tells us more about A12
Operators that keep going and going…
Carissa wondered if Perl 6 would have what she called ‘persistent’ operators, so that you could do:
my $a = 10;
my $b = 5;
my $c = $b + $a;
print $c; # 15
$a = 8;
print $c; # 13
Several people pointed out that it’s already possible to do this sort of thing in Perl 5 so it’d be a big surprise if you couldn’t do the same thing in Perl 6. (See perldoc overload in the section “Really symbolic calculator” for details).
Announcements, Apologies, Acknowledgements
I’ve had it with discussions of whether Unicode’s a good idea or not, and from this summary onwards I’ll not be including any such discussions unless Larry does an implausible volte face. That is all.
Now I can go back to being anxious about my stepdaughter who’s been in labour for rather a long time.
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:p6summarizer@bofh.org.uk, or drop by my website, maybe I’ll add some content to it this week.
http://donate.perl-foundation.org/ – The Perl Foundation
http://dev.perl.org/perl6/ – Perl 6 Development site
http://www.bofh.org.uk/ – My website, “Just a Summary”
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub
