This week on Perl 6 (11/03-11/10, 2002)
by Piers CawleyNovember 15, 2002
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/a/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
Pages: 1, 2 |
