This week on Perl 6 (10/28-11/03, 2002)
by Piers CawleyNovember 06, 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.
Fun With File Formats
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
Portable Linking Issues
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
Implicit Stack Direction Probe
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
Of MOPS and Microops
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
Very Complete Lexical Scopes
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
miniparrot, a First Attempt
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
Meanwhile, Over in perl6-language (or "The Horror! The Horror!")
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:
- Perl 6 is going to be even harder to parse than Perl 5
- Unicode operators in the core language are just wrong. Many people agree with him.
- Superpositional operators will be too rare to justify giving them precious one character operators.
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
Smalltalk-Type Collection Classes?
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
Persistence of superpositions
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
Proposal: Vector Operators for Hashes
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
Plaintive Whine About for Syntax
Dave 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
Pages: 1, 2 |





