Planet Perl Six

Carl Masak: The typo trap: a farcical FAQ

Mon, 08 Feb 2010 12:54:56 +0000

Help! I'm getting the error "invoke() not implemented in class 'Undef'" in my large application. What did I do wrong?

You've mistyped a class name which sits inside a namespace.

How am I supposed to figure that out?

I didn't say it was a particularly good error message.

It's like this: if you mistype a class name which is not in a namespace, you'll get an informative error message:

$ perl6 -e 'A.foo' Could not find non-existent sub A in Main (file src/gen_setting.pm, line 324)

However, if you mistype a class name which is in a namespace, you will get an uninformative error message:

$ perl6 -e 'A::B.foo' invoke() not implemented in class 'Undef' in Main (file <unknown>, line <unknown>)

So there's your error message. Linking it to the actual cause is something which you'll learn by experience.

So in that case, I don't get the name of the class which was mistyped in my program?

Correct.

And I don't get the line number of my typo?

Indeed not.

Or the file?

Right. You'll get no information about the location of the typo.

Is that intentional?

Well, no. As you see from the error message above, the information is meant to be printed, but it comes out as (file <unknown>, line <unknown>) instead.

Why?

Rakudo is built on top of Parrot. Usually, Rakudo generates its own error messages, but in some cases, Parrot will also generate an error. The error invoke() not implemented in class 'Undef' is such a case. When a Parrot-internal error like this one occurs, Rakudo will not be able to extract the annotation information required to provide a sensible line number and file.

I... I see.

Yeah. Sorry about that.

Are you able to pick up the irony in the fact that when I use namespaces to help mitigate the complexity of my project, I end up with an error message that in fact makes it harder for me to manage the complexity of my project?

Hold on.

Yes. We are able to pick up the irony in that. Quite easily, in fact.

Consider not using namespaces at the present juncture. They are very useful, but they are also known as a frequent source of annoyances like this.

By the way, I couldn't help but note that the line number and file information in your first example doesn't make any sense either. What the heck is src/gen_setting.pm and line 324?

Well, uh, that's the last line of internal Rakudo code that actually has a working line-and-file annotation. It's nothing that should reach the user, really.

So that's kinda broken, too?

Annotations are currently broken, yes. Apologies.

Back to my mistyped type name. My program is distributed over fifteen modules and ten thousand lines of code. How do you propose I find my typo?

First off, we recommend that you compile often. That way, the diff from the last working code will not be too large, and you will not have to visually scan so much text hunting for your typo.

Secondly, it's often useful to have your project in a version tracker such as Git, so that you can do git diff to see the changes against the index, or against the latest commit.

Thirdly, when all else fails, you can always insert print statements into your code, to try to bisect the origin of the error.

So in other words, Rakudo is no help whatsoever when this occurs?

Now, that's not quite fair. Rakudo tells you that the error occurs. That's actually useful information.

And you consider that adequate?

No, I didn't say that! No-one is happy about this situation. It's just the way things are.

So it can't be fixed?

Theoretically, yes. But not easily. Remember that the error occurs in Parrot.

Don't Rakudo and Parrot developers confer with each other?

Oh, sure we do. Do not assume that we're deliberately causing this situation. It's just that the current way Rakudo and Parrot are welded together makes the situation non-trivial to rectify.

So this problem is going to go away with the advent of the new ng branch?

There's nothing to indicate that this would be the case. In ng, you currently get a Null PMC access:

$ ./perl6 -e 'A::B.foo' # ng branch Null PMC access in invoke() current instr.: '_block14' pc 29 (EVAL_1:0) called from Sub '!UNIT_START' pc 984 (src/glue/run.pir:17) called from Sub 'perl6;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1) called from Sub 'perl6;PCT;HLLCompiler;command_line' pc 1489 (src/PCT/HLLCompiler.pir:794) called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown file):-1)

To its credit, Rakudo ng does provide more information in this case, but unfortunately the information is of a kind which was concealed from the user in Rakudo master about a year ago (because it tended to be very uninformative).

Just to summarize: this all sucks, right?

That would be a succinct description of the state of this particular error message, yes.

I heard that the Perl 6 community has adopted very high standards with respect to error messages. There's talk about "awesome error messages", and last summer I was in the audience when Larry Wall demonstrated how good Perl 6 was at reporting error messages to the user. How does this error message square with all of that?

The awesome error messages are like a platonic ideal towards which all implementations aspire. Rakudo, being rooted in our imperfect physical world, doesn't always get all the way. Yet.

I'm about to go visually scan ten thousand lines of code, looking for where my error message might have originated. Any last words?

We value your efforts as an early adopter of Rakudo. Your feedback is important to us. Have a nice day.

Jonathan Worthington: Catching up: two Rakudo Days from December

Sat, 06 Feb 2010 22:45:42 +0000

Today plenty happened in Rakudo land - in fact, it was my most active day's Rakudo hacking in quite a while. colomon++ also made some great commits, and between us a lot of things moved forward today. For my part, hashes and pairs are in much better shape.

I wrote before that I'd got some Rakudo days left to write up; there are two of them, but I'll cover them both in this post, since some of the work crossed the two of them anyway. Here's what I got up to between them.

