The Perl 6 Summary for the week ending 20021110
Far off in distant Newark a figure, muttering something about `Leon
Brocard', shambles across a railway bridge and makes its way into a
waiting room. Time passes. After a while, a train arrives and the figure
shambles on board, takes its seat, pulls a laptop from its bag and
starts to type. This is what it types: `=head1 The Perl 6 Summary for
the week ending 20021110'.
Yes, it's time for another update on the japes and tomfoolery from the
world of Perl 6. We start, as usual, with perl6-internals.
The Myth of Fingerprints
At the end of the previous week, Gregor posted an outline of his
proposal for fixing the fingerprinting issue with dynamic loading. (The
fingerprinting issue is that 'old' .pbc files may break big time when
run on newer Parrots. Ideally we'd like Parrot to refuse to run such
files *before* bad things happen. It's proposed that this be done by
adding `fingerprints' to .pbc to allow for identification by Parrot.)
Leopold Tötsch wasn't at all sure about Gregor's approach, pointing out
that it would have massive speed implications, and lo, the thread got
dragged off in the direction of a discussion of optimizing Parrot for
speed. How did that happen then?
http://makeashorterlink.com/?T12252F62
"on_exit" not portable
Andy Dougherty pointed out that Solaris doesn't have "on_exit", which is
used by Parrot to clean up after itself, and suggested that
interpreter.c be reworked to use "atexit". However, SunOS has on_exit
but doesn't have atexit. It's a quandary. Josh Wilmes suggested
implementing "Parrot_on_exit()" and "Parrot_exit()" in platform.c and
half promised a patch (unless somebody beat him to it.) Leo Tötsch and
Nicholas Clark both said, essentially "Nice idea, go do it."
Dan chimed in, pointing out that the current "on_exit" behaviour seemed
to be there as a workaround for bugs in exceptions, and that fixing
those was probably the better idea. Leo turned off the 'on_exit' stuff,
just as Josh was sending a patch implementing the Parrot_* functions. I
think that, as we now stand, we're back to doing exit cleanup, but using
the portable Parrot_* functions.
http://makeashorterlink.com/?F53246F62
http://makeashorterlink.com/?G14231F62
Should memory be washed?
Peter Gibbs was unsure of the guarantees given by "Parrot_allocate" and
friends regarding the contents of the memory supplied. Apparently, some
code appears to assume that it will get pre-washed memory, while other
code does its own cleaning. Which is right? Leo Tötsch reckons that the
current behaviour (memory is zeroed at allocation time) should be
guaranteed. Dan wasn't so sure that this was a good idea if we go for a
`malloc like' scheme and thought that it could be argued that it was a
bug for any code to assume that the memory it got was zeroed.
Eventual consensus was that the basic allocator should not guarantee
zeroed memory, but that there should be a set of allocator functions
that *do* return zeroed memory. Leo checked in a patch to that effect.
Then they started talking about performance.
http://makeashorterlink.com/?X15224F62
"string_set" is back
Leopold Tötsch has added a 'string_set' function which allows strings to
be recycled instead of having to create new strings every time. This can
lead to substantial speed gains when used appropriately. This led to a
discussion on when it was appropriate to use non destructive assignment
and when to use a destructive set. Somewhat to my surprise, nobody has
yet suggested the lispish "set" is non destructive, "set!" is
destructive split, allowing the Parrot coder to choose. Looks like I
just suggested it here.
http://makeashorterlink.com/?M26225F62
Meanwhile, over in perl6-language
Amazingly, the main topic of conversation this week wasn't the dreaded
operator thread...
Unifying invocant and topic naming syntax
Allison Randal has written an article about Perl 6 topics for perl.com.
`Ralph' read this and didn't appear to like it very much, particularly
the "sub foo ($bar) is given($baz) { ... }" syntax which sets $baz to
the value of the caller's topic. (If you're not sure what I'm talking
about, now would be a good time to read Allison's article. Topics are
great, you'll like them.) Ralph wanted to do "sub foo ($baz : $bar is
topic) { ... }", and supplied several further, terser and terser
declaration forms, "method f ($self : $c : $a*, $b) {...}" anyone?
Allison thought Ralph was barking up the wrong tree, and explained the
thinking behind the topic related syntax and pointed out that Ralph
appeared to be conflating two `independent but interacting features'
with his proposal, but Ralph didn't give up that easily. Eventually,
after comments from Damian and Allison he let the subject lie.
http://makeashorterlink.com/?W59612C52
http://makeashorterlink.com/?P47251F62
UTF-8 and Unicode FAQ
Actually, I lied about the operator thread subsiding. It fragmented. But
at least now the various fragments got their own subjects. In this
particular subthread the whole 'Unicode operators in core' thing got
discussed. There appear to be two camps. The first camp maintains that
Unicode operators in the core means Perl will start looking dangerously
like APL and will need a space cadet keyboard to use. The second camp's
argument for Unicode operators appears to be `Yeah, and your point was?
We only want to use « and », and isn't it about time the world got with
the Unicode program?'
Me? I'm on the fence. I can see the reasoning behind wanting Unicode
operators, but I'm not entirely sure I like them (the 'email encoding'
problem is my major bugbear...)
http://makeashorterlink.com/?R28251F62
http://makeashorterlink.com/?O29212F62 -- A decent summation from
Michael Lazzaro
Supercomma!
At one point in the UTF-8 and Unicode thread, Larry wondered if he could
raid Unicode for a better character than ";" for separating parallel
"for" loop streams. Michael Lazzaro responded with a couple of
suggestions for different supercommas which would have different
meanings. I couldn't tell you what the symbols are, my mailer rendered
'em as Latin-1 digraphs, neither of which looked much like a comma.
Larry then confessed that he was thinking of changing the declaration of
parallel for loops from:
for @a ; @b ; @c - $a ; $b ; $c {...}
to something like:
for parallel(@a, @b, @c) - $a, $b, $c {...}
Which has the advantage of not messing with the block signature at all,
which Larry reckons should make Simon Cozens happier. Damian pointed out
that doing things this way would probably mean we'd get a bunch of
useful functions for iterating over arrays (and then implemented one
such function). Others followed, implementing various other useful
functions before Damian capped them all with a nicely generalized "zip"
implementation.
Buddha Buck endeared himself to the summarizer with his summary of "for"
loop possibilities. Buddha also included a rather pretty implementation
of "for" as a recursive function, though Damian reckoned he'd not quite
got the signature right.
http://makeashorterlink.com/?T2A212F62
http://makeashorterlink.com/?V6B212F62
http://makeashorterlink.com/?Y2C252F62
http://makeashorterlink.com/?Q2D211F62
The interminable operator thread
`Smylers' is my hero of the week for a message he posted summarizing the
various (12) options for changing the look of operators, with particular
reference to vectorization. Options range from `as we were' to the
`guillemot' option which involves seabirds and a pathological inability
to spell `guillemet'.
http://makeashorterlink.com/?C1E222F62
FMTWYENTK about ":="
Bravely declining to expand the acronym in his subject, arcardi posted a
summary of his current understanding of the behaviour of ":=", the
binding operator, and peppered the post with questions. None of which
got answered this week.
http://makeashorterlink.com/?I5F213F62
Junctions and laziness
Junctions are what we're calling superpositions this week. Piers Cawley
had another crack (the operative word I think, on rereading) at his non
deterministic search algorithm using junctions and a subclass of
Function. Damian, of course, came up with a better possible syntax for
lazy functions:
sub some_func(Num $n) is lazy returns Num {
return $n ** $n;
}
Billy Naylor wondered if a similar notation could be used for memoize:
sub fib(Num $n) is memo returns Num {
given $n {
when 0 { 0 }
when 1 { 1 }
otherwise { fib($n-1) + $fib($n-2) }
}
}
and Damian pointed out that this was covered in Apocalypse 2, but the
name of the property was yet to be decided. Which led to discussion of
appropriate names.
http://makeashorterlink.com/?A10342F62
Primitive vs. Object types
David Whipp was worried about the use of primitive types. He pointed out
that "whenever a value passes through a primitive type, it loses all its
run-time properties; and [junctions] will collapse. I worry that this
could cause very obscure bugs". He also worried that the similarity of
names ("Int" for an object vs. "int" for a primitive) would make such
problems harder to spot, and violated Larry's maxim that `Similar things
should look different'. He proposed that, in order to use primitive
types, a module author should first do something like "use primitives
qw(int)", and that maybe names like "int" should be changed to names
like "_prim_int32".
Dan wasn't entirely sure that David's basic assumption about
properties/junctions was accurate, but Michael Lazzaro pointed out that
this had been strongly implied by things Larry and Damian had said,
though Michael later dug up a reference to Apocalypse 2 which was
ambiguous about runtime properties on primitive types. Dan started
making 'worried' noises about supporting primitive types and Larry,
while still keeping things fluid about what will actually happen,
explained more of his thoughts about them.
Garrett Goebel wondered about the difference between `attribute' and
`property' in Perl 6. I assume everyone would like to know this. The
very short answer goes something like: `attribute' is the Perl 6 term
for an instance variable, a `property' can be thought of as a `yellow
sticky note attached to an arbitrary object'. Dan has a better
explanation which doesn't avoid using a trademarked term.
http://makeashorterlink.com/?A11332F62
http://makeashorterlink.com/?Z12322F62
http://makeashorterlink.com/?N23363F62 -- Dan's attributes/properties
explanation
perl6-documentation was born
On Wednesday, Michael Lazzaro (who has been doing some sterling
documentation work, check out his `introduction to variables and values'
docs, linked below) proposed that now was the time to start documenting
(and finalizing) the detailed design of what we know about Perl 6 so
far. He is concerned that for all the discussion on the language list,
most of the decisions don't appear to be being documented, nor reflected
back in updated Apocalypses and other documentation.
He proposed, therefore, that perl6-language `focus on fleshing out every
last detail implied by Apocalypses 2-N, *in that order*' and hoped that
we could `migrate perl6-language into a list that finalizes aspects of
the design, documents them, and revises them as needed'.
Allison Randal wasn't initially convinced that this was necessarily a
good idea. She worried that Larry (the Official Last Word on Perl 6)
would be snowed under by an RFCesque tide of new documentation, and that
reviewing such a tide would make him lose focus.
At this point, Michael threw the Virtual Coffee Mug.
After a further period of discussion Dan pointed out that the key was to
`Just Do It' (a phrase normally pronounced with four words), so we
created the perl6-documentation mailing list and your summarizer got a
bunch more work.
The thread is long. I've summarized the main line (badly) and now
provide some links to key posts, but if you want more detail I suggest
you follow the first link and read the thread. For those that like drama
and high emotion, the virtual CM chucking post is Michael's response to
Allison's reply. I'm not going to link directly to it; trust me, context
is better.
http://cog.cognitivity.com/perl6/val.html -- vars and values intro
http://makeashorterlink.com/?D24332F62
http://makeashorterlink.com/?H25312F62 -- Dan talks sense
http://makeashorterlink.com/?U66325F62 -- So does Simon Cozens
http://makeashorterlink.com/?R27363F62 -- The tests should be the spec
Meanwhile, In perl-documentation
The new baby got off to a flying start as Michael Lazzaro laid down his
goals for the project. Early discussion centred on the overall structure
of the intended documentation; what formats it should be written in; the
requirements for concrete, executable Perl 6 test cases and the
importance of fluidity. Michael repeatedly stressed that it was vital
that the documentation list retain focus; his goal is that the entire
list should work on one thing at a time.
http://makeashorterlink.com/?E68322F62
Roll call
Michael asked for a quick roll call of who was interested in the
documentation project. As an added bonus, he asked that even the lurkers
put their hands up if they were interested. Surprisingly, some of them
decloaked and did so.
http://makeashorterlink.com/?T29332F62
Project Goals?
Michael formally kicked off the discussion with the question "How can
this documentation project best help with the overall goal of producing
a finished Perl 6?" Answers on a piece of data to the list, do not
attempt to write on both sides of the data at once.
http://makeashorterlink.com/?D2A352F62
Project Start: Section 1
Late on Friday, Michael kicked off discussion of the first section, most
of the discussion of which took place during the following week. Which
is when I'll summarize it.
http://makeashorterlink.com/?C1B355F62
In Brief
Leo Tötsch and Brent Dax have been working on ways of making Parrot GC
go faster by improving the performance of the `destroy' phase.
Andy Dougherty sent in a patch to ensure that the languages/perl6 build
will work without bison. Andy found and fixed a compiler specific bug
introduced by someone using C++ style comments.
Richard Proctor suggested that miniparrot should be called `budgie'.
Leo Tötsch showed off some numbers for the life generations/sec test.
JIT is looking very quick indeed, it's only around 25% slower than a
native C implementation.
Dan's back from Seattle and digging through his mail backlog.
Leo Tötsch has been thinking about regexes/patterns/rules and thinks
that we should reintroduce a regex state object, making regexes
reentrant once more.
Who's who in Perl 6?
Who are you?
Simon Glover
What do you do for/with Perl 6?
Write tests, stomp on compiler warnings, fix bugs (occasionally)...
Basically, I try to help out with some of the tedious but necessary
stuff in order to free up other people to concentrate on design &
implementation.
Where are you coming from?
About this time last year, I was starting to get a bit frustrated at
what appeared to me to be the slow pace of Parrot development, when
I suddenly thought: 'You know, if you gave them a hand, they'd
finish sooner'. So I did (and we haven't... yet. Of course, I've now
got a better understanding of *why* this takes a long time).
I'd also like to add that I'm proof that you don't have to be a C
coder in order to be useful on a project like this...
When do you think Perl 6 will be released?
Depends what you mean by Perl 6 -- after all, we already have a
subset of it up and running on Parrot. Seriously, I think we'll have
something that's genuinely usable and useful well before the end of
2003, even if there are still a few loose ends to tie up.
Why are you doing this?
I like Perl - it matches the way I think. The problem is, Perl is
too slow for many of the things that I'd like to use it for, and too
hard to extend. Parrot should fix both of these problems.
Also, it's nice to see one of my favourite features of F90 finally
make it into Perl :-)
You have 5 words. Describe yourself.
Mild-mannered English computational astrophysicist.
Do you have anything to declare?
All the C I know I learnt from Parrot. (Well, OK, K&R helped too,
but it's amazing how much you can learn from reading other people's
code).
Acknowledgements, requests and general banter
This summary was again brought to you from the 0625 Newark on Trent to
Kings Cross and the 1720 Kings Cross to Newark on Trent trains. It was
fuelled by copious amounts of GNER coffee and, one one occasion, a bacon
and tomato toasted sandwich. I'd like to extend my thanks and best
wishes to Avril Hill, who's been bringing me morning tea for months now,
but who's about to escape the train and start working on Leeds station.
Proofreading services were supplied by aspell and myself. Blame aspell
if it's really terrible.
I'm running short of questionnaire answers. If you've *ever* been
mentioned in a Perl 6 Summary, or if you haven't (yet), please consider
answering the questions Simon just answered and sending them to
<mailto:5Ws@;bofh.org.uk. Thanks.
Now, if we all join in with the chorus:
If you didn't like this summary, what are you doing still reading it? If
you did like it, please consider one or both of the following options:
* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl 6.
* Send feedback, flames, money and/or a Schneider 90mm f/5.6 Super
Angulon XL to <mailto:pdcawley@;bofh.org.uk
The fee paid for publication of these summaries on perl.com is paid
directly to the Perl Foundation.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
