Tag Archives: perl6

Hypotheticals in Perl 5

In Appendix C of Apocalypse 12, Larry speculatively mentioned the syntax:

    let foo();

Which would “try” foo, and then revert things back to the way they were before that if something failed in your block. Well, I’ve implemented a Perl 5 module, Data::COW (which hasn’t been indexed at my time of writing, but will be at your time of reading), which could, er, hypothetically let you do that. Interestingly, I implemented it so you could do that on a smaller scale for the logic programming module I’m writing.

First, assume that all external state in your program is accessed through %$state, and everything other than that is purely functional. This seems like a big assumption, and it kind of is, and it kind of isn’t. If you don’t change the state of any modules (a fairly easy thing to do, depending on what modules you’re using), it would be fairly trivial, though maybe not easy easy, to massage all your own state into a single global hash. (Note that all stateful things need not be in the hash: the hash is just your “root set”, corresponding quite closely to all of your globals and file-scoped lexicals.)

Then I can easily write temp foo():

    my $old = $state;
    $state = make_cow_ref $state;
    # remaining code in the block
    $state = $old;

foo() is allowed to change whatever it likes, and it will be restored (of course, only those things that can be copied can be restored) after the block ends. let() is approximately the same:

    my $old = $state;
    $state = make_cow_ref $state;
    eval {
        # remaining code in block
        1 } or $state = $old;

It’d be sweet if Perl 6 could allow that kind of thing to operate on the global state instead of a single hash. Sweet indeed, but I don’t know how practically useful.

Awesome Efficient MMD

I’m currently implementing Class::Abstract, which will become my Perl 6 multimethod proposal. I pounded my head against a wall for a couple hours, and I came up with a really awesome multimethod dispatch algorithm. It isn’t Manhattan distance, of course, because I hate Manhattan distance. Actually, it’s more general: it’s an algorithm for quickly finding all possible candidates, without using any algorithm to disambiguate which ones. It is Θ(a m t) (where a is arity, m is number of methods, and t is number of types) in space, which beats the hell out of Parrot’s current Θ(t a), especially since t is usually much larger than the other parameters. It’s also fast-O(a+m) in time, where fast-O is technically O(a+m), but the bounding constant is quite small relative to most asymptotic measures. That is, it can be implemented in a really tight, CPU register-only loop, on top of the fact that a and m are generally small.

Continue reading

Threaded Values

In my constant struggle to find the Grand Unified Multimultimethod Paradigm (GUMP?), I started to think about how Perl 6′s Junctions interact. Junctions really aren’t multimethod candidates at all. They’re a special type of “meta-value” which implicitly take over all operations on them. And that type of value turns out to be a lot more useful than just to implement Junctions. And so I think we should generalize it, to make a generic autoöverload hook.

As an interesting example, we could implement the generalized Einstein notation (as Synopsis 9 proposed, and everybody liked the idea, but nobody liked the solution). The index could be an autoöverloading value that computes its necessary range and then evaluates at all the values it needs to.

The actual rules of Einstein notation are pretty yucky when you’re dealing in a practical context (it has to do with summing over things that appear exactly twice). But it’s easy to generalize, even away from sums. Then you could do the matrix multiplication yj = Aijxi like so:

    use Notation::Einstein;
    ein -> $j { @y[$j] = esum { @A[$j;$^i] * @x[$^i] } }

Which is probably as good as it’s going to get without introducing special case rules.

Now let’s think about how the autoöverload method works. It’s powerful enough to support Junctions, which ought to be as much power as we’re ever going to need out of it. Bascially, anything you do with it at runtime can be intercepted. Pass it to a function, add something to it, flirt with it, whatever, it knows.

For efficiency, I’d suggest that these guys deserve a declaration or a secondary sigil so the compiler can see them. Junctions would have it too (I’ve gradually been convincing myself that this would be a good idea on a language level as well). It’s like a fancy tie, so I’ll call it $~thing.

Here’s where the multimethods come in. It’s not multi infix:+ (Junction $~j, $x) as you might expect, but rather multi OVERLOAD (Junction $~j: Operator &o: *@_) (or something like it). Using subtype-based dispatch, you can be as specific as you like with the operator (any operator, any infix operator, the plus operator, any sub call, etc.). Operator is a very generic, interesting type, and I’ll leave the discussions of that to the insane ramblings inside my own head… which occasionally make it to this page.

So this multimethod allows you to specify exactly what you want to intercept—how local you want your object to be. If you try to alias your object non-tiddily object, you either get an error or you run the risk of your semantics not propagating (I can’t decide). In any case you could always overload :=. Anyway, here’s the OVERLOAD method for a conjunction.

    multi OVERLOAD (Conjunction $~j: Operator &o: *@_) {
            map { &o($_, *@_) } $~j.real.states  # .real keeps the junction from intercepting the call
    multi OVERLOAD (Conjunction $~j: Operator::Boolify: *@_) {
        grep { ?$_ } $~j.real.states

Et similia

I just watched Castle in The Sky, only the second Mayazaki film I’ve seen. The storyline was very Final Fantasyesque, and the music was top notch (to be expected from Hisaishi). The movie itself would have been excellent, once you get past of the blantancies of anime, if it weren’t for the all-around happy ending. The climax was bittersweet, and I don’t know why he had to turn it around and make it Hollywood happy. But it’s a great movie nonetheless, if you’re in to anime epics.

My Glop talk isn’t coming along as quickly as I’d like it to. I have the main points outlined, but none of the details are there yet, and I ought to really get cranking if I want a chance to practice before I speak. Glop itself is pretty neat so far, though. I feel like I’m back in the days of QBasic’s “what if I…” graphical programming, except it’s a lot faster.

Oh, and I’m now officially on the Perl 6 design team. I’m proud, though I’m not sure this changes anything. I didn’t get selected as pumpking, but that’s okay—more time for school (I was worried about that).

Famous Perler

So Allison Randall (On the Perl 6 design team) just, she just, well, let me put the body of the message right here:

    From: Allison Randal
    Subject: Retroactive Synopses


    Would you be interested in working on Synopses 2-4? The task would be to
    summarize the Apocalypses with updated content. You might be
    co-authoring with Damian or the sole author, it depends how much time
    everyone has.


Umm, let me think about it. Done. Yes!

This will get me a fair share of publicity outside of the perl6-language community. Wow! I’m so excited!

Perl 6 unfolds

So now I don’t have a relationship. But thanks to Victoria, I realized I like blogging. So I presume this is going to turn in to much more a technical blog. Which means I can start attracting my buds from the Perl community who aren’t terribly interested in my personal life.

The more I think about Perl 6′s philosophy, the more I realize how much of a damn genious Larry is. I was reading Kim’s blog about LL3 and thinking maybe the future of programming languages isn’t one (or a few) good general purpose language, but instead many domain-specific languages suited to the task at hand. That’s kind of the way things are going. But there still needs to be a language (currently C) in which those little languages are coded.

Then I thought about Perl 6. I was worried at the beginning because Larry was making the syntax so mutable that the language would become unmaintainable1. Nobody could understand what was going on in anybody else’s code. But now I realize that he’s integrating domain-specific understanding into the very syntax of Perl. Thus, Perl is much like English (or any other natural language): there’s a standard syntax and grammar by which we adhere, but then domain-speak becomes more specialized: new vocabulary is introduced, idioms are created, shorthand is made (for instance, TLA’s).

It comes from the idea, I think, that there will be more and more programmers as computers become more and more pervasive. And the fact that a physicist shouldn’t be maintaining a linguist’s code.

I’m really happy to be a part of this project. It’ll go places.

1 I maintain that Perl is not unmaintainable, just that a vast majority of Perl programmers write unmaintainable code. As Larry says, Perl gives you enough rope to hang yourself with, and a lot of people do.