| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
It looks like things are starting to slow down slightly as we run up to Christmas, but the quality of discussion remains high. We'll start with the usual trawl through perl6-internals.
Dan ruled on last week's discussion of testing for undef in
Parrot. We're getting a new isnull branch op along with a new Undef
PMC. Leo Tötsch implemented it with his usual alacrity.
groups.google.com[10.0.1.2]
One of the annoyances of writing something that's really going to be used is that you can't get away with the equivalent of outlining your proof on the blackboard, waving your hands and saying "The details are left as an exercise for the interested reader". A case in point is Parrot's array of comparison branch operators. For a while now we've been getting by with a sparsely populated array of such beasties. This week saw people (well, okay then, Leo, but he has the productivity of people) doing the detail work to get the full range implemented.
groups.google.com[10.0.1.2]
Dan wasn't happy with the scoping of the .const directive in IMCC
(essentially constants are sub/block scoped, which makes them pretty
much useless for the things constants are normally used for). Melvin
Smith made the fix.
groups.google.com[10.0.1.2]
Dan had mandated that the Parrot internal equivalent of the Perlish
Package::Name should be Package\0Name. Nobody (Dan included)
liked the embedded nulls mandated in Dan's original spec. After some
discussion he posted a description of a new hierarchical namespace
design.
Dan pointed out that the use of hierarchical namespaces would probably
mean that the semantics (and syntax) of find_global would need to
be adjusted.
groups.google.com[10.0.1.2]
groups.google.com[10.0.1.2] -- The New Namespace
Dan's been writing more PIR code by hand, and is discovering infelicities as he goes.
groups.google.com[10.0.1.2]
groups.google.com[10.0.1.2]
Following his bout of IMCC bug spotting, Dan announced a decision about macros in PIR and PASM code. Essentially, Parrot's built in PIR and PASM parsers do not need to do macros as 'macro assemblers are for people, not compilers'. Because of this, Dan would like to see any macro processing moved out of the core binary and into an external tool. (Which can always be invoked via the hypothetical macro-parrot.pl). Melvin Smith suggested that it would probably be worth extracting the existing macro processor from imcc.l and moving it into a separate library.
The language list continues to fascinate (and not in the 'car crash' way it has done on occasions in the past) with an ongoing conversation between Larry on the one hand (seemingly designing on the hoof and certainly doing a great deal of thinking aloud) and everyone else on the other hand getting clarification or extrapolating to the point where Larry has to step in and do a little bit more design.
I'm finding it hard to do a proper summary of what's going on because so much is changing (and because so much of what seems to be set in quick drying concrete now is so novel.)
Essentially the discussion revolves around Roles, which are sort of
like Java interfaces, sort of like mixins and nothing like either. In
his 'Vocabulary' post, Luke Palmer describes a Role as 'A collection
of methods [and/or attributes] to be incorporated into a class sans
inheritance [...]. Used with does'. In this new world, a property
($bar but Red etc) is a kind of degenerate role.
At the same time though, we're getting other gems. For instance, Perl
6 is going to get something a little like final, but instead of it
being a declaration made in a type's implementation ("This is the one,
the only Integer and you may not inherit from it or ever alter it!"),
it will become a promise made by a type's user not to attempt to
monkey with it come run time, which should set the code generator free
to use optimizations that aren't safe when everything's dynamic.
So, if you're interested in how Perl 6's OO system is going to work, now is the time to get involved in the language list. If there's something you've always wanted to do or something about Perl's current OO that you love and want to retain, it's time to speak up for it. The odds are good that you'll be able to do what you want using the mechanisms being designed, but you'll be kicking yourself later if it turns out you can't.
If you do join in, you'll see references to the 'Traits Paper'. This is where the original idea for what Larry's calling 'Roles' came from. When you read it, bear in mind that the authors of the paper use the term 'trait' for what we're calling a 'role' (We already have traits you see).
www.cse.ogi.edu -- Traits paper
Joe Gottman asked for some clarification about which was more right,
Apocalypse 4 (for @a ; @b -> $a ; $b {...}) or Perl 6
Essentials (for zip @a, @b -> $a, $b {...}) when talking about
Essentials> iterating through two (or more) arrays
at once. The rule of thumb for this seems to be 'latest publication
date wins' so P6E is the most correct. He went on to wonder what
happens when one array is shorter than the other (an undefined value
is passed into the loop when the array runs out of values until the
last array is exhausted). He wondered what would happen if any of the
arrays contained undef; how would the body of the loop be able to
differentiate between a 'valid' undef and one created by the loop
itself.
Larry pointed out that, in Perl 6, undef isn't necessarily unique and may well contain an unthrown exception with extra information hidden in a property.
If you're even vaguely interested in the workings of Perl 6's object system, you need to read the referenced post.
Luke Palmer, worrying about people using Object related vocabulary in subtly inconsistent ways, posted a glossary explaining how OO terminology is used in a Perl 6 context. Casey West wrapped it up in a POD, which will, I hope, end up on dev.perl.org soon.
Of course, there were a few corrections for subtleties, a few rethinks of the design so far, and general gratitude for at least having a baseline document that people could refer to.
groups.google.com -- Casey's POD
Stéphane Payrard wondered if Perl 6 would have enums and bitenums directly supported in the language (he pointed out that it wouldn't be hard to implement them using macros of course). Larry speculated that enums might just end up being special cases of roles/subtypes.
Further down the thread, Uri Guttman commented that Larry seemed to be working on a grand unification and wondered if string theory had any place in it. (Actually, it's been apparent for ages now that a great deal of the power that Larry's putting into Perl 6 arises from the unifications he's making, but that's an article for my weblog I think).
For the duration of the panto season, Leon Brocard will be appearing in the role of Pumpking in a Perl 5 Porters summary near you.
Still no link shortening. I appear to have managed to subtly screw my Perl installation and now I can't get the link shortening module installed. I shall try and make time to fix it this week.
Unless someone beats me to it (please someone, beat me to it) I'm going to try and put together a 'state of play' post, summarizing the current state of the Perl 6 Object system with a little more background in it than Luke Palmer's excellent 'Vocabulary' post. All being well it'll be appearing in next week's summary.
If you find these summaries useful or enjoyable, you might like to contribute to the Perl Foundation to help support the ongoing development of Perl. I also welcome feedback at [email protected]'>p[email protected] or at my website.
donate.perl-foundation.org -- The Perl Foundation
www.bofh.org.uk -- My website, Just a Summary