The Perl 6 Summary for the week ending 20031228
It's the last Perl 6 Summary of 2003 already. Where did the year go?
A large part of my year went down the plughole in the great double disk
disaster which saw about 3 years of mail, a few gigabytes of photos and
my entire summary archive disappear into the ether. I have backups now.
This means I won't be going back through the archive to give you a
potted history of Perl 6 and Parrot 2003. Instead, I'll plough on with
what happened last week, starting with perl6-internals.
More object stuff
A few weeks ago, Dan asked for volunteers to implement a nice Parrot OO
interface to the Postgres RDBMS to replace the purely procedural version
that he wrote before Parrot had objects. Harry Jackson has stepped up to
the plate. Go Harry.
http://tinyurl.com/2bq9w
The trouble with threads...
Threads are evil. But they're also handy tools for a lot of work. This
dichotomy means that people have opinions about them. And they express
them. The rolling threads thread made it to p6i this week. Well, it made
it to p6i last week too, but (in the nature of the roving threads
thread) it continued this week too.
Later in the week Dan laid down the ground rules and the beginnings of
the design of Parrot's thread capabilities. Essentially, Parrot will
guarantee that 'nothing that bytecode does should be able to corrupt the
internals of Parrot'. C extensions are free to muck up everything, but
they should try not to. That's about the only guarantee Parrot will
make; keeping user level code thread safe is the job of the author of
said code. Dan went onto list the various rules about how data is shared
between threads.
This being a threads thread a few people dragged it off into a
discussion of how to design programs with/without threads. Ho hum.
Leo Tötsch got stuck into the technical meat of Dan's post, and kicked
off a discussion of the impact of threads on the memory management
system (in the presence of threads, a copying garbage collector becomes
impractical for instance, and things can get ugly when, say, thread 2
needs to grow a shared string that originated with thread 1).
http://tinyurl.com/37w6x
http://tinyurl.com/2j3xo
ParrotIO objects
Cory Spencer wanted to know if it would be possible to push a
character/byte back onto a ParrotIO stream. Melvin Smith promised that
parrot would get both "unget" and "peek" but not necessarily until he'd
recovered from a bout of flu.
http://tinyurl.com/3f8tp
Licensing of library wrappers
Why does it have to be so hard to give stuff away if you want to stop
other people claiming it as their own? Not content with having the
thread thread, this week also saw the return of the licensing thread.
Dan wants to have any library wrappers like ncurses.pasm that get
included with Parrot be as nearly in the public domain as their authors
can make them. The few people that commented agreed with him.
http://tinyurl.com/yscmh
'Python' running fast on .NET
Not content with having a threads thread and a licensing thread, this
week also saw a "Python's really quick on .NET" thread. It seems that
Miguel de Icaza has been showing off some benchmarks from 'IronPython',
a Python compiler that targets .NET. Dan was dismissive, pointing out
that the bits of Python that will 'give .NET serious fits' hadn't been
implemented. Joe Wilson wasn't so sure and, later in the thread,
implemented a couple of benchmarks that gave some worrying performance
numbers (with Perl 5 going substantially faster than Parrot). This led
to a certain amount of rewriting of the benchmarks to make them really
equivalent and Dan realizing that there's a need for a faster, less
flexible base array type.
Joe also came up with a recursive Fibonacci sequence function that ran
horribly slowly in its IMCC incarnation when using the full Parrot
Calling Convention. Again the code generated needed optimizing, but it
did point up some issues that will be looked at. Leo Tötsch in
particular redid the original benchmark with continuation creation
hoisted out of the loop and ended up with an IMCC version that,
unoptimized, ran about 33% faster than the Perl code. Work continues on
identifying and fixing the bottlenecks these benchmarks threw up.
http://tinyurl.com/2ozzz
http://tinyurl.com/29w4y
http://tinyurl.com/365x2
Future Win32 JIT issues
Jonathan Worthington pointed to some documentation from Microsoft which
states that, in the future, Win32 will turn on execution protection of
data pages by default, which has implications for any JIT system. The
fix is to use the appropriate Win32 API call to allocate memory that's
marked as okay for execution. Jonathan wondered if this would have any
effect on the current Parrot Win32 JIT. In short, yes it does (and it's
apparently already causing problems with Parrot's JIT when running on
Redhat's Fedora). Leo proposed a parrot internal API for allocating
executable memory and wondered how to probe for the appropriate system
calls at Configuration time.
http://tinyurl.com/22md9
When is enough too much
Dan is pondering adding a new type which automagically converts a Parrot
level Array into a C array but wondered if that might just be making the
NCI interface too big. Various people said that they'd find such a type
very useful and told Dan to go for it.
http://tinyurl.com/2vs9a
The "foldup" op
Dan added a new "foldup" operator to parrot's assembly language. "foldup
Px" sticks a new Array PMC into Px containing all the PMC arguments,
both from the registers and from the overflow array. This should make
working with variable argument lists and unprototyped calls somewhat
easier.
http://tinyurl.com/2h8rq
PMC registry
Dan's added an External PMC Registry to the design. The idea is to
register PMCs that get passed into external libraries and may cease to
be reachable from the current root set (those things in memory that the
Garbage Collector uses as its initial set of live objects when doing a
DOD run) for a short while. The registry of PMCs will, of course, be
considered part of the root set. It's not been implemented quite yet,
but it's only a matter of time before Leo posts a patch. Why not see if
you can beat him to it?
http://tinyurl.com/3denr
Meanwhile, in perl6-language
It was quiet. Too quiet. A single message blew through the list like
tumbleweed, discussing how Perl 5 style objects will work in Perl 6
(according to Dan, the poster, they'll work like they always did).
So, without further ado
As I Promised...
As perl6-language was so quiet this week, I've taken the opportunity to
finally get 'round to providing an overview of Roles/Traits/Properties.
Note that I've almost certainly got the syntax wrong, but hopefully it's
close enough in flavour to what Larry's been thinking about that you'll
have some idea. And it does at least give a baseline so you'll be able
to understand what people are talking about in future.
In the original paper, Traits are introduced to provide small units of
reusability that can be neatly composed with small amounts of glue code
within classes. The example they use is of a drawable circle class that
is implemented by composing the traits TCircle and TDrawing.
A Trait is a little like a partially abstract class, but instead of
virtual methods it has required methods. Here's a Perlish version of the
paper's 'TDrawing' Trait which deals with drawing in a generic fashion
(We assume a Smalltalkish environment)
trait TDrawing;
requires &.bounds, &.drawOn;
method draw { .drawOn: World.canvas }
method refresh { .refreshOn: World.canvas }
method refreshOn($aCanvas) { ... }
Meanwhile the TCircle Trait represents the geometry of the circle, with
methods like "area", "bounds" and "circumference". As described by the
original paper, Traits don't have any state of their own, so TCircle
requires accessors for the "centre" and "radius" attributes. Here's my
rough take on what TCircle might look like:
trait TCircle;
requires(Point $.centre, $.radius);
method area { PI * .radius ** 2 }
method circumference { PI * 2 * .radius }
method bounds
{ given Vector(.radius, .radius)
{ return [ .centre - $_, .centre + $_ ] } }
...
These Traits can then get composed to make a real class:
class Circle;
has Point $.centre, $.radius;
does TCircle & TDrawing;
method drawOn($self: Canvas $aCanvas)
{ $aCanvas.fill_oval($self.bounds, colour => Colour.black) }
The paper goes on to discuss conflict resolution. Suppose we have our
TCircle trait, which (amongst other things) handles testing for the
equality of circles, and we decide we need a ColouredCircle class that
makes use of a TColour Trait, which handles testing for the equality of
colours. This means that both Traits implement an "equals" method. We
need to resolve this in some fashion. Here's how the original Traits
proposal handles things (I'm making guesses as to the Perlish versions
of the syntax...)
class ColouredCircle;
has $.centre,
$.radius,
$.rgb;
does TCircle but rename( &.equals => &.circle_equals ) &
TColour but rename( &.equals => &.colour_equals );
method equals($other)
{ .circle_equals($other) && .colour_equals($other) }
Or, if you decide colour is unimportant when comparing the equality of
circles:
class ColouredCircle;
has $.centre is protected,
$.radius is protected,
$.rgb is protected;
does TCircle & TColour but without( &.equals );
Of course, this being Perl, the original Traits formulation doesn't go
far enough because Traits don't have state of their own, so let's start
speculating. Consider the TCircle Trait. it would be great if you could
specify that the Traits should provide the "centre" and "radius"
attributes if they didn't already exist (At this point I think we're
really talking about a Perl 6 Role, so lets introduce the 'role' keyword
instead)
role RCircle;
requires
$.centre is optional,
$.radius is optional;
...
In other words we state that, if the class/other roles don't provide
those attributes, then RCircle should provide its own. There probably
needs to be a way of specifying whether such attributes are private to
the role or shared with other roles etc, but that can be worried about
later. Or say you're working on a Comparable role (a la Ruby) and you'd
like a default implementation for a " &.cmp " method, you might be able
to do (but there will probably be substantially better syntax for doing
it):
role Comparable;
requires
&.cmp is implemented(method ($other) requires(&.magnitude)
{ .magnitude <> $other.magnitude });
so classes that don't provide a working "&.cmp" get a default
implementation (assuming they provide a working "&.magnitude" instead).
Larry has been talking about using Roles to implement runtime properties
too (The canonical example being "return $value but true"). The idea
seems to be that applying a property to a value turns that value into an
instance of a singleton class with an added role. However, this is
proving to be a little thorny. The problem is that, in applying a
property you sometimes want to override the underlying object's
implementation of some things (for instance, "but true" needs to
override the usual boolean methods of the underlying object) and at
others you want the property to respect any preexisting things ("$circle
but blue" should probably set any underlying "$.rgb" attributes
correctly). I'm sure the problem is soluble, but that doesn't make it
easy.
I think Larry has implied that a Role can be used in a method signature
as if it were a type, so one could write:
method some_method(DrawableRole $glyph) {...}
and any class which used the DrawableRole role would satisfy the type
requirement. If you think about it, this means that you could use a role
like a Java interface. In the 'pure' interface variant you would only
have a "requires" section:
role NSDraggingDestination;
requires
{ method draggingEntered(NSDraggingInfo sender) {...}
method draggingUpdated(NSDraggingInfo sender) {...}
method draggingEnded(NSDraggingInfo sender) {...}
method draggingExited(NSDraggingInfo sender) {...}
method prepareForDragOperation(NSDragginInfo sender) {...}
method performDragOperation(NSDragginInfo sender) {...}
method concludeDragOperation(NSDragginInfo sender) {...} }
I want Camel6Bones, and I want it now (actually, I'd be happy with a
CamelBones that worked with Perl 5 and OS X 10.3, but I like to think
big).
The toolmaker in me notes that Roles *really* come into their own when
you have tool support for them. The authors of the original Traits paper
modified the Squeak class browser in such a way that a Class could be
looked at as a collection of Traits or you could flatten the traits out
and view it as a collection of methods. Hopefully it will be a good deal
easier to write similar tools for Perl 6 than it is to write them for
Perl 5.
Acknowledgements, Announcements, Apologies
Thanks to everyone for reading these summaries, and special thanks to
those of you who've sent me feedback over the course of the year. My
postbag has been small, but positive. No thanks at all to the
scum-sucking lowlifes who continue to pepper my mailbox with spam; I've
stuck with one main email address for nearly 10 years now, and I'm not
about to change it just because of the utter arsewits who keep trying to
sell me Viagra or Lolitas or a fortune in Nigerian bullion. It doesn't
mean I'm not tired of it though.
Thanks to Leon Brocard for being so good humoured over the months that a
certain running joke has dragged on. Leon, I promise that you will only
be mentioned in the 2004 summaries if you've actually done something
Parrot or Perl 6 related to warrant your inclusion.
Thanks and best wishes to Larry, Damian, Dan, Allison, Leo, Luke,
Melvin, Garret, Steve, Daniel, Brent, Jürgen, Clint, Gregor, chromatic,
the various and several Michaels, Austin, Smylers, David, Joseph,
Stéphane, Gordon, Jonathan, Paul, Ziggy, Andy, Chip, Simon and all the
others that I've missed for giving me so much to write about (even if I
haven't quite understood what I'm supposed to be summarizing on
occasion).
If you find these summaries useful or enjoyable, show your appreciation
by contributing to the Perl Foundation to help support the ongoing
development of Perl. Money and time are both good. Also, I'm always
pleased to get feedback at [EMAIL PROTECTED] and traffic at my
website.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://www.bofh.org.uk:8080/ -- My website, Just a Summary