Filled out attribute composition logic for role application. A good chunk of this was written in NQP - in fact, all of the role appliers are. :-) Along the way I brought roles up to speed with the attribute part of the meta-object protocol - I'd forgotten that when doing it for classes, though since we couldn't compose attributes at that time it wasn't so interesting anyway. The end result was that we could pass S14-role/attributes.t again.
The specification states that if in a role you do inheritance, then this is just passed on to the class that the role is eventually composed in to, and added to that class's parents. We never had any support for this in master; with a neat meta-model approach it became rather easier to get it in place in ng.
Got BUILD/CREATE fixed up a bit and added back support for "has $.answer = 42" style declarations, again through the new attribute sub-protocol.
Got us handling non-block where blocks again, and added Block.ACCEPTS back - in Perl 6.
We had various "helpers" to let us do some of the low-levelish stuff in PIR. This is mostly for the places where we need those things in place in order to be able to compile the rest of the built-ins that are written in Perl 6. However, a couple of these helpers knew too much about Parrot and too little about the meta-model, which abstracts it away. So, I re-wrote some of those in terms of the meta-model. Much cleaner.
Before we relied entirely on Parrot for our "do we do this role" checks. However, given the unfortunate semantic mis-match between Parrot's built-in role support and what we need for Perl 6 (I did try and influence things in a different direction back when we were doing Parrot's role support, but failed), I've been gradually working us towards not relying on those for Perl 6's role support. (In master, it felt to me like we have almost as much code working around the semantics of Parrot roles as we'll need to have to not use them.) Anyways, the divorce isn't quite complete yet, and it's not even a goal for the ng branch. However, I did make a notable step towards it by getting our .does checks implemented entirely in terms of the meta-model. In the long run, I'm hoping we may be able to write the entire role implementation in NQP, which helps with the even-longer-run dreams I have of Rakudo having additional backends. But that's for The Future. :-)
Cleaned up and re-enabled sigil based type checking in signatures.

Thanks to Vienna.pm for sponsoring me to hack on Rakudo, not only for these two days, but also throughout 2009!

Jonathan Worthington: The importance of a break

Sat, 06 Feb 2010 00:31:49 +0000

Several days before Christmas, encouraged by my mum asking, "when you're going to start your Christmas break", I stopped working and hacking on stuff and started relaxing. Until then, I hadn't realized just how tired I was. I slept quite a few ten hour nights in the following week, and had an enjoyable Christmas break. I'd figured I'd maybe take a week or so's break, and then get straight back to things, but a week on I had no motivation or energy to dig in again whatsoever. So, I decided my break would go on through New Years. New Year's celebrations this year involved curry - something I certainly wouldn't mind it involving again.

Early January brought several days in Sweden, part of planning for an upcoming refactoring of my work/location - there's details on my personal blog, but the short version is that I've accepted a job at a Swedish startup and will be moving there in March. It's not full time, so I'll continue to have time for Perl 6 development. They know about and, happily, are supportive of my involvement in Perl 6 and my continued attendance of Perl conferences.

I spent a weekend in Prague on the way home. I did it by train rather than flying, which was enjoyable. It snowed almost my entire time in Prague, and I caught a cold in the following week, but it was kinda worth it to wander around this beautiful city. Didn't bother studying Czech at all, and sorta got by with speaking Slovak, though some folks heard me speak and immediately concluded English would be easier. :-) Somehow it kinda felt like I was back somewhere I belonged, even though I'd never been there before. I love central Europe, and excited as I am about Sweden, I know I'll miss this part of the world a lot.

Anyway, I eased back into some work in January, but mostly took it quite easy. The happy result is that, come February, I'm finding myself recharged and ready to dig back into things again. I got some nice commits done to Rakudo yesterday, and today I meant to, but instead participated on an interesting thread on p6l and did some other useful meta stuff (like this post). Tomorrow should have plenty of hacking time though, and I'm looking forward to it. I also have a couple of blog posts to do about Vienna.pm-funded Rakudo Days I did in December, but never got around to writing up; thankfully I did make notes on what I did on them. :-) My main focuses from here on will be on:

Continuing to get Rakudo's ng branch into shape - we'll make it master soon. A lot is missing, but things are going back fast and often very neatly. It's easy to focus on what it doesn't yet do that master does, but it has many things right that master does not - now including laziness!
Finishing up my signatures grant. I really, really want to do that within the next couple of weeks.

Anyway, that's what's been up with me. If you take away anything, it's that you may not realize how much you need a break from something until you take it, and if it's not the only thing putting food on the table, then it's probably better to take the needed amount of break and come back revitalized. I guess the other option is to dig back in regardless, but I suspect that's the path to burnout, something I'm quite keen to avoid.

More technical blabbering here soon. :-)

Carl Masak: Blast from the past: E02

Thu, 04 Feb 2010 14:47:06 +0000

SF took my challenge to heart and started producing a "modern Perl 6" version of the example code in E02. His thought process can be seen here, and here.

After being a bystander for a few hours, I coulndn't restrain myself anymore: I produced my own version. I should say at once that it's quite different from SF's: while he keeps close to the original E02 (which, in turn, sets out to prove that Perl 6 is/was not very different from Perl 5), my version is a bit more liberal in its interpretation. I do mix in some of my personal preferences into it. Some examples:

