The Perl 6 Summary for the 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.
http://tinyurl.com/2h7c4
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".
http://tinyurl.com/3dd85
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://tinyurl.com/2s5ep
http://tinyurl.com/2djx8 -- 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.
http://tinyurl.com/2699g
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).
http://tinyurl.com/2ksox
http://tinyurl.com/3hyky
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.
http://tinyurl.com/2m7sf
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.
http://tinyurl.com/33r9w
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.
http://tinyurl.com/2xbn6
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"
http://tinyurl.com/2ev4n
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://tinyurl.com/3b4xo
http://tinyurl.com/2pt7b -- 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://tinyurl.com/37fls -- Leo implements at 3pm
http://tinyurl.com/24x22 -- 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.
http://tinyurl.com/3x5v3
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.
http://tinyurl.com/2zjgj
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.
http://tinyurl.com/yrt5c
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.
http://tinyurl.com/2o2yd
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.
http://tinyurl.com/35lfu
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://tinyurl.com/2vbp5
http://tinyurl.com/3cv6m -- 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.)
http://tinyurl.com/2rnd9
Ponie gets a development release
Arthur Bergman has made the second development release of Ponie, the
Perl5/Parrot hybrid. The initial response was positive.
http://tinyurl.com/2d3vp
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.
http://tinyurl.com/399rq
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://tinyurl.com/25r8x
http://tinyurl.com/32x4y
http://tinyurl.com/2kdmh -- 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.
http://tinyurl.com/3gjzz
PIR Syntax 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).
http://tinyurl.com/2n4ve
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!
http://tinyurl.com/28zgu
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.
http://tinyurl.com/2y8q5
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://tinyurl.com/2uem6
http://tinyurl.com/2fs7m -- 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).
http://tinyurl.com/yuke9
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:[EMAIL PROTECTED], 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"
