The Perl 6 Summary for the week ending 20031214
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.
Testing for null
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.
http://groups.google.com/[EMAIL PROTECTED]
How many comparison ops do we need again?
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.
http://groups.google.com/[EMAIL PROTECTED]
Incorrect scoping of constants in IMCC
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.
http://groups.google.com/[EMAIL PROTECTED]
Objects and Namespaces
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.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
-- The New Namespace
Dan Sugalski, IMCC Bugfinder General
Dan's been writing more PIR code by hand, and is discovering
infelicities as he goes.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
Macros, PIR and PASM
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.
http://groups.google.com/[EMAIL PROTECTED]
Meanwhile, in perl6-language
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).
http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf -- Traits
paper
Iterating through two arrays at once
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
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.
http://groups.google.com/[EMAIL PROTECTED]
Vocabulary
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.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED] -- Casey's POD
Enums and bitenums
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).
http://groups.google.com/[EMAIL PROTECTED]
Acknowledgements, Apologies, Announcements
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]
or at my website.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://www.bofh.org.uk:8080/ -- My website, Just a Summary