We don't do $ARGS prompts("Search? ") anymore, but there's a nice &prompt function which I used instead, together with a while loop.
The &show function now uses gather/take, rather than printing directly.
Also, I avoided the statement-modifying mess from the original E02 &show code.
Also, E02's &show makes a point of using a slurpy @_ rather than naming the paramters. I don't. (Neither does SF.)
It just makes sense to use a given/when construct in the &insert function. To its credit, E02 tantalizingly hints of it, but then does a MIB mind-wipe. (You don't recall that bit? Oh well...)
In the same function, E02 puts undef to initiate the child nodes to some empty value. Both SF and I independently realized that just any undefined value won't work if &insert is to have %tree in the signature, because %tree only binds to an Associative value. SF solved it by putting Hash (an undefined Hash type object) in the child nodes, and changed it to Hash.new in the later version. I used {}, which should be equivalent to Hash.new, but IMHO more idiomatic.
The whole traits business hadn't solidified in 2002, but I believe that the end result is both more realiable, more useful, and prettier. You'll have to judge for yourself.

I believe rewriting the exigeses in modern form is a very worthy activity. I hope we'll see more of that. Perl 6 suffers a bit from stale, outdated documentation, and having these in new versions would be valuable.

It's also a very interesting historical activity to read the old apocalypses and exigeses, as I increasingly find. Perl 6 has come a long, long way since 2001.

Herbert Breunung: [Help] Diploma, Pills and enlarge your Perl

Mon, 01 Feb 2010 23:54:29 +0000

Yes my November edits are on halt so I gave the TPF Perl 6 wiki some love. Repeatedly that Wiki gets spammed. Unfornunately i didn't found the admin, so had to deleted all spam by hand. If anybody reading that, please help to tighten this socialtext instalation.

perl6.announce: Announce: Rakudo Perl 6 Development Release #25 ("Minneapolis") by Patrick R. Michaud

Mon, 01 Feb 2010 09:41:19 +0000

[This notice is going out a bit late; the release was indeed
produced on time, but I was delayed in sending out this notice.
With apologies for the delay... --Pm]

On behalf of the Rakudo development team, I'm pleased to announce the
January 2010 development release of Rakudo Perl #25 "Minneapolis".
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the January 2010 release
is available from http://github.com/rakudo/rakudo/downloads .

Rakudo Perl follows a monthly release cycle, with each release
code named after a Perl Mongers group. The January 2010 release
is code named "Minneapolis" for Minneapolis.pm, hosts of the annual
Frozen Perl Workshop [1]. In 2009 the Frozen Perl Workshop featured a
one-day hackathon for Perl 6 and Rakudo development, which ultimately
informed the design and implementation of the current build system.
(The 2010 Frozen Perl Workshop will be on February 6, 2010, for those
interested in attending.)

Shortly after the October 2009 (#22) release, the Rakudo team began a new
branch of Rakudo development ("ng") that refactors the grammar to much more
closely align with STD.pm as well as update some core features that have been
difficult to achieve in the master branch [2, 3]. We had planned for
this release to be created from the new branch, but holiday vacations
and other factors conspired against us. This is absolutely the final
release from the old development branch; we expect to make the new branch
the official "master" branch shortly after this release.

This release of Rakudo requires Parrot 2.0.0. One must still
perform "make install" in the Rakudo directory before the "perl6"
executable will run anywhere other than the Rakudo build directory.
For the latest information on building and using Rakudo Perl, see the
README file section titled "Building and invoking Rakudo".

Some of the specific changes and improvements occuring with this
release include:

* Rakudo is now passing 31,957 spectests, or 85.7% of the available
test suite. This is roughly the same level as the December 2009
release (because most effort has taken place in the "ng" branch
as described above).

* Rakudo's calling conventions have been updated to match changes
in Parrot 2.0.0's calling and context structures.

The Perl 6 language specification is still in flux. Please take note of the
following changes, which might affect your existing programs. In the next
release of Rakudo, the deprecated features will likely be gone.

* The root of the object hierarchy has been changed from 'Object' to 'Mu'.
The type 'Object' goes away.

* The term 'undef' is gone. You can replace it with other constructs,
depending on context:
- 'Nil' is undefined in item context, and the empty list in list context
- 'Mu' is the most general undefined value which does not flatten in list
context
- as a smart matching target, you can replace '$obj ~~ undef'
by '$obj ~~ *.notdef'

* Builtin classes will derive from 'Cool' (which itself derives from 'Any').
Most of the builtin methods on these classes will be defined in the
'Cool' class instead of 'Any'. See Synopsis 2 for more details.

* Starting with the next release, we will likely switch to using
"YYYY.MM" instead of "YYYY-MM" (dot instead of hyphen) as release
identifiers. This is intended to simplify building and packaging
for other distribution systems.

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible. If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compiler@perl.org
mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#26) is scheduled for February 18, 2010.
A list of the other planned release dates and codenames for 2010 is
available in the "docs/release_guide.pod" file. In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release. Parrot releases the third Tuesday of each month.

Have fun!

[1] http://www.frozen-perl.org/
[2] http://use.perl.org/~pmichaud/journal/39779
[3] http://use.perl.org/~pmichaud/journal/39874

chromatic: Perl 6 Design Minutes for 27 January 2010

Fri, 29 Jan 2010 21:00:38 +0000

The Perl 6 design team met by phone on 27 January 2010. Larry, Allison, Patrick, and chromatic attended.

Larry:

tweaked definition of when a series operator is considered infinite
nailed down more list assignment semantics with respect to interators
clarified how ($a, $b, @a) = 1..* works
KeyWeight deletion criterion kept consistent with other KeyHash types
negative keyweights are allowed to fail at pick time
"mostly eager" now assumes unknown closure generators are probably infinite
random whackage on List, Seq, Parcel, Capture, Iterator, Nil etc.
List is now simply the iterator role, and doesn't do Positional
Seq takes over Positional duties for reified (or reifiable) value lists
think of Seq now as a constant Array (but also lazy like Array)
Iterable now means you can ask for an iterator, but doesn't do List
Array, Seq, etc do Iterable, but not List
only actual iterators do List
Nil is defined as a suitable sentinel for both list and slice iterators
continued to rethink that with pmichaud++ et al
we'll probably end up with an EMPTY special exception object to be the iterator sentinal
proposed an E operator to go with it to make testing for EMPTY across multiple iterators very fast
other than that, mostly just bug whacking, no major refactors
still thinking about doing real LTM for STD
did lazify Cursor's fnum->fate translations for shorter LTM candidates in preparation for smarter LTM
we don't need special objects for the items that get matches
we do need to think more about the hyper cases
how to do list processing using balanced trees of delegated sub refs
don't want to build in serial assumptions where we don't need them

Patrick:

made the Rakudo #25 release last week
it was much easier to make the release than explain what we were planning to do instead
also working on iterators and lists
NG branch is blocking on that
worked on the design in my head for three weeks
realized that we were doing iterators completely wrong the other night
Larry's making some useful changes to the spec in response
there are still some unclear spots in the spec
we need an implementation to figure those out
my biggest question is the relationship between List, Parcel, Itertor, and array
as of this morning, I think I have it
that code seems to be working and efficient
so far it's working well
continuing with that
wrote a very short range iterator prototype that colomon has used
also write a map iterator that works
coming up with examples for the zip operator was nice
good ideas for what we need to be able to do
objects that can iterate have a .iterator() method
to interpolate that into a list, .list() returns a flat Parcel for that iterator
Parcels know how to generate Iterators
those know how to handle Iterators of Iterators
I suspect that's how we do hyper iteration
change Parcels to understand that
adding pieces back into the ng branch
next I have to fix slurpy parameters
many of our builtins need that
need to figure out Jonathan's code to do that
after that, I'll do arrays
that should remove the blockers on the ng branch

Allison:

working on Pynie
Francois has helped greatly to update it for Plumage

still working on the TT #389 fix
think I have the right design, just need time to implement it
working on a potential new time for #parrotsketch

Allison:

thinking about hackathons
would be nice to have a Rakudo hackathon at YAPC::NA

Parrot will come up; didn't it come up about half the time last year?

Patrick:

it was all Parrot

Allison:

you'll have an influx of Rakudo interest two months after Rakudo Star

Patrick:

probably will have one before then
but can tell people "Go to YAPC; we'll show you how to help in person there"

Herbert Breunung: first new november articles, please review it

Fri, 29 Jan 2010 19:44:05 +0000

According to my modus operandi I wrote the first 2 articles in the november wiki about Pugs and Parrot. Next will follow but please participate, get an account from masak (we have a channel at irc://irc.freenode.org/november-wiki) or write me your suggestion to lichtkind@cpan.org and i wrap text around it.

Carl Masak: Mildew, Sprixel, Vill: In praise of the alternatives

Fri, 29 Jan 2010 13:54:30 +0000

Not all of Perl 6 is Rakudo. Well, when I use Perl 6, it is. But I'm hoping 2010 will change that. We have a few other implementations out there, which fall in the "small but promising" category.

Mildew

From the README:

Mildew is an experimental implemention of Perl 6, written mainly in Perl 5. It is named in the tradition of 'yeast', 'slime' and 'mold', which were/are related projects.

I can't say I've ever understood the idea behind naming projects after icky things, but I like the projects as such. They seem to generate a kind of "basic research" which strengthens the foundations of Perl 6. The decade-old project has always been about attacking the enormously big task of implementing Perl 6 from different angles — and I like the angle pmurias++ and ruoso++ are taking.

Mildew uses the 'viv' parser and the STD.pm grammar to convert Perl 6 source code into an Abstract Syntax Tree. An AST is a data structure that describes what the Perl 6 program is meant to do. Mildew contains various experimental backends selected by the -B and -C switches to export or to execute the code in the AST.

Mildew targets both SMOP (written mostly in C) and the Google V8 JavaScript compiler.

Sprixel

From the README:

sprixel (anagram of perlsix): viv and STD.pm parse Perl 6 source, emitting an Abstract Syntax Tree in YAML, then sprixel walks the AST using its trampolined, stackless, continuation passing style interpreter written in JavaScript and executed by Google's V8 JavaScript compiler and runtime engine.

I know diakopter++ is playing around with both JavaScript and C♯ implementations of Perl 6 rule engines. That is also an area which excites me, and where I'm glad people are making headway.

Vill

From the README:

'vill' is the ugly temporary name of this project that connects 'viv' as Perl 6 front end to LLVM as code generating back end. It sounds too much like 'vile', or mock German 'will', but it fits.

Heh.

Unlike other Perl implementations such as Pugs, Rakudo, Sprixel and Mildew-js, 'vill' produces native executable files. [...]

Whoa! That's potentially very attractive.

The slowest part of 'vill' is 'viv', because that runs as a separate Perl 5 child process. The medium term plan will be to use the STD.pm grammar, but replace the 'viv' parser with a new one to be written in C. [...] If the dependency on 'viv' can be removed, the ugly 'vill' name will no longer be appropriate, and it will be time to think of a better one [...]

I'm actually hoping I might be able to help with the C-based parser.

Conclusion

Rakudo is the implementation that shows up on the radar of most outsiders right now. (And with good reason.) But much exciting work is going on in the background, with implementations like mildew, sprixel and vill.

I'm sure this will come off as almost self-evident, but I'll say it anyway: the moment an alternative implementation will cross a threshold into the area of the really interesting, is when it provides a significant chunk of Rakudo's functionality (which is saying quite a lot), together with some feature that Rakudo doesn't have. Given Rakudo/Parrot's current performance, the most obvious feature would be speed. But it might also be something else, such as a bridge to Perl 5, or a very solid metamodel. The more ground-shaking the new feature, the less important will be the delta between the alternative implementation and Rakudo.

At the very least, I think one of the above implementations will pass through the Mach 1 barrier in 2010, and attract a serious user base, and more developers. I'd love for Rakudo (and Pugs) to have some company up there among the "big" implementations.

Exciting times!

chromatic: Perl 6 Design Minutes for 20 January 2010

Thu, 28 Jan 2010 00:10:27 +0000

The Perl 6 design team meet by phone on 20 January 2010. Allison, Patrick, Will, and chromatic attended.

Allison:

did distro testing on Ubuntu and the Mac
set up a Hardy chroot; Parrot works just fine there
have a feeling we missed some deprecations, but we have a lot in there
enough to work on for three months

I added the STRING idea, to give us the possibility of the value semantics change

Allison:

less stressful to have three months at a time
otherwise working on class assignments

Patrick:

family illness knocked me out for a few days
we'll postspone the January release for up to a week
going to make the Rakudo-ng branch the master branch
that won't take more than a week
we'll release by Thursday of next week
also need to make the -ng branch build with Parrot 2.0.0
need to merge some outstanding patches to make that work

are you going to stick with 2.0.0?

Patrick:

unless we need a change in Parrot that we can't live without, yes

Will:

we could do a point release if you need one

Patrick:

that's up to Parrot
from Rakudo's perspective, that's not terribly important
we're shifting everything around for the -ng branch
we'll definitely stick the February release to Parrot 2.1
I'll post messages to the list about the new release plan shortly

Will:

working on the one_make branch in Parrot
trying to mark dependencies properly in a single Makefile
get some of that out of the configure system
we should be able to merge to trunk in a day or two
there's still more work to do, but we're at a merge point soon

released Parrot 2.0.0 yesterday
sending out release announcements soon, but the code is out
Stephen Weeks helped me fix up PGE not to fetch methods from namespaces
should be able to merge the TT #389 fix branch to trunk very soon
will take a look at other Rakudo blockers after that

chromatic: Perl 6 Design Minutes for 13 January 2010

Tue, 26 Jan 2010 22:54:19 +0000

The Perl 6 design team met by phone on 13 January 2010. Larry, Patrick, and chromatic attended.

Larry:

made constant declarations more consistent with type declaration syntax
removed various spec fossils regarding the old :by modifier
reworked KeyHash docs to make the semantics clearer
refactored regex AST methods out of Cursor
symbol table files are now compiled into their own subdirectory
STD can now use modules defined in the test suite
testing STD against the test suite now produces many fewer warnings about missing modules
STD now specifically disallows forms like :!foo(0) and :5bar[42] that supply unexpected args
STD now tracks 'of' types in declarations and prevents spurious 'of' types
STD treats anon enums, subsets, and constants etc more consistently
removed old type slot from constant declarator, now uses more standard type slots
random bug fixing
errors with expectation lists are less noisy, no longer reporting lookaheads and whitespace

Patrick:

lots of thinking
looking at Rakudo-ng today
plan to do lists tomorrow
want to get those out of the way
Jonathan and I think we can merge it for the January release
should know more after the weekend

working on TT #389
:method should not add entries to NameSpace
PGE/TGE have problems
will not land for 2.0
may add (and immediately deprecate) an experimental op to help migration

Herbert Breunung: November is over, i don't care

Sun, 24 Jan 2010 00:24:49 +0000

I'm back, english-hackin on November. it was planned to make november the month to push november foreward, but maybe this will happen now in february. currently just pushing some content around, to make smaller, better readable pages. The content will become also better linkable.

I'm delighted that viklung and masak solved the more pressing half of the issues i filled in the november tracker, but 5 min ago I filed a new one.

as i currently preparing an article about the upcoming rakudo star, its easier for me to fill more conent in the p6 related wikis.

chromatic: Perl 6 Design Minutes for 06 January 2010

Sat, 23 Jan 2010 00:12:46 +0000

The Perl 6 design team met by phone on 06 January 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

in Spec Land, renamed p{} to qp{} to avoid using up another common single letter
bare say/print is now just a warning
Carl Mäsak dug up fossilized restriction on hash literals, which I removed
since the insides of blocks are now parsed as statements, there is no longer an inconsistency in line-ending curlies
refined the picking vs grabbing semantics with respect to immutable vs mutable bags and such
to avoid legacy confusion, renamed break/continue to succeed/proceed
clarified that an implicit succeed returns the value of the whole when block
it is not somehow magically inserted around the last statement
renamed true to so to avoid confusion of the predicate with the True enum value
at the suggestion of moritz++, split Any up into Any and Cool types
Cool stands for Convenient OO Loopbacks, or any other acronym you'd like
the built-in types derived from Cool are the ones that do Perlish dwimmy coercions
user types still derive from Any by default, so aren't born with gazillions of methods
conjecturally, also keep "last-resort" multis in Cool package
responded non-explosively to a potentially explosive rant/twitter
clarified various things in response
it is not necessary that all implementations be equally good at everything
there will be a minimal Perl 5ish grammar alongside STD that any VM can support as a well-behaved subset
it is also acceptable to support bug-for-bug compatibility with Perl 5
the language designer is neither omniscient nor omnipotent
the design process is therefore convergent on the part of all parties involved
the rate of convergence is an emergent property, and is to be forced
convergence is deemed to be positive as long as anyone is still working on Perl 6
the solidification of the spec is also part of the convergence, and depends on proven implementation
unproven parts of the spec are to be considered implicitly conjectural
as implementations converge on specs, we can throw out or delay parts of the spec that as yet unproven
everyone is allowed to panic once.
on to implementation, found fencepost precedence error inside list prefix
moved the default initparse method from STD into Curso so other grammars don't have to define it
added quote modifier :p (aka :path) so we can form the qp{} path literal
installed better warnings about bare say/print
generalized the say/print warning to anything a p5er might try that might be in p6 without the defaulting
STD and CORE now support recent renamings to so, succeed, and proceed
no longer reports "Bogus statement" when "Missing term" is more accurate
now catches /\b/ and advises to use an appropriate p6 word boundary assertion instead
emits better message when an intended reduce is interpreted as composer
detects most attempts to use postfix after whitespace, and suggests omitting whitespace
now parses tick-less embedded comment syntax as line-end comment (but still warns for now)

Patrick:

took the last couple of weeks off
keeping up with things, but not much writing code
read the S01 changes with great interest
glad to see them
answered some PGE questions for Carl

Larry:

we've talked about them all along
they weren't written down in an obvious place

Will:

working on Parrot
trying to move as much out of the configure process into a Makefile as possible
intended to improve the build
attempting to remove recursive makes
avoid unnecessary rebuilds
improve dependency tracking in the build
probably ready after 2.0

Patrick:

I'm impressed
thanks for taking that on; we needed it

Allison:

working on deprecation notices
we've talked about a lot of things over the past six months
not sure they're all in the file appropriately

working on bugfixes
also working on deprecations

Patrick:

I intend to merge the ng branch before the January release
some people are antsy, but I have a lot of confidence
we'll probably pass about 70% of the test suite
it looks like a regression, but we have different features added now
lazy lists work, for example
lots of things fudged in the previous version work now

Carl Masak: Code generation and stone soup

Fri, 22 Jan 2010 16:41:30 +0000

I don't know what kept me away from generating code for so long. Fear and prejudice, perhaps.

I've been trying it the last few days, and I have two things to say. First, it's like learning to program all over again. Remember that sense of power from the early days, when just picking up coding? "Hey, I can program this piece of code to do whatever I want." Well, guess what? That feeling comes back when one starts down on the path to madn... erm, to code generation. Only it's stronger. "Hey, I can program this piece of code to program that piece of code to do whatever it wants!" I think I've just discovered meta-hubris. Most likely, I'm not the first to do so.

Second, there's a flip-side to the feeling of power. That other feeling is how you feel when you knit your brows and wish that your neurons would line up a bit better so you could think more clearly about the problem at hand. Who would have thought, that feeling is also stronger when you're suddenly writing two different, entwined and related programs at the same time, in the same file. In my case, the knitted brows turn into an empty stare and a jaw left slackly agape, as I sit there wishing that I was better at context-switching between runloops.

Honestly, I think I expected eval to be the source of much programmer confusion, but I have to confess that it seems I underestimated the vistas it opens up when you buy into the idea of generating exactly the piece of code you need for the task (from an AST, say), and then eval it into a closure. That's what the back end of a compiler ends up doing, so maybe I shouldn't be so surprised that it's a versatile technique.

Lately, I've been in the business of squeezing every drop of juice out of the already implemented control flow constructs already implemented in Rakudo. I'm writing a p6regex→p6 compiler, you see. (Yes, that's a rather crazy notion; thanks for asking.) Along the way, I've often felt the need for not-yet-implemented control flow. This has led me to this hope-inducing maxim:

Every type of control flow in programming languages is just convenient sugar for if statements and while loops.

ifs and whiles are the stone soup to which all the rest of our control flow can be added as seasoning. ifs let you conditionally skip ahead in code, and whiles allow you to conditionally skip back. That's all you need.

Here are some examples.

Switch statements are just sugar for chained if/elsif/else statements. Even Perl 6's given/when constructs.
The variants next, last and redo, either with or without a label to affect a less-than-innermost loop, can be desugared to sad boolean-ish variables, plus some if statements to appropriately regulate the expression of the code inside the loop. (Yes, go ahead and twitch just thinking of it. That sugar is there for a reason.)
Subroutines and subroutine calls can be simulated with the appropriate use of a switch statement and an explicit call stack stored in an array variable.
Even exceptions, or more generally continuations, can be desugared in this way. As soon as you have total control of the call stack, you're free to save and rewind to some previous state to your heart's content.

Aside from the switch statements and unlabeled next etc, which already work very well in Rakudo, I've been doing the whole list of desugarings in GGE (the regex compiler). The part with the continuations was especially fun. I needed them for backtracking, at least as long as the compiler was only an interpreter.

But then, during a fruitful discussion with diakopter++, I was told how to emulate (delimited) gotos with a switch and a loop. The idea is quite obvious in retrospect: just keep the current 'label' in a variable, and switch on it in each iteration. Presto! I should have thought of that. I don't even need to flee to PIR any more.

I took the idea and generalized it to delimited gosubs: instead of keeping the current label in a scalar, keep it at the top of a stack. Define macro-like constructs to push to (local-branch) and pop from (local-return) the stack. Suddenly I don't need continuations as much.

Result: this. We send in the regex /<[a..b]> | <[b..e]>/ on the top line, along with the target string c to match on. The program generates an AST, an anonymous subroutine which executes the regex in atomic Perl 6 operations, and finally a match object which indeed finds c to be a match.

Here's a similar but slightly more involved example. And here's one doing captures and backreferences inside a quantified non-capturing group. Isn't that exquisite? (Ok, bad choice of word. Sorry.)

As I said, I wrote most of with a feeling of being not just in over my head, but of being in over my head twice. I'm still a bit surprised it works. The runtime compilation seems to introduce a bit of a speed penalty, but (1) it's a one-time cost, since you can re-use the regex object, and (2) I told you it would be slow.

The code-generating work still resides only in a local branch on my computer. I'll push it to master as soon as I'm done bringing GGE back to its former capabilities. (Update 2010-01-24: Done, and done.)

Code writing code. What a concept!

chromatic: Perl 6 Design Minutes for 16 December 2009

Fri, 22 Jan 2010 01:52:43 +0000

The Perl 6 design team met by phone on 16 December 2009. Allison, Patrick, Jerry, and chromatic attended.

Patrick:

finished my Hague Grant
sent the final report to Jesse to wild approval
drafted a new version of PDD 31 on HLL interop
write some code to implement part of that in NQP's HLLCompiler
added various tests
need to get languages using that now
Rakudo will use that
it's the basis for Rakudo's use and import
if it works for Rakudo, it should follow for other languages which use HLLCmpiler
had a few comments about missing pieces and corrections
it's still a draft spec, but we need iteration to finish the spec
working on little bits of code here and there
adding features for projects which use NQP
trying to return to using Rakudo and updating the -ng branch

Allison:

working on the Pynie refresh this week
started over with the Python 3 grammar
have that translated into NQP-rx
it compiles and can parse a few things
working my way through the grammar
no actions set up yet

Patrick:

there is a .DEBUG rule
call it on a subrule to turn on tracing from that rule down
that saves you from having to put in panic statements

Allison:

is there a good NQP-rx tutorial for actions?

Patrick:

working on it
is your work in the Pynie repo?

Allison:

it's in Mercurial on bitbucket.org under project pynie
that's what Python 3 uses
also the Parrot roadmap session went very well

Jerry:

we still have some actions to take based on that work
need to convert our priority list into Trac tickets and wiki items
Parrot's goal for every month until Rakudo * is to support Rakudo * and HLLs in general

Allison:

that's valuable
it changes our priorities in the next year
it moves things between "would be nice" and "necessary"

worked on the roadmap session
helping with the Context/CallSignature merge
will do a dry run of the Rakudo release today

perl6.announce: MiniPerl6 3.0 "Perlito" - Go lang, JVM backends by Flavio S. Glock

Thu, 21 Jan 2010 09:01:29 +0000

MiniPerl6 (mp6) is a subset of Perl 6, which was designed as a light
bootstrapping language.

Changelog for version 3.0:

- Go language backend; using Go: http://golang.org/

- Java-class backend; using Rhino: http://www.mozilla.org/rhino

- util/mp6.pl - compiler command line script written in MiniPerl6

- new repository at http://github.com/fglock/Perlito

- new web page at http://www.perlito.org/ created by nferraz (Nelson Ferraz)

Enjoy!
- Flávio S. Glock (fglock)

chromatic: Perl 6 Design Minutes for 09 December 2009

Thu, 21 Jan 2010 04:41:19 +0000

The Perl 6 design team met by phone on 09 December 2009. Larry, Allison, Patrick, Will, and chromatic attended.

Will:

some work on NQP port of Partcl
Patrick has been very helpful
sent a message to the Parrot list about the planning meeting this Sunday
initiated a community document to discuss those plans

Allison:

implemented large chunks of obscure C code to perform fast string matching using the FFT
wondering if that'd be useful in Parrot
maybe we do our indexing operations by character set in the NFG form
also does very basic pattern matching by leaving out optional characters
could be useable in the core tests, where it's tricky to depend on PGE
this was my final assignment before the Christmas break
have a month off to work on Parrot stuff then
I'll show off my assignment when I submit it

Patrick:

finished my final report for my Hague grant
haven't quite finished the grant, but left TODO items
rather than trying to finish everything and then write the report, I'd draft the report and keep notes on what I needed to finish
need to work on HLL interop
enable Perl 6 and other Parrot languages to load libraries from other HLLs
will work on that over the next few days
had several coversations about optimizations, constants, and inferior runloops
made minor PAST improvements
integer constants can automatically promote to num constants without going through a PMC
updated NQP to make it easier to write custom operator subs, if you're using the operator precedence parser
implemented the beginnings of smart matching
not full Perl 6 smart match
makes sense in the Parrot context
can match against regexes, tokens, rules, and any types with protoobjects
code looks more like Perl 6
not much on Rakudo besides answering questions
will get back to the Rakudo-ng merge after finishing my grant work
also worked on Partcl
updated its regex syntax, particularly for enumerated character classes
fixed it to handle unquoted, non-word characters in regexes
previously it only handled barewords as literal matches
it's closer to the Perl 5 syntax now

Larry:

didn't like the name PairValSet, renamed it EnumMap
likewise PairSet is now PairMap, and PairVal is just Enum
so individual constant pairs now called "enums"
we distinguish pairs, which have read-write values, from enums, which are constant in the value
you can now do .enums on hashes and arrays as well as enumerations
differs from .pairs, which give reference semantics into the values of the original data structure
.enums gives you a constant snapshot
David Green suggested renaming Enum.name to Enum.key, and he was right, since they're constant pairs
trying to be consistent about calling the whole type an "enumeration" and referring to the bits as "enums", even though the keyword is enum
thought people would rebel at typing the long name
clarified that the anonymous enum is compile-time evaluated as an anonymous list of constants
you can always cast to an EnumMap at run time for the other behavior
simplifying conditional semantics
STD parser now parses a WHENCE closure as part of the typename, rather than relying on subscript parse
block escape within a closure within a string used to parse as a normal block by responding to comments outside of the block
already fixed the embedded block in the regex syntax
made that usable by strings and regexes now
blocks in regular code try to figure out if they're at the end of a statement
look for the trailing curly
inside a string or regex, there are no statements
it makes no sense to look for the end of the statement there
the obsolescence messages were still in the old framework that upsets some Perl 5 people
changed the wording to "Unsupported use of ..."
#perl6 found a precedence inconsistency in parsing of list prefixes vs list infixes in NG
turned out to be wrong in STD first, and NG copied it
I fixed it in STD, Patrick fixed it in NG
otherwise last week was rather too ADD-ish, so mostly did Q&A on IRC

fixed some bugs
made some optimizations
think I've fixed most constant PMCs in PBC now, which should help NQP and Rakudo

Patrick:

it'll take a while before Jonathan and I can take advantage of that
Allison, when you push_eh an ExceptionHandler onto an array in a context, it creates an RPA
does that hold other things besides an EH?

Allison:

potentially
events get stored in the scheduler
only EHs are scoped to a context
the old pushmark/popmark stuff to do actions used that same global array
it may have changed to use the same array
that's deprecated though
they won't use that array for long

Patrick:

I need something to replace pushaction and popaction before they go away
when we handle LEAVE semantics, we want to avoid generating an exception to leave that scope for caching
I don't want to generate and rethrow actions to go up the stack
those ops let me do that without generating exceptions

Allison:

we do need singleton exception objects for FAIL and RETURN
no extra information needed
right now, you can insert anything you want in that array
the local_branch and local_return uses that array

Patrick:

it shouldn't
bsr and ret may have
I provide my own there

Allison:

oh right
I might not have checked in that code

Patrick:

by the way, NQP doesn't use local_branch or local_return

chromatic: Announce: Parrot 2.0.0 "Inevitable" Released!

Thu, 21 Jan 2010 04:37:49 +0000

The Beyond and below are like a deep of ocean, and we the creatures that swim in the abyss. We're so far down that the beings on the surface superior though they are can't effectively reach us. Oh, they fish, and they sometimes blight the upper levels with points we don't even understand. But the abyss remains a relatively safe place.

Vernor Vinge, A Fire Upon the Deep

On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0 "Inevitable." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 2.0.0 is available on Parrot's FTP site, or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on our source code repository to get the latest and best Parrot code.

Parrot 2.0.0 News:

Features
- Context PMCs now support attribute-based introspection
- Context and CallSignature PMCs merged into CallContext
- .lex directive throws exceptions when used with incorrect register types
Platforms
- Packaging improved for free OS distributions
- PPC, PPC64, and ARM now tested when running Linux
Performance
- Minor improvements to the profiling runcore
- Improvements from the CallContext PMC merge
New deprecations
- In/out parameters in STRING modification functions
- Void handling in NCI signatures
- Parameter passing opcodes order in PBC
Tests
- Continued migration of core tests from Perl 5 to PIR
Tools
- dependency checker improved
Miscellaneous
- Deprecation cycle length changed to three months from six
- GC accuracy improved
- PMC freeze improvements; much more reliable
- Makefile improvements for dependency handling

Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 16 February 2010.

Enjoy!

perl6.announce: Parrot 2.0.0 "Inevitable" Released! by chromatic

Wed, 20 Jan 2010 20:00:44 +0000

The Beyond and below are like a deep of ocean, and we the creatures
that swim in the abyss. We're so far down that the beings on the
surface -- superior though they are -- can't effectively reach us.
Oh, they fish, and they sometimes blight the upper levels with
points we don't even understand. But the abyss remains a relatively
safe place.

-- Vernor Vinge, A Fire Upon the Deep

On behalf of the Parrot team, I'm proud to announce Parrot 2.0.0
"Inevitable." Parrot (http://parrot.org/) is a virtual machine aimed
at running all dynamic languages.

Parrot 2.0.0 is available on Parrot's FTP site, or follow the download
instructions at http://parrot.org/download. For those who would like to
develop on Parrot, or help develop Parrot itself, we recommend using
Subversion
on the source code repository to get the latest and best Parrot code.

Parrot 2.0.0 News:
- Features
+ Context PMCs now support attribute-based introspection
+ Context and CallSignature PMCs merged into CallContext
+ .lex directive throws exceptions when used with incorrect register types
- Platforms
+ Packaging improved for free OS distributions
+ PPC, PPC64, and ARM now tested when running Linux
- Performance
+ Minor improvements to the profiling runcore
+ Improvements from the CallContext PMC merge
- New deprecations
+ In/out parameters in STRING modification functions
+ Void handling in NCI signatures
+ Parameter passing opcodes order in PBC
- Tests
+ Continued migration of core tests from Perl 5 to PIR
- Tools
+ dependency checker improved
- Miscellaneous
+ Deprecation cycle length changed to three months from six
+ GC accuracy improved
+ PMC freeze improvements; much more reliable
+ Makefile improvements for dependency handling

Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 16 February 2010.

Enjoy!

Carl Masak: The taming of the newbie - a comedy on IRC

Tue, 19 Jan 2010 09:26:20 +0000

The other day, I remembered this old piece of #perl6 backlog from 2005:

<masak> question: what are good ways in p5 and p6 respectively, to reverse a string? <masak> the easiest way i found in p5 was join '', reverse split // $string <masak> doesn't look very nice, now does it? <integral> *blink* <integral> $string = reverse $string

It feels odd to realize this five years later, but it seems that in 2005 I didn't have a firm grip on how reverse worked in Perl 5. Chances are, dearest reader, that you do. But if not, the rest of the refreshingly frank discussion will explain it.

Meanwhile, five years earlier, I persist in my innocent ignorance:

<masak> nope <masak> doesn't work :( <masak> reverse only reverses lists... i think

Reading this from the perspective of five years' work with Perl 5 and 6 is... enlightening, in a slightly cathartic way. Sure, it could have been that I'm the first to discover that reverse in Perl 5 doesn't in fact reverse strings, despite thousands of people using it daily for that purpose. But the chances of that are astronomically small. My peers on the channel tell me this.

<PerlJam> masak: clearly you are insane. <integral> perl -le '$string = "abc"; $string = reverse $string; print $string' <integral> masak: the manual *clearly* explains all the stuff about context <integral> and the faq

They do, you know.

<PerlJam> masak: in perl6 it would be $string.=reverse probably.

This was true in 2005, but nowadays we have flip for strings, reverse for lists, and invert for hashes. The need for different functions falls out naturally from the fact that Perl 6 doesn't depend as heavily on context as Perl 5 does.

Back in the log, I'm still trying to reintegrate into reality.

<masak> integral: your example worked, thx <masak> but nothing worked for me <masak> apparently i am insane :P

PerlJam and integral are one step ahead of me.

<integral> no, you don't understand scalar context. perl -le 'print scalar reverse shift' foobar <PerlJam> masak: you were probably saying "print reverse $string" <masak> no, but maybe something of the sort <masak> and that doesn't work, because...? <integral> masak: print's prototype is (@), ie list context. It's a rightwards named list operator <PerlJam> masak: context. * masak thinks he sees it now

These explanations are actually very good, but just in case, let me restate them in my own words: reverse has two main behaviours. Either it reverses a list of things, or it reverses a string of characters. It switches between these two behaviours based on something. You might think that this something is what type of thing you send in (a scalar or a list), but that isn't so. Instead, reverse responds to its surroundings and figure out what they expect. $string = reverse $string is a scalar assignment, and expects a scalar. print reverse $string, as integral explains, puts reverse in list context, so it reverses the list of one thing ($string), i.e. doing nothing.

Steve Yegge has this to say, in a vitriolic critique of Perl:

Perl also has "contexts", which means that you can't trust a single line of Perl code that you ever read.

I would say that it's actually not that bad, and the idea of context can be unintuitive at times, in many cases it's actually very natural and useful. reverse, in my humble opinion, is not one of those cases. I'm glad it's split up into different methods in Perl 6.

At the end, we learn that I had actually Read The Faithful Manual already, I just hadn't read it carefully:

<PerlJam> masak: perldoc -f reverse <masak> thx, integral and PerlJam <masak> PerlJam: I read the perldoc entry but apparently not carefully enough * masak reads it again <masak> ah <masak> "In scalar context, concatenates the elements of LIST and returns a string value with all characters in the opposite order." <masak> this somehow went past me as something i didn't want :/

In summary, I mostly wrote this blog post because I like to make myself squirm. 哈哈

But I guess there's also a moral to it all. We all start somewhere, and in a way it's reassuring to find five-year old proof of this fact. A newbie is just on a part of the learning curve you've already visited; they haven't had a chance to tweak their keyboard and developing environment to maximum efficiency yet, and they sometimes forget that the manual is there, or misread it in some way. So, don't hesitate to be be kind to them, and help them connect to the goodness that is perldoc, PerlMonks and Planet Iron Man so that they can grow and bloom into experienced wielders of Perl.

But don't hesitate to call them insane, either, when the situation calls for it.

Carl Masak: Ovid is right: roles are awesome

Sat, 16 Jan 2010 17:38:36 +0000

A class hierarchy of expression nodes: it's so much the prototypical use case for run-time method polymorphism that it's almost a cliché. One can close one's eyes and picture the way parts of the expression tree interact in rich, complex ways, shaped by the very types of the nodes themselves, in a dynamic dance of late bindings and virtual methods. Switch statmement, get thee behind me. Et cetera.

I'm building one. And I'm having almost too much fun doing it. In between trying to use the strengths of Perl 6 and keeping true to the original program I'm porting, I've discovered an important thing: Ovid is right about roles.

Specifically, I'm having trouble picturing how I would cram all the type information into my expression node class hierarchy, were I not using roles. The roles definitely help manage complexity in my case.

Here's a pretty diagram of my class hierarchy.

It's a flat beast. Apart from everything deriving from Exp, I have only one case of old-skool inheritance in the diagram. And even that one is more making a point than actually shortening the code.

Then there's all the colorful dots, representing the roles I'm mixing into my types. Some are for convenience (like the blue ones), others are vital for my program (like the green ones), and the rest are somewhere in between on the convenient/vital scale.

I even have a case of inheritance between two of the roles! Which means, in practice, that those classes with an orange dot also act as if they had a red dot. Very handy.

During the infancy of Rakudo, I've gotten used to learning to live without various features. Were I to do what I'm doing here without using roles, I could use two other mechanisms. The first is regular inheritance. The very thought gives me a bit of vertigo; I don't think I'd be able to turn the colored dots into base classes. Definitely not all of them at once; I'd have to choose. And that choice would affect the entire design of the program, probably resulting in loss of clarity.

The second way I could compensate for not having roles would be by using .can a lot. The presence of a given role in a class is isomorphic to the presence of a given method in a class. So that would definitely work, but I don't think I would like it as much. There's something to be said for declaring is and does relationships at the very top of the class declaration.

All in all, I'm very happy about the way things work. I'm wondering whether, had I not read all of Ovid's posts on managing the complexity of class hierarchies with roles, I would have come up with this design myself. Maybe, maybe not. But anyway: thanks, Ovid! This rocks!

A still-open question for me is whether the topmost type, Exp, should be a class or a role. Synopsis 12 has this to say about when to use roles:

Classes are primarily for instance management, not code reuse. Consider using C when you simply want to factor out common code.

I am using Exp for code reuse, and for giving all of the other classes in the hierarchy a common base type. So I guess I could indeed turn it into a role. But it's just that... I don't see a reason to do so, and I still feel instinctively reluctant about it. Maybe I'm a bit hung up about it being a class hierarchy.

This point has come up before on IRC, and I've yet to hear a satisfactory way to resolve it: when faced with making a base type a class or a role, which way should one go?