Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

masak
  (email not shown publicly)
http://masak.org/carl

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Thursday April 22, 2010
08:31 AM

I can haz constant?

Let's try this format. Mixing #perl6 IRC logs with more detailed explanations, sort of like a movie and a commentator track.

<masak> over lunch, since I'm so into scoping of different kinds right now, we got to talking about class-bound variables again. my colleague jonalv, whose home language is Java, thought that it was a shocking omission not to have class-based variables.
<masak> I explained how 'my' and 'our' didn't do what was intended, since lexpads and packages are orthogonal to OO inheritance.

"Orthogonal" is quickly becoming one of my favourite terms in language design. It doesn't mean "at an angle of ninety degrees", but rather "along independent dimensional axes", that is, "not having anything to do with one another".

The two things that are orthogonal here are ordinary variable scoping on the one hand, and (method) inheritance on the other. In particular, a deriving class typically isn't lexically nested inside its base class, nor is it a subpackage of it, not even in the case of A::B deriving from A. (Unless they're nested in code, but in the general case they aren't.)

<masak> when I talked about 'state' variables, he was a bit mollified and admitted that the need wasn't as great for class-bound variables.
<masak> and when I explained about the non-need for class-level methods due to type objects, I had almost convinced myself that we don't need class/static variables :)
<masak> but one use case that I can see is something akin to a constant defined in a class, which ought to be reachable from all its methods and the methods in derived classes.

When I learned about static fields in Java, even the examples were contrived. They looked much like this:

class Car { // this is Java code
    static long cars_produced = 0;

    public Car() {
        ++cars_produced;
    }
}

Here's where Perl 6's state initializer feels a little bit like Java's static scope declarator.

class Car { # this is Perl 6 code
    submethod BUILD() {
        state $cars-produced = 0;
        ++$cars-produced;
    }
}

In both pieces of code above, the variable counting all the cars ever produced since the beginning of the program will begin at 0 and increase by one every time we construct a new car.

However, the visibility is different. In Perl 6, the variable is only visible inside the BUILD submethod. If we want all methods to see it, we'll have to move it out to the larger class scope. (And then we don't need state, because the class block is only run once. We can use my to tie it to the lexical class block, or our to tie it to the class package. In the latter case, it can be referred to from the outside as Car::cars-produced.)

But that still doesn't give us the inheritance that we like to associate with classes. The Java code would keep ticking up cars even if we derived a RollsRoyce class from Car, as long as we called super() from within the RollsRoyce constructor. The Perl 6 code will behave the same (and automatically) since we put our initialization in the Car.BUILD submethod, which would get called by RollsRoyce.BUILDALL. But in Perl 6, we can only see the variable when inside Car, not when inside RollsRoyce. Java doesn't have this issue.

Excuse the crappy non-real-life example. 哈哈 But two more realistic use cases bring us back to the IRC discussion in question.

The first is one or more constants that a class might want to share with its deriving classes. That feels pretty natural. The second is enums, which are basically constants packaged in a convenient form.

I like throwing out items for discussion like this on #perl6. You never know who will pick them up, but I usually learn something from them, and sometimes the spec even gets improved as a result. This time, TimToady replied:

<TimToady> std: has constant $.pi = 3;
<p6eval> std 30419: OUTPUT«ok 00:01 110m␤»
<jnthn> o.O
<TimToady> masak++ was conjecturing class-based constants, but it already falls out
<TimToady> in fact, that was one of the reasons the constant declarator moved from being a scope_declarator to being a type-declarator, so we could use it in arbitrary scopes

Well, that does take care of the constants use case. Nice! You use has and twigils to get you the inheritance behaviour. Why didn't I think of that?

Here's why I think it's extra nice: rather than make this an issue of scoping and visibility, the has constant construct makes it an issue of immutability. Given this information, the compiler is free to optimize as much as it can, but (unlike Java) we never had any need to invent a "class level" scope, where static things are stored. That aligns with the rest of Perl 6; we don't have 'static methods' either, for example — but you can achieve much the same things through other means.

<masak> TimToady: 'has constant' still makes me happy. what's my best solution if I want to do something similar with an enum? (i.e. share it between a class and all its descendants.) enum is also a type declarator, but the name doesn't have a twigil...
[...]
<TimToady> masak: testing a patch for 'has enum $.meth <foo bar>'
<masak> TimToady: \o/

I love it when existing parts of the design just melt together into something even more useful than the sum of its constituent parts. The fact that I can be part of that process makes the work on Perl 6 feel much less like work and much more like an adventure.

So now, I can haz constant! And enums! I expect they will come in handy, especially since I will be on the lookout for possible uses for them.

As for class-based variables, Perl 6 still doesn't have them. I don't see a similarly good way to add them to the language. On the other hand, I also don't have a better use case for them than that crappy Car example.

Wednesday April 14, 2010
09:04 AM

Levels

  • First, you find the tool and find that it does a lot of good for you. The tool might be perl, an executable, or Perl, a language family. You engage in a positive cycle where learning more provides you with a more means to solve new problems efficiently.
  • Then, you find the repository. In the case of Perl, that's CPAN. It's full of code that solves problems, including problems you've been trying to solve lately. It's like finding a cave full of treasures. The tool becomes immeasurably richer because of the repository.
  • Then, you find the patterns. Those are recurring code idioms within your solutions, and within the solutions in the repository. Usually they encode common sense, and represent which configurations survived in the human-assisted natural selection occurring when solutions grow and change. You discover that the range of solutions you're able to solve satisfactorily increases as you master the various patterns.
  • Finally, you find the community. After all this time enjoying the tool, the repository, and the patterns, you connect with the group of people behind some of these. The group of people forms an intangible but very real resource in itself; people share knowledge freely in the ad-hoc network that forms and reshapes itself.

The above list is of course idealized, and the events must not occur that clearly or in that order. The world is messy, and it's possible to 'level up' according to a very personalized path, and with vastly different speeds.

An interesting effect is that whereas it's more straightforward for beginners to access the levels in the order stated above, the reverse holds for contributing to the different levels. You're more likely to push something to CPAN than to patch the perl compiler, and contributing to the community is something you do just by submerging yourself in it.

Because the first three levels are completely dead and consist only of ones and zeros, it's easy to forget that one is dealing with humans at all. One might stumble into the community layer with a dead-things mindset, and say things that wouldn't be acceptable if they didn't take place on the Internet, where expectations are that everyone might be a jerk.

Far too often, I see tweets on this form:

People who [engage in practice X] should be {hanged, drawn and quartered | shot on sight | [etc]}

That kind of rage is only possible when we forget both that practice X (for most values of X) is only configurations of ones and zeros, and that the people who engage in it are indivuduals just like us. Yes, it's hyperbole, and we don't mean actual shooting on sight — but the mere fact that we're casually formulating this thought is worrying. Or should be.

Zen Buddhism talks about the perceptible world being an illusion. As programmers, we know that we're dealing with castles built of virtual nothingness, and still we are prepared to lose our temper over exactly how they're built. We get stuck sometimes in the illusion projected by our machines.

The community level is where the least amount of code gets written. From the perspective of programmer-minded problem solving, it's the most abstract and ephemeral level. From the point of view of people, places, and things, it's the only level that actually exists. If all the other levels went away but the community remained, we could still do great things. If all the other levels remained but the community went away, there'd be no-one left to notice.

Friday April 09, 2010
02:49 AM

It's about time

jnthn++ touched upon the subject. I thought I'd do the same. We're rewriting the Temporal spec from scratch. It's not the first time this happens, but for some reasons, this attempt feels better than the previous ones.

Ever since the Web.pm work had its course plotted in more detail — not to mention since the work on GGE — I feel I belong to the "shameless copycat" school of design. More specifically, in many domains not directly related to the Perl 6 core model, our best chance of success is likely not to be oh-so-clever, but to start with something that works well in some other language (big-sister Perl 5, Ruby, Haskell, JavaScript, what-have-you), adapt it to Perl 6 idioms, and ship it. In the case of Temporal, the clear winner was CPAN's DateTime, a subset of which is now in Synopsis 32.

Imitation may be the sincerest form of flattery, but basing your design on something that already works also seems a fairly safe way to make sure that the design you end up with isn't and abstraction-laden heap of wishful thinking.

Thursday April 01, 2010
04:53 PM

Yapsi 2010.04 Released!

It is with a certain degree of amusement that I want to announce, on behalf of the Yapsi development team, the April 2010 release of Yapsi, a Perl 6 compiler written in Perl 6.

You can get it here.

How does one compile and run a Perl 6 compiler, you might ask? One way would be to use it on itself, but this has been known to cause some immediate dependency/bootstrapping issues. It's often a great deal easier to use an existing compiler to get off the ground. Yapsi runs fine under the 'alpha' branch of Rakudo.

This is an "official" release of Perl 6, to the extent that we, the Yapsi development team, have authority to make official Perl 6 releases, which admittedly isn't a very large extent. It's also a "complete" implementation, in frankly not very many ways at all.

Here's an example of what Yapsi can do:

$ ./yapsi -e ''

...that's right, it runs the null program. And with correct semantics, and all.

But that's not everything. We also do assignments:

$ ./yapsi -e 'my $a = 42'

Note that here, too, the semantics are completely on the spot. 42 gets assigned to $a, and nothing is output.

For those of you who cry foul at this point, just watch:

$ ./yapsi -e 'my $a = my $b = my $c = 5; say $a'
5

Ta-daa!

Yapsi consists of a compiler and a runtime. The program is compiled down into a kind of instruction code called SIC [sic]. This code can then be executed very quickly inside the provided runtime, where the definition of "very quickly" depends on the runtime you're bootstrapping off, etc.

An overarching goal for making a Perl 6 compiler-and-runtime is to use it as a server for various other projects, which will hook in at different steps:

  • A time-traveling debugger (tardis), which will hook into the runtime.
  • A coverage tool (lid), which will also hook into the runtime.
  • A syntax checker (sigmund), which will use output from the parser.

Another overarching goal is to optimize for fun while learning about parsers, compilers, and runtimes. We wish you the appropriate amount of fun!

Monday March 29, 2010
11:37 AM

Step 1 on the road to recovery: admitting you have a problem

In order to be better, we had to refactor Rakudo. It wasn't a question of 'if', it wasn't a question of 'when'. If we were to meet the goals of Rakudo Star in 2010Q2, we'd have to pull Rakudo apart and put it back together. It would lead to a lot of downstream breakage, but better now than later.

We're currently at the 'downstream breakage' part. Until now, I haven't really taken a look at the scope of the breakage. Today, I will. I suspect I'll spend much of April doing damage control.

In other words, the "admitting you have a problem" from the blog post topic refers to the fact that until now, I've been an alpha guy. "alpha" is the code name for "the old Rakudo master branch". You know, the one on which my code works. But being an alpha guy will feel more and more quaint, and I hope I don't have to be an alpha guy up until the point Rakudo Star is released. That would feel terribly inconsistent.

So. Let's try to run my favourite apps on Rakudo master.

November

Trying to compile November, I get the error message "Unable to parse blockoid, couldn't find final '}' at line 8" on the first file I attempt to compile. After some digging, it turns out that the error isn't actually located in that file, but in a file used by a file used by that file. The error message is due to this regex definition.

token port       { (\d**1..5)
                    <?{{ $I0 = match[0]
                         $I1 = 0
                         if $I0 > 65535 goto fail
                         $I1 = 1
                       fail:
                         .return ($I1)
                    }}>
                   <!before \d> };

The trained rakudologist immediately picks out the PIR code assertion (highlighted in bold), a construct no longer supported in Rakudo after the refactor. But real, non-PIR code assertions are supported, so the above should simply be swapped out for <?{ $0 < 2 ** 16 }>.

I swap it out and move on.

Next fun error message: "You can not add a Method to a module; use a class, role or grammar". This occurs in a file where I'm decidedly in a class, and not a module. Rakudo is wrong; I am right.

So what is going on to make me get that error message? This:

$ cat A.pm
grammar A {
}

$ cat B.pm
class B;

method foo() {
    use A;
}

$ perl6 B.pm
You can not add a Method to a module; use a class, role or grammar
[...]

My guess is that the parser gets confused about the kind of scope it's in when switching between files. I submit this as a rakudobug and move on.

Druid

Stuck at the Configure step. The error message is familiar: "You can not add a regex to a module; use a class, role or grammar". That's just pure bigotry. And it's been discussed before, but not resolved yet.

Luckily, the regex can be easily inlined in this case, so I do that and move on to the next message:

$ perl6 Configure

Configure.pm is preparing to make your Makefile.

Method 'postcircumfix:<{ }>' not found for invocant of class 'Failure'
[...]

Please bask in the sheer informativeness of it all while I try to find the cause.

Ah. The reason for the error message is that alpha has a %*VM<config><build_dir>, but master currently doesn't even have a %*VM. I could hack around that, but I'll submit a rakudobug instead.

proto

$ ./proto
Can't locate File/HomeDir.pm in @INC [...]

In all the chaotic mess that is Rakudo error messages, it feels comforting and a bit relieving to get a Perl 5 error. And one as mundane as this, to boot.

Hm, I heard mberends++ mention that he was doing biggish changes in proto. Seems this is one of the results. I must have a look at them later they seem interesting but right now I'm looking for Perl 6 errors. So, moving on.

Web.pm

Same regex-in-module bigotry as with Druid. And after that, same %*VM trouble. Not too surprising in retrospect; they use the same Configure.pm module.

GGE

GGE also uses that Configure.pm module, so I just skip the configure step and manually replace alpha with perl6 in the Makefile. This is the error I get:

$ make
env PERL6LIB='/Users/masak/gwork/gge/lib:/Users/masak/gwork/gge/lib:/Users/masak/wor k/hobbies/parrot/languages/rakudo' perl6 --target=pir --output=lib/GGE/Match.pir lib/GGE/Match.pm
Placeholder variables cannot be used in a method at line 39, near "multi meth"
[...]

The method in question contains zero (0) placeholder variables. So what's going on here?

As usual, the answer turns out to be "something completely different". It's in the method above, which also doesn't contain any placeholder variables, that the error originates:

$ perl6 -e 'class A { multi method new(*%_) { |%_ } }'
Placeholder variables cannot be used in a method at line 1, near "}"
[...]

And that's just wrong, so I submit a rakudobug and call it a day.

Conclusion

A good first harvest.

It's difficult to judge whether I've found 10% of the total breakage, or 1%. But regardless, this needs to be done, and sooner rather than later. I think the allure of easy-to-reap rakudobugs will urge me on in this quest.

I still haven't given up the thought of doing nightly builds of all the projects. That would amount to automatic (or at least greatly simplified) bug finding and collection.

Looking forward to the first automatically found rakudobug. 哈哈

Sunday March 21, 2010
05:52 PM

Pushups, repetition, and newbies

A while ago, I found a website called one hundred pushups, with the help of which you're supposed to be able to build enough arm muscle strength to be able to perform 100 pushups in a row.

The way the site goes about helping you reach this goal made me think about Perl 6, because... well, because everything does. 哈哈 But really, there's something to take away from the method employed by this site.

I'm on week 4 now. If you'll have a look at that page, you'll see it's basically just three tables with numbers, one table for each of the three days of exercise in the week. Week 3 is also just three tables. Week 2 and week 1 are also just three tables each. All the weeks are just a set of three tables. The whole website is just built around eighteen tables of suitably increasing numbers. I don't even read the rest of the text on the pages anymore, I just look at the numbers.

If there is any such thing as a "secret" to exercise, it's repetition of tasks within one's limits. I can't do 120 pushups, but if I'm allowed minute-long breaks, I can do 24 pushups five times. (I'll still be exhausted, but compare that to trying to do them all at once — I wouldn't be able to finish.) It's pretty clear to me that, primitive as those tables may be, they do have the desired effect.

The connection to Perl 6 programming? Well, I can't write a grammar engine implementing the whole of Perl 6 regex behaviour. That's crazy talk; I have no prior experience whatsoever. But give me half a year of tinkering, about five or six refactorings and 250 commits, and things at least slide within the range of the possible.

viklund++ and I couldn't just sit down and write a wiki engine in Rakudo in 2008, because no-one'd written anything in Rakudo in 2008... but give us a quiet summer and fifteen weeks of recurring meetups of sitting down and toying around, each week solving a little problem of some sort... eventually we ended up with something that you could log in edit pages with.

Perhaps even more similarly, I guess it would take me a full week or so to submit 700 Rakudo bugs, if I spent eight hours a day on it, giving each bug five minutes. Of course, bugs are not discovered with a frequency that'd make that possible, but even if they were, I'd probably hate the whole job halfway through Monday. As it is now, it's quite fun to be the masakbot. Bleep bloop.

And that's the thing. When you do things frequently but always within the range of your abilities, it doesn't feel like productive work, it doesn't feel like learning, and it doesn't feel like progress. But it is. I've learned more as a programmer in these past two years than in any other two years of my life, just because I come back and do little things I already know how to do, in new and slightly different ways. And I do that a hundred times a month. It adds up.

We've been getting some new nicks on the #perl6 channel lately, and a common question is: "I want to learn/help/contribute. Where do I start?". The real answer to that is "Well, if you have to ask...", but we're friendly so we don't say that. We often end up saying a variant of the following:

Stick around, look for something that catches your fancy (app writing, blogging, writing tutorials/docs, compiler development, sharpening the spec, submitting bug reports, tending the test suite, hugging trolls) and then just do that, for as much and as long as you want. Most importantly, have fun!

Though not meant that way, it may come off as a bit dismissive, as if we didn't care what the newcomer does, or didn't care where resources are being invested; but the real reason we answer like that is that we hope that our new gal or guy will find a sweet spot where they can just come back and do things again and again with small variations and it just stays fun and inspirational, like a child's game or a relaxing hobby.

Because that's how a lot of us are passing the time on #perl6. In a constant state of play; because that's how we and Perl 6 grow the fastest.

Monday March 15, 2010
05:47 PM

Plain old assignment, and freaky binding

What happens when we do assignment? When we do $a = 42;, for example.

Intuitively, in almost every language, what happens is at least something like this: the symbol $a becomes associated with the value 42. In pseudo instruction code, it might look something like this:

my $a; $a = 42;
    $0 = 42
    store '$a', $0

(Feel free to read $0 et al. as "some register in the VM". And to fantasize liberally about the opcodes.)

From this model, we expect variables to be independent, even when we've assigned from one to the other. So in this piece of code...

my $a = 42; my $b = $a; $a = 5;
    $0 = 42
    store '$a', $0
    $1 = fetch '$a'
    store '$b', $1
    $2 = 5
    store '$a', $2

...we expect $b to still be associated with the value 42, and not to have suffered some freaky action-at-a-distance which causes it to be changed when $a is assigned to 5.

"Well, obviously $b won't do that", you interject. "It can't, if we believe in the model in which there are only symbols and their associated values. No freaky action-at-a-distance can occur." And that's right, as far as that goes.

But it turns out that Perl 6 allows a middle abstraction layer between symbols and values. The entities occupying this middle layer are usually referred to as "containers", but that's a terribly overloaded term. I'll call them "buckets" in this post, hoping I won't throw some hash expert into a fit. 哈哈

To explain the behavior of (and need for) buckets, let's take an almost identical example as the one above:

my $a = 42; my $b := $a; $a = 5;
    $0 = 42
    store '$a', $0
    bind '$b', '$a'
    $1 = 5
    store '$a', $1

(Note the two surface differences from the earlier example: := rather than =, and bind rather than assign.)

The state at the end of this new program is a case of freaky action-at-a-distance. When the value of $a is changed to 5 in the last statement, the value of $b will also be changed to 5.

The reason for this is simple: the := (and the bind) causes the symbol $b not to have a bucket all of its own, but to acquire $a's bucket. When 5 is subsequently stored in that bucket, both $a and $b are simultaneously affected, since the two symbols share one and the same bucket.

Now as a language feature, freaky action-at-a-distance may at first seem to be situated somewhere on a spectrum between "useless" and "dangerous". But it is the feature that makes pass-by-reference parameter passing work:

my $a = 42;
foo($a); # freaky!
say $a;  # 5

sub foo($b is rw) {
    $b = 5;
}

Note how that's practically the same example as the above with binding, except that it's now mediated through a layer of parameter passing. But $a and $b still share one single bucket, as before.

I only have two more things to say about this. First, jnthn++ explained in Copenhagen that the difference between scalar bucket and an array/hash bucket is that the former always forwards method calls to the value it contains. I don't grok that yet, so I may have got it wrong.

Second, there's still a way to circumvent buckets, assigning values directly to symbols:

my $a := 42;
    $0 = 42
    bind '$a', $0

What this means is simply that the variable $a is bound directly to a value, and has no buckets to which one can assign new values. It's a bit like a read-only value, except that $a can still be rebound to something else.

These are the kinds of thoughts one gets when starting to write a time-travelling debugger.

Monday March 08, 2010
05:01 PM

The ghost of Algol 68

Ever wonder why bash closes if blocks with fi? This practice was inctroduced in Algol 68, a language that Perl 6 was accused of reinventing yesterday on the perl6-language list.

Curious, I went to the Wikipedia article to read up on Algol 68.

ALGOL 68 (short for ALGOrithmic Language 1968) is an imperative computer programming language that was conceived as a successor to the ALGOL 60 programming language, designed with the goal of a much wider scope of application and more rigorously defined syntax and semantics.

"Successor." "Wider scope of application". "More rigorously defined syntax and semantics". Sound familiar?

ALGOL 68 has been criticized [...] for abandoning the simplicity of ALGOL 60 becoming a vehicle for complex or overly general ideas, and doing little to make the compiler writer's task easy [...]

Oh dear. ☺ We even have the 'do little to make the compiler writer's task easy' meme in Perl 6...

<TimToady> after all, Perl Philosphy is simply to torment the implementors on behalf of the user (#perl6, 2008-10-09)
<pmichaud> aha! I have a quote for my keynote.

Besides that, there's all these other little parallels, such as

  • Algol 68 seemingly playing with words (they borrowed the term 'gomma' from Finnegan's Wake, but the feature it denoted got scrapped in a 1973 revision),
  • something junction-like called 'multiple value',
  • a whole heap of values for different forms of nothing and undefinedness,
  • a newly-invented grammar formalism, and
  • a general feeling of deep ambitiousness and a desire to get things right.

So, there are deep similarities between Algol 68 and Perl 6. There's not much to say to that, except perhaps "huh".

If there's anything in it all that's uplifting though, it's the second paragraph of the article:

Contributions of ALGOL 68 to the field of computer science are deep and wide ranging, although some of them were not publicly identified until they were passed, in one form or another, to one of many subsequently developed programming languages.

If that's not spot on for Perl 6, I think it will be in a decade or so.

Tuesday March 02, 2010
06:15 AM

I'm a snowplow

Oops. I think excessive distractedness just made me miss a 10-day interval, thereby falling off the Iron Man challenge. Oh well. [Sidenote: Is there a way to easily check one's Ironman status?]

Lately, I've been feeling a bit like the snowplows shuffling snow around outside my office window. I have a lot of things I want to blog about, but I've been pushing them ahead of me. That's exactly what the Iron Man thing is supposed to counter. Guess procrastination won out in this case.

So, how much blog would a masak write if a masak could write blog? Here's a list off the top of my head of the things I've been thinking of blogging about:

  • The presentation I'm writing for the Open Source Days in Copenhagen this weekend. I'm really excited about it.
  • The "7 Wonders of the Ancient Grammar Engine" series. I've started on it, and I like what I have so far.
  • More E03 stuff. Guess that's what I didn't blog about in the past 11 days.
  • snarkyboojum++ and I have started toying with writing a time-travelling debugger. Yes, really.
  • A lot of things are happening in Rakudo-land this month, after the successful ng merge. colomon++ especially shines like a bright star right now, bringing lots of tests back online each day.
  • I'd like to get enums in Rakudo before this month's release. I've already done anon enums. Next up: named enums.
  • I've been starting to think seriously about u4x lately. Partly because of other people's questions, partly because it seems the the time is ripe to start it.
  • However, every time I have that thought I realize that the book is more important at the moment. I have some unimplemented ideas there as well.
  • GGE is very near being PGE-compliant. Just a few finishing touches are needed. This will likely usher in a new era in Perl 6 grammars and parsing.

Will I have time in the near future to expand these one-liners into full-fledged blog posts? Only time will tell.

Friday February 19, 2010
06:30 PM

E03, the modern, pragmatic, honest version, with corners cut

I was a bit optimistic with time. So what else is new.

Anyway, various distractions such as $WORK kept interrupting my translation of E03 today, but now I've finally got it all ported to modern Rakudo-Perl 6. Here it is. Two biggish things remain:

  1. I haven't tried running the code. I'm pretty sure it won't run on the new Rakudo master yet. But I've written it with alpha (the old development branch) in mind, and it should run there.
  2. I haven't looked at SF's E03 translation yet. (Yes, I'm linking to a blog entry which I haven't read yet.) I saw that the title of his post is "first stab", which makes me feel a little better.

Here are a few random comments about the code.

  • The original code in E03 is the strangest example code I've ever read. All due props to Damian, but... quod? A program whose task it is to "locate a particular data file in one or more directories, read the first four lines of each such file, report and update their information, and write them back to disk"? Come again? (My suspicion is that this was the program arrived at by simply cramming in as much of A03 as possible into the same piece of code, but nevermind.)
  • A few nice things are still missing from Rakudo. The s{}{} syntax is the last still unimplemented request in an old blog post of mine. It'd be pretty nice to have. I think we'll have it soon, thanks to ng.
  • You can't open files rw in Rakudo. Then again, you can't seek or truncate them either, so I guess opening them rw wouldn't make much sense anyway. Due to this, I had to work around a central part in the program, where filehandles were stored in a hashtable, to be read from in one subroutine and written to in the next one. Had to store the filenames instead, and re-open the files for writing.
  • We don't have the :r and :w filetests yet, but :e and (strangely enough) :s are implemented. Someone with tuits should really do :r and :w.
  • A fair amount of the updates in E03 are out-of-date. I guess operators and related things are an area where Perl 6 really has evolved a lot in the past few years, or even in the past year. As I speak, the exact semantics for infix<...> is still being discussed on #perl6.
  • When I say things have changed around a lot, I should really mention that I say that with a sort of relief of the sort that means "gee, I'm glad we didn't stick to what we thought we wanted back then!". Things have, by and large, improved greatly. I actually hope to write more about that.

This exigesis-modernising is kinda fun! Now I'm eager to go read what SF++ has been up to.