This week on Perl 6 (11/03-11/10, 2002)
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://groups.google.com/groups
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 behavior 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://groups.google.com/groups
http://groups.google.com/groups
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 behavior (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.
The 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://groups.google.com/groups
string_set Is Back
Leopold Tötsch has added a ‘string_set’ function that 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 nondestructive, set! is destructive split, allowing the Parrot coder to choose. Looks like I just suggested it here.
http://groups.google.com/groups
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 that sets $baz to the value of the caller’s topic. (If you’re not sure what I’m talking about, then 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://www.perl.com/pub/2002/10/30/topic.html
http://groups.google.com/groups
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 appears 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://groups.google.com/groups
http://groups.google.com/groups – A decent summation from Michael Lazzaro
Supercomma!
At one point in the UTF-8 and Unicode thread, Larry wondered whether 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://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups
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://groups.google.com/groups
FMTWYENTK about :=
Bravely declining to expand the acronym in his subject, arcardi posted a summary of his current understanding of the behavior of :=, the binding operator, and peppered the post with questions. None of which were answered this week.
http://groups.google.com/groups
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://groups.google.com/groups
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 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 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://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups – 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://groups.google.com/groups
http://groups.google.com/groups – Dan talks sense
http://groups.google.com/groups – So does Simon Cozens
http://groups.google.com/groups – 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 centered 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://groups.google.com/groups
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://groups.google.com/groups
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://groups.google.com/groups
Project Start: Section 1
Late Friday, Michael kicked off discussion of the first section, most of the discussion took place during the following week, which is when I’ll summarize it.
http://groups.google.com/groups
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 about 25 percent 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 with some of the tedious but necessary stuff in order to free other people to concentrate on design & implementation.
Where are you coming from?
About this time last year, I started 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 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 pdcawley@bofh.org.uk
The fee paid for publication of these summaries on perl.com is paid directly to the Perl Foundation.
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub
