The Perl 6 Summary for the week ending 20030209
Welcome to the latest Perl 6 summary, your handy cut out and keep guide
to the goings on in the crazy world of Perl 6 design and development.
It's been a rather quiet week this week; only 75 messages in
perl6-internals and a mere 57 in perl6-language. So, at least it's
palindromic.
We start off, as is traditional, with perl6-internals
The 2004 Performance challenge
Dan announced that he'd made a bet with Guido van Rossum that Parrot
would be faster at executing a pure python benchmark of some sort to be
determined. The details of the challenge will be announced at OSCON 2003
and the results at OSCON 2004. Dan stands to lose $10 and a round of
beer for the Zope/Pythonlabs folks. (Dunno how many of them there are
though...). We don't know what he stands to win yet, but I'd hope 'beers
from each of the Zope/Pythonlabs folks' are included.
For some reason nobody commented on this.
<http://makeashorterlink.com/?K2C815C63>
More Parrot Objects
Jerome Quelin wondered how Parrot objects would handle property
inheritance. Dan pointed out that properties don't get inherited and
Jerome realised he meant to ask about attribute inheritance. Attributes
*are* inherited but are mostly invisible to any methods but the methods
of the class that defines the attributes (though they will be accessible
(presumably through reflection)).
In another subthread, we got confused by multimethods.
<http://makeashorterlink.com/?O6D816C63>
<http://makeashorterlink.com/?O4E822C63> -- Multimethods
Bytecode Metadata
James Michael DuPont wanted to know what had been decided about Bytecode
metadata and outlined the things that he'd like to know about a given
bytecode. Leo T�tsch reckoned that what James wanted was either in the
bytecode right now, or was handleable by the framework that was in
place. He pointed James to docs/parrotbyte.pod in the Parrot
distribution.
Further discussions centred on the *amount* of metadata and whether this
would affect loading speed and efficiency, or get in the way of the
desired 'mmap and go' principle. J�rgen B�mmels pointed out that we also
had to be capable of passing meta data from a compiler 'through' IMCC
and on to the final bytecode. There was also a touching reunion between
James Michael DuPont and Gopal V. Ah...
<http://makeashorterlink.com/?E41925C63>
Multi programming language questions
Phil Hassey has been lurking, fascinated on the internals list for a
couple of months. This week he broke the silence by asking a couple of
questions about cross language function dispatch, string compatibility
and global scopes. For instance, PHP, Common Lisp and others are case
insensitive about functions. Which is okay when you're calling such a
function from a case sensitive language, but can be tricky if you call
out from a case insensitive to a case sensitive language. Dan thought
that there wasn't going to be much that could be done about this problem
(at least, not transparently) but seems to think that the other issues
raised shouldn't be too problematic.
<http://makeashorterlink.com/?R32931C63>
Random questions
David popped up and, after remarking on the amount of progress Parrot
had made since he last looked at it, had a few questions about various
bits and pieces. Leo and Dan provided a bunch of good answers.
<http://makeashorterlink.com/?X63912C63>
A Scheme for extending core.ops
Leo T�tsch seems to have got bored of 'just' being the Patch Monster and
has been producing some discussion documents proposing all sorts of
useful tricks for improving the design/speed/extensibility of Parrot's
internals. This week he turned his attention to core.ops. His plan
involves a way of reducing the size of core_ops, improving cache
locality and generally solving a raft of problems I didn't even know
Parrot had. His new scheme allows for a small core.ops, easy extension
and no execution speed penalty for non core ops. As is usual with Leo's
stuff, the scheme came with code. Gregor had a bunch of observations and
suggestions and he and Leo thrashed out a slightly modified scheme for
going forward.
<http://makeashorterlink.com/?P54921C63>
Week of the alternative runloops
Leo T� offered a couple of different core runloops this week. First up
was the Computed Goto Prederefed (CGP) runloop which, essentially
combined a two runloop optimization techniques to provide what can only
be described as massive speedups. The -O3 compiled version ran
parrot_mops 6 times faster than the basic 'fast_core' and more than 3
times faster than the previous fastest core. People were impressed.
A few days later, Leo reached into his bag of tricks and pulled out the
CSwitch runloop that did predereferenced dispatch via a big C switch
statement. This loop is about 50% faster than the basic fast_core loop,
but slower than all the computed goto dispatched loops. At this point
Jason Gloudon pointed out that predereferencing can cause problems in a
multi threaded environment.
Quote of the Parrot development process so far:
"I'm a really bad C programmer" -- Leo T�tsch
<http://makeashorterlink.com/?R15942C63>
And that about wraps it up for perl6-internals this week. Dan's been
busy in Sebastapol with the Perl 6 Cabal thrashing out the design of
Perl 6 functions and other bits with Larry, Damian, Allison and
chromatic, which probably explains why he's not been driving the mailing
list for the week.
Meanwhile in perl6-language
It's been even quieter on the language list. Mostly interesting though.
Shortcut "?="
Miko O'Sullivan proposed a new assignment operator, "$var ?= $x : $y",
equivalent to "$var = $var ? $x : $y". It was pointed out that, for
correctness that should be "??=". Deborah Ariel Pickett wondered what
was the need for such an operator and couldn't imagine ever needing such
an operator.
<http://makeashorterlink.com/?V26962C63>
Language Discussion Summaries
Miko O'Sullivan proposed that members of the language list provide
summaries of the discussions in the group [What's this? Chopped liver?
-- Ed]. The idea being that each summary would describe a proposed idea
and then summarizes the list's feelings on the idea, and would be posted
on a website. The idea was basically well received, then the list fell
to quibbling about format, whether summaries should be posted to the
list where they could be picked up by the list summarizer, and whether
we were just reinventing RFCs all over again.
As of now, the only summary that actually exists is Miko's summary of
the proposed "??=" operator. Which I hadn't even bothered to read until
I came to write the summary.
<http://makeashorterlink.com/?T27923C63>
<http://www.idocs.com/perl6/> -- Summaries website
Newline as a statement terminator
St�phane Payrard confessed that he would like newline to be a statement
terminator everywhere it can be. Everybody hated it. Deborah Ariel
Pickett came up with a neat example of why it was a really bad idea with
a simple ambiguous piece of code:
sub foo
{
print "abcde"
if $condition
{
print "fghij"
}
}
which could mean either:
sub foo {
print "abcdef" if $condition;
return sub {
print "fghij";
}
}
Or
sub foo {
print "abcde";
if $condition {
print "fghij";
}
}
And disambiguating with indentation is way too Pythonesque for many.
<http://makeashorterlink.com/?L18921C63>
Arrays vs. Lists
In his quest to exhaustively document what is known about Perl so far,
Michael Lazzaro asked for a definitive answer to the question "What's
the difference between an array and a list in Perl 6"?
Various answers were given but I think Uri Guttman came up with the most
succinct pair of definitions, which reduce to 'lists are read only,
arrays are read/write'. (That's the data structure itself, not the data
structure's contents, "($a, $b) = (1, 2)" doesn't modify either list,
but it does modify the lvalues in the left hand list).
<http://makeashorterlink.com/?J49912C63>
<http://makeashorterlink.com/?I1A923C63> -- Uri's definitions
Announcements, Acknowledgements and Trip Planning
This week's summary was prepared in the comfy chair with distractions
from cats, irc, former employers, bugs and poring over maps of the
Eastern Seaboard.
We're coming to America. This year, making a virtue out of a necessity
we're going to give ourselves a good long holiday in the States. We'll
be flying out to Boca Raton for YAPC, then taking a road trip up through
the Appalachians to New England, possibly swinging into Canada before
coming down through Michigan to Chicago and taking a slow train to
Portland, OR for The Perl Conference. If it looks like you might be on
our route, drop me a line...
Proofreading services were provided by Aspell and me. (I could lie and
say that they were provided by Leon Brocard, enabling me to work his
name into the summary somehow, but I think I'll do it in a parenthetical
comment instead.)
If you appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
<http://donate.perl-foundation.org/> and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. <http://dev.perl.org/perl6/> and <http://www.parrotcode.org/>
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, job offers or the secret of eternal
immaturity to [EMAIL PROTECTED]
This week's summary was sponsored by Darren Duncan. Thanks Darren. If
you'd like to become a summary sponsor, drop me a line at
[EMAIL PROTECTED]
--
Piers
