This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit

The Perl 6 Summary for the week ending 20021103

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 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 defence, 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 if 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.[]

Portable linking issues

Andy Dougherty is having portability problems. He wants to portably compile and link 3 files and he's having problems and wondered what the best way forward 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.)

Implicit stack direction probe

Meanwhile, Jason Gloudon's patch to move the stack direction probe back to initialization time rather that 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.

Of MOPS and Microops

There's been some discussion of granting a small number of Parrot registered 'most favoured' 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.[]

Very complete lexical scopes

Jonathan Sillito has submitted a patch which `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.

miniparrot, a first attempt

If you've been paying attention to the Parrot build process, you'll be 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.

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 vs. 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. Lots of people agree with him on this.
  • 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. -- Op list, Take 3. -- Take 4 -- Take 5 -- Take 5a -- Take 5b -- Take 6 -- Pointers to Unicode stuff -- Someone coming in late -- 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.

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 very on topic...

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 too far...

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 or not to interleave sources and iterators before deciding on the current syntax.

Nondeterministic algorithms, flexops, and stuff

Piers Cawley made heads hurt (his included) when he posted a question about using superpositions (aka flexops) to implement non deterministic 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).

Primitive Boolean type?

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, etc 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.

Labelled if blocks

Last week, Steve Canfield wondered if Perl 6 would have labelled 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 which 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:


or whatever.

In Brief

There was some disCcussion 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. Lets 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 clean up' patch (2000+ line patch).

Allison Randal has a fascinating article all about Perl 6 topics and topicalizers at 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.

Who's Who in Perl 6?

  • Who are you?
  • Mike Lazzaro. My wife and I own a company called Cognitivity ( in Burbank, California -- we met at Caltech, in Pasadena. We use Perl5 for our commercial e-learning software (online, customizable corporate training software). This is the first company we actually own, after working as consultants/contractors/employees for years at other places. It's great.

  • What do you do for/with Perl 6?
  • Originally, I just wanted to document Perl6's OO behaviours, but I soon found that to be impossible without documenting everything else first, so that's what I'm doing. I'm going piece-by-piece through all the early Apocalypses, attempting to fill in all the details and implications, which I am writing up in book-like form. As I get them done, I'll post them for review and feedback -- but before that, I'll have a lot of little questions and inconsistencies that I need to pin down.

    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.

  • Where are you coming from?
  • I've been using Perl since the 4 to 5 migration. Before that, I was mainly a C/C++ person. Before that, assembler. Perl5 is the best language I've ever used, but lately it's had some enterprise-level scalability problems that I need to solve, if I'm going to keep using it. Hence, I'm helping with Perl6.

  • When do you think Perl 6 will be released?
  • Sooner than people think... maybe a robust alpha within six months, I bet. People are worried about the length of time it's taking to get through the initial decisions, but most of the hard ones have already been done. It's going to pick up dramatically after the next two or three Apocalypses.

  • Why are you doing this?
  • Because I've had to work in five different languages over the past few years, and they all suck, each in their own special way. Horribly. If I'm going to continue programming as a career, I want to work in a language that, as much as possible, takes the grunt work out. I don't like re-solving the same design patterns umpteen times. That's something a computer should do for me.

    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...

  • You have 5 words. Describe yourself.
  • Programmer, Manager, Writer, Optimist, Cynic.

  • Do you have anything to declare?
  • I've grown to hate most technical terms, because nobody uses them to mean the same way. So I have an allergic reaction to descriptions that use a lot of big words to explain something that should be Much More Obvious. You'll find I post a lot of "please clarify" messages, to try to beat that out of people. :-) It doesn't always mean I'm dense, though sometimes it does. Sometimes it means "No -- really. Is that your final answer?"

Acknowledgements, requests and the third thing.

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, what are you doing still reading it? If you did like it, please consider one or both of the following options:

The feed paid for publication of these summaries on is paid directly to the Perl Foundation.