Front page | perl.perl6.internals |
Postings from August 2002
Perl 6 Summary for week ending 20020728
August 1, 2002 02:46
Perl 6 Summary for week ending 20020728
Message ID: email@example.com
Here goes, better late than never.
Perl6 Summary for the week ending 20020728
Better late than never, it's the return of Piers Cawley's Perl 6
summaries. First I'd like to thank the very lovely, and worthwhile Leon
Brocard for his excellent job of producing last week's summary. Any
suggestion that I only asked him to do the job because it made the job
of mentioning his name that much easier this week will be laughed at.
The Perl Conference
Last week saw the 6th O'Reilly Perl Conference. I wasn't there and am
only slightly jealous. As well as producing parodies of the Apple Switch
ads and other amusing things, people talked about useful and interesting
stuff, including Perl 6 and Parrot. Sadly there are no "switch/parrot"
or "switch/perl6" spoof ads. Yet. However, Leon Brocard has made the
slides from his `Targeting Parrot' talk available. Leon is particularly
proud of the typography, apparently.
Apart from the conference, most of the Perl 6 action has been in
perl6-internals, so we'll start there.
Scott Walters thought that "Keys are not needed." and claimed that they
were a premature optimisation which should be done away with to prevent
ugliness. Dan pointed out that Scott had missed the important case where
data was inherently multi-dimensional. Josef Höök had a dream about
morph chains and caching. Scott pressed his case once more and Dan
replied pointing out a few misapprehensions on Scott's part and
generally mounting a sturdy defence of the status quo, which caused an
outbreak of agreement and general understanding. Scott patched up
docs/vtables.pod to incorporate the information in this thread. Yay
Scott! He then implemented multilevel key lookup for arrays. Double yay
Meanwhile, over in a side thread, Ashley Winters proposed `ParrotTuple'
as a possibly useful PMC, Leon Brocard concurred, suggesting that,
because it should be a relatively simple PMC to implement it'd make a
great learning project (and, potentially, a great teaching project once
it was implemented). Aldo Calpini and Stephen Rawls both volunteered to
have a crack at it.
Whilst we shouldn't poke fun, the suggestion that Parrot's opcode
dispatch takes 'non-finite time' did make me smile.
Dan promises a better spec for multi level keyed access as soon has he
finishes the TPC talk slides.
Quote of the thread: "Generality and elegance are nice, but the point is
to go faster" -- Dan Sugalski
Note: Piers Cawley is me. I'll stick to referring to myself in the third
person when discussing my posts to the mailing lists. Piers does not do
Cerebus the Aardvark imitations all the time.
Anyhoo, Alberto Manuel Brandão Simões (who I will be calling `Alberto'
for the rest of the summary) made some suggestions about the
implementation of hashing of PMCs in Parrot. Dan said that we should add
an `id' method to the basic PMC vtable, and it should return an INTVAL.
Nicholas Clark suggested that maybe it'd be better to return an unsigned
value and Piers Cawley suggested that, if we were going to call it `id'
then it should return a guaranteed globally unique value. Brent Dax
suggested that, whatever it was called it should return a string, giving
"new Math::BigFloat('3.1415926535897932384626433832795');" as his
telling example. Alberto reckoned that, if "@a = (1,2,3)" and "@b =
(1,2,3)" then "@a.hash == @b.hash" should hold. Piers disagreed and
commented that languages like scheme have two or three different
equality/equivalence operators to deal with this sort of thing. Dan
agreed with him.
Mike Lambert has committed some changes to Parrot's Garbage Collector
that give an 8% performance improvement on the GC heavy tests in
examples/benchmarks. Yay Mike! Peter Gibbs pointed out that we're still
a lot slower than pre 0.0.7 versions of Parrot. The delay appears to
have been introduced because of the `addition of stack-walk code to
avoid child collection', which is apparently required to handle
exceptions cleanly. Nicholas Clark wondered if we couldn't avoid the
stack-walk and get a speedup if we're not calling any external code, but
that would mean extra bookkeeping, which might slow things down again.
Mike Lambert thought Nick's scheme might have merit and lamented the
lack of `real world' parrot programs. But then, as he pointed out, what
*is* a `real world' program? Mike also reflected on the mysteries and
difficulties of tuning garbage collectors; the controls available appear
to be somewhat complex and the trade offs are subtle and quick to anger.
Mike is looking forward to tuning the GC against parrot code that's
generated by Sean O'Rourke's perl6 compiler.
Regex bugfix and speedup
Angel Faus has been working on the parrot regex engine and submitted a
patch that gives a substantial speedup with simple patterns. Nicholas
Clark wondered about compiling perl 5 with regex optimisations turned
off so we could compare the speeds of the basic engines without magic.
Simon Cozens reckoned that this would be a pointless exercise. Nick
restated his reasoning, and Simon then wondered if the current parrot
regex engine was worth comparing against, and if it was well enough
designed to cope with the rigours of Apocalypse 5 type patterns. Hugo
van der Sanden thought that turning off the optimiser in perl 5 would
not be easy, but he'd like to make it easier on the perl 5.9 track.
[PATCH] Reduce array.pmc keyed code
Mike Lambert offered a patch to get rid of some of the clutter in
"array.pmc" and the resulting "array.c" by introducing a layer of
indirection, and asked for comments. Scott Walters pointed at his
earlier posts about refactoring the PMCs and suggested working together
on the issue. And there was agreement. Nicholas Clark added his weight
to this by pointing out that, in perl 6, being able to say "`this is an
array of ints' and have them stored in sizeof(int)" has been blessed by
Larry in one of the apocalypses.
Meanwhile, in perl6-language
Things were quiet, too quiet. The `Hashing PMCs' discussion took place
partially in perl6-language, with crossposts back to perl6-internals.
Otherwise not much was said.
David Nichol offered some cunning thoughts about perl in a distributed
persistent world which looked interesting, and offered a possible macro
definition syntax. Luke Palmer didn't like the syntax and wondered if
David wasn't thinking too much in Perl 5.
We're still assuming that the minimum version of perl you need to build
Parrot is 5.005, the eventual goal being to make the build self
supporting using a `miniparrot' approach (I wonder if we'll call that
`budgerigar' or `parakeet').
The mailing list archives are still not searchable (tell me about it),
but Brent Dax points out that the ever wonderful Google has the "site:"
keyword to do search restriction. I foresee a handy little autobookmark
appearing on my galeon toolbar real soon now.
Steve Fink suggested that "RECALL" wasn't that good a name for Tanton
Gibbs' proposed new preprocessor instruction because of the confusion
between `recall' and `re-call', proposing "REINVOKE", "RE_CALL", "CHAIN"
and the rather wonderful "DOITOVERAGAINBUTDOITRIGHTTHISTIME()". Brent
Dax suggested "AGAIN" (visions of the teletubbies as parrot programmers
swam in at least one head). This particular bikeshed has now been
Sean O'Rourke thinks there's a problem with "find_method". Nobody else
appears to have any thoughts. Warnock's Dilemma applies.
Aldo Calpini provided a short tutorial on submitting patches.
Simon Glover found a bug in parrot's file handling. Apparently the
"open" opcode disagrees with "read" and "write" (from core.ops) about
what a file handle should look like. Warnock's Dilemma applies.
Simon Cozens' head is exploding as he tries to make an inherently
recursive operation into an iterative one.
Jonathan Sillito had a couple of questions about lexical scopes and
scratchpads; apparently he has an implementation sketched out, but
wanted some clarification. Melvin Smith is also working on something
If you have a `Parrot' directory in your copy of the parrot source, you
should probably get rid of it; it can be hard to make diffs otherwise,
as Tanton Gibbs discovered.
Stephen Rawls has a problem; Spamassassin thinks his patches are spam.
Miguel de Icaza of Ximian popped up, via Simon Cozens, to point out that
the mops test for C# wasn't quite comparing apples with apples because
it was using 64 bit values and everything else was using 32 bit
integers. Melvin Smith fixed it.
Brent Dax is on holiday 'til August the 3rd. Melvin Smith is supposed to
be using the time to spread rumours about him and generally running amok
through Brent's code. But he hasn't spread any rumours about Brent yet,
though I heard that Brent's `holiday' was in fact a trip back to the
factory for an oil change and to have his nuts tightened.
Melvin Smith things Array.pmc is broken and is going to apply some
PerlArray.pmc fixes back to Array.pmc. Sean pointed out that there's
some perl specific behaviour in PerlArray.pmc that shouldn't be ported.
Mike Lambert, bless him, asked if he could propose a `simply-phrased
question?'. He had an IntArray in @P1 and a NumArray in @P2 how would he
do the equivalent of "S1 = P1 * P2"? He reckons the answer is
trickier than it looks.
Sean O'Rourke wants more ops. As things stand there's no way to get to
the vtable's cmp_num and cmp_string methods from parrot assembly. Which
is bad. He offers a patch.
Stéphane Payrard wanted to play with Qt from parrot, but the sources
didn't play well with C++. So he's offered a patch.
Alberto has some docs about various PMCs available at
Alberto also offered a Boolean.pmc, but it wasn't accepted. However,
it's nice, simple example of PMC implementation that may well repay a
closer look if you're interested in that sort of thing.
Johnathan Sillito implemented an `invoke' op which calls an arbitrary
vtable method. Applied.
Angel Faus offered a patch which `apparently makes the rx engine behave
well with the GC'. Warnock's Dilemma applies.
The "usleep" portability I mentioned in my last summary appears to have
been solved, but the patch hasn't been applied yet.
Andy Dougherty supplied a patch to eliminate 69 compilation warnings.
Sean O'Rourke has patched the perl6 compiler to work with perl 5.005_03.
Who's who in Perl6
Who are you?
What do you do for/with Perl 6?
I mainly discuss language design issues like the rest of the
second-level folk. I occasionally answer questions about Perl 6
syntax, as I have been following very closely it's creation.
Where are you coming from?
Naturally, from a pathologically eclectic state of mind.
When do you think Perl 6 will be released?
I don't really care, because I will surely be long deceased before
Why are you doing this?
Because I love programming, I love Perl, and I love community
You have 5 words. Describe yourself.
My slogan: Luke smokes Perl.
Do you have anything to declare?
Ha! Declarations are for structured programmers!
Acknowledgement, apologies and stuff
There are a few things different about this week's Perl 6 summary.
1 It's late.
2 There's no/very few links and URLs
3 Did I mention that it's late?
4 The grammar's probably even ropier than usual
Yes. I know. Last week was 'fun', for highly sarcastic values of fun.
Hopefully net access, commute times and general time available to write
summaries will be back to normal next week and you'll get a lovely,
shiny, highly linked summary. I'm publishing this now -- without my
usual level of proof reading -- only because I'm running so damned late.
Actually, feedback on this would be good; in general adding the links is
the most time consuming and tedious part of writing the summaries,
requiring a net connection and time to check the links. Which leads me
to wonder if I can't write links as predictable google searches using
the message-id. Time to experiment methinks.
As usual, if you liked the summary, send money to the perl foundation to
help support the ongoing development of Perl 6. Or you could send me one
of those shiny T?iBooks that all the cool kids were playing with at TPC.
But that's just naked self interest on my part and I'm really writing
summaries for love, kudos and egoboo.
Also, if you're involved, however peripherally in the Perl 6 development
process, I'd really appreciate it if you'd answer the questionnaire I
posted. I'm still waiting for answers from Larry and Damian; Dan's
answers will be forthcoming in 5 week's time (I'm publishing them in
strict order of receipt).
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Perl 6 Summary for week ending 20020728