This week on Perl 6 (10/28-11/03, 2002)
Welcome to the latest of the ongoing series of Perl 6 summaries, in which your arrogant moderator does battle with the forces of prolixity in a Brobdingnagian attempt to tame the tortuously tangled threads of Perl 6's design and development mailing lists. And if I keep up the purple prose at that rate, then it'll *still* be clearer than the tangle that is this week's perl6-language discussion.
However, because it's customary and because the language list scares me, we'll start with the comparatively tame perl6-internals.
Toward the end of last week, Rhys Weatherley had asked about being able to insert arbitrary chunks of metadata into parrot bytecode files. Dan ended up producing a `draft sketch' of the bytecode generation facilities and the ability to add arbitrary chunks of metadata was conspicuous by its absence. People didn't seem to be happy about this, lamenting a lack of flexibility, both in the overall file structure and in what one could stick into the bytecode. Dan mounted a sturdy defense, pointing out that we want `a file format that does what we need it to -- present executable bytecode data to the interpreter -- as fast as possible. Everything else is secondary to that.'
Kv Org wondered whether it would be a good idea to worry about sandbox issues in the bytecode format, but nothing came of that question. Well, not this week anyway.
http://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups
Andy Dougherty is having portability problems. He wants to portably compile and link three files, and he's having problems and wondered what the best way was to get an early test compiling properly on all platforms. Help was supplied, the build was fixed, and the world remained safe for democracy. (Modulo a few local difficulties.)
http://groups.google.com/groups
Meanwhile, Jason Gloudon's patch to move the stack direction probe back to initialization time rather than compile time was offered. I'm assuming that Nicholas Clark's suggested speedup trick from last week was implemented as part of it, but I'm no great understander of C.
http://rt.perl.org/rt2/Ticket/Display.html
There's been some discussion of granting a small number of Parrot registers 'most favored' status. The idea being that a small number of registers would actually be held in global (possibly real register) variables, with the rest being accessed through via indirection through the interpreter. Apparently, the JIT core already does some optimization along these lines, and Dan doesn't seem to be sure that doing it for the main interpreter would actually be much of win. Discussion continues.
http://groups.google.com/groups
Jonathan Sillito has submitted a patch that `implements a very complete set of lexical scope semantics.' It looks pretty cool to my untutored eye. General response was positive, though Jürgen Bömmels did have a query about how to create a new scope.
http://rt.perl.org/rt2/Ticket/Display.html
If you've been paying attention to the Parrot build process, then you aware that it was always a goal to use a cut-down variant of Parrot itself to run the configuration tests. The plan is that this miniparrot should be buildable with nothing more than an ANSI-compliant C compiler. Josh Wilmes thinks we're about ready to start building said miniparrot, and offered his first cut to the list. Response was positive, with quibbles, which is about what one would expect.
http://groups.google.com/groups
The dreaded `Operator Reshuffle' thread continues apace -- of the 450 posts last week I'd say about 400 of 'em were discussing various aspects. Bear in mind, too, that the path of discussion could be described as helical (sort of like circular, but getting more and more wound up with each go 'round). There are at least two factions involved, roughly caricatured as `Simon Cozens versus the rest of the world.' Simon can be thought of as the voice of conservatism (or Reason, depending on whether you agree with him or not), generally arguing against stuff he considers massively ugly or confusing. Simon's allies vary depending on which issue he's discussing and his worries include:
This is, of course, a gross simplification of what's going on in the
various operator threads, but it does cover a fair number of the
issues that are arising in the attempt to get ^ back as exclusive
or (which then frees ~ up to become string concatenate,
which... ah, go read last week's summary, I already did this...)
BTW, 'Vectorizing' is the new 'Hyperizing' (or did I do that last week?)
Here's the various threads involved in the kerfuffle, along with Michael Lazzaro's utterly wonderful summaries of the current core operator list as he sees it.
http://groups.google.com/groups -- Op list, Take 3.
http://groups.google.com/groups -- Take 4
http://groups.google.com/groups -- Take 5
http://groups.google.com/groups -- Take 5a
http://groups.google.com/groups -- Take 5b
http://groups.google.com/groups -- Take 6
http://groups.google.com/groups -- Pointers to Unicode stuff
http://groups.google.com/groups -- Someone coming in late
http://groups.google.com/groups -- Questioning the value of infix superpositions
One of the subthreads of the mammoth operator thread covered whether it might be a good idea to include a set of collection classes in the style of the Smalltalk Collection hierarchy to the Perl 6 core dist.
http://groups.google.com/groups
Buddha Buck wondered how pervasive superpositions were, and for how long they would remain entangled. Damian thinks they should be all pervading and fully propagating. This thread didn't really stay on topic ... .
http://groups.google.com/groups
Arcadi made some proposals about how to extend the concept of vector operators to hashes as well as lists and arrays. Discussion ensued. People seem to like the idea of extending vector ops to cover hashes, but weren't necessarily sure that Arcadi's approach was the right one. 'Adverbial' control of how the vector ops work was also discussed, though Larry gave the impression that he thought this might be a generalization ... .
http://groups.google.com/groups
for SyntaxDave Storrs really doesn't like the syntax of the `parallel streams'
variant of for:
# This iterates over @a and @b in parallel
for @a; @b -> $x is rw; $y { $x = $y[5] }
and he offered a list of suggestions, though I think more people disliked his alternatives (even among those who didn't like the current syntax) than liked 'em. Damian pointed out that a little finesse with the editor could be of some assistance:
for @a ; @b
-> $x is rw; $y { ... }
Ed Peshko wondered what happened when you had a lot of parallel streams, and Damian obliged with:
for @a; @b; @c; @d; @e
-> $a_var1 is rw, $a_var2 is rw;
$b_var is rw;
$c_var is rw;
$d_var is rw;
$e_var1 is rw, $e_var2 is rw
{
...
}
But this is a somewhat pathological case. Damian also mentioned that he and Larry had thought long and hard about whether to interleave sources and iterators before deciding on the current syntax.
http://groups.google.com/groups
http://groups.google.com/groups
|
by Piers Cawley
Piers Cawley made heads hurt (his included) when he posted a question
about using superpositions (aka flexops) to implement nondeterministic
algorithms. The particular example given was an algorithm to find a
path between two nodes of an acyclic-directed graph (lifted from a
text on lisp). Jonathan Scott Duff thought the idea was 'neat.' For an
encore, Piers redid the function without flexops, using a continuation-based implementation of choose and fail (which hurts my head
more than the superposition-based version, frankly).
http://groups.google.com/groups
Michael Lazzaro asked a tricky question: Can a bit be undefined? If
so, then it leads to the somewhat counterintuitive assumption that one
would need two bits to store a single `bit.' Which is certainly
odd. However, it turns out that native types like bit, int, cannot be undefined; so that's all right. This then branched off into
a discussion of whether Perl 6 would have an explicit Boolean
type. It won't. Unless Larry changes his mind.
http://groups.google.com/groups
Last week, Steve Canfield wondered whether Perl 6 would have labeled if
blocks, which would allow one to jump out of arbitrary levels of
nested ifs. It seems the answer is `no,' but this led to a discussion
of possible control statements that affect the flow of control in
different sorts of blocks (subs, conditionals, loops, etc.). It's
looking like we may end up with a leave statement. The other
possibility would be to make return a method, allowing one to do:
Loop.return($x)
or whatever.
http://groups.google.com/groups
http://groups.google.com/groups
There was some discussion on the internals list about what functions need to have an interpreter argument. The basic rule appears to be: `If it's going to allocate memory, it needs an interpreter.'
Leopold Toetsch has rejigged the startup procedure so that we will
always have a valid interpreter, making patches like the one that
allowed for a NULL interpreter in sprintf unnecessary.
Discussion of the Parrot Copyright/License changes was subdued, bordering on the nonexistent. Let's hope it stays as smooth.
Leo Toetsch has been doing various refactorings of Parrot ops.
There was discussion about how to generate the MD5 hashes for Parrot bytecode `fingerprints.' The catch is that the Perl module Digest::MD5 isn't guaranteed to be available on all Perl installations ... .
Josh Wilmes did a massive 'indentation cleanup' patch (2000+ line patch).
Allison Randal has a fascinating article all about Perl 6 topics and topicalizers at http://www.perl.com/pub/a/2002/10/30/topic.html, which is well worth the read.
Paul Johnson had some thoughts about using properties on statements and the like as a way of providing metadata to things like code-coverage tools.
My feeling is, because I'm *not* on the design team, and I *don't* know all the thinking on how and why things are decided, I'm a good test person to write newbie-level documentation. If you can explain it to me, that's a pretty good indication that you and I can explain it to someone else. I think the disconnection between designer and documenter will be important, in this case, because we want Perl6 to be heavily adopted by mere mortals, not just experts.
Why am I volunteering for documentation? Dunno, seemed like that effort was falling behind, since everyone keeps asking the same questions, over and over (like me, for example). And I can type fast. And I've got lots of experience at herding cats, which can't hurt ... .
This summary was once again brought to you from the comfort and security of a GNER Express train running between Newark and London, and from the greater comfort and security of my armchair at home. Production was abetted by industrial quantities of site tea (in the case of GNER) and Earl Grey China Moon tea (in the armchair).
Proofreading was mostly done by Piers Cawley, so you can blame him if there are any outrageous typos.
And, as the postamble usually goes, if you didn't like this summary, then what are you doing still reading it? If you did like it, then please consider one or both of the following options:
The fee paid for publication of these summaries on perl.com is paid directly to the Perl Foundation.
Perl.com Compilation Copyright © 1998-2006 O'Reilly Media, Inc.