Exegesis 6 (Perl 6 Subroutines) Released

chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."

Comments

For those who don't know....

[ajs]

The way Perl 6 is being developed is thus:

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

Hope that helps clear this up for those who aren't sure what's going on when they see a new Apocolypse or Exegesis come forth.

Re:Keywords

[ajs]

Perl has keywords picked up from C (for, if, while, int, printf, etc.); BASIC (substr); Modula (module); CPP (defined); and many other sources. It's very much a post-modern language in the sense that it seeks to deconstruct all other languages and re-build itself in their images without actually being just a collage of their parts.

HOWEVER, that being said Perl has a huge advantage over the keyword restrictions of most languages. I'll show you a sample of some code, and you tell me if you can see what the advantage is:

$time = time();
$localtime = localtime();
print "UNIX timestamp $time is $localtime\n";

The same goes (to a slightly lesser extent, since you don't *have* to use the prefix-sigle &) for subroutines and all of the other miscelaneous Perl data types that can be named (obviously those that cannot be named like stashes never conflict with a keyword).

Holy syntax overload batman!

[jtdubs]

I've never seen a language with so much syntax. Perl 5 had more than enough, now they've more than doubled it.

You have { } for blocks, and for automatically parameterized blocks (ie. anonymous functions).

You have =, := and ::=, ~=, ~~, .... = does assignment, := does binding and ::= works at compile time and is normally used to define types and such, ~= is pattern matching, and I have no idea what ~~ does.

You have the new <== and ==> pipeline operators. They are dataflow operators. Like so:

$foo ==> my_func ==> $bar;
is the same as
$bar <== my_func <== $foo
is the same as
$bar = my_func($foo);
is the same as ...

You already had the $,@,%,& to prefix variables with.

You have more uses for * now, as in slurpy arrays and splicing. As in, the * can make an array parameter slurp up all the remaining arguments, or it can make an argument flatten into a list of arguments.

They've added some wierd << foo >> syntax that I didn't even bother to read about as I was in syntax shock.

They've added ^ which indicates that a variable in a block is actually a parameter and therefore the blocks is actually a parameterized blocks (ie. anonymous function). So, now you can't tell if something surrounded by { }'s is just a block of code or whether it's an anonymous function. Although, I don't think this is a problem as it's usually obvious from the context.

And I didn't even read to the end of the paper!

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

Justin Dubs

Re:Holy syntax overload batman!

[ajs]

Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions)

That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can). However, most Lisp code really doesn't benefit from this fact as much as it does from its side effects.

Let me give you an example. One side effect of what you describe is lambda functions, and a cool feature distinguishes lambda functions from simple function pointers in C is closures.

Perl provides the equivalent of Lambda functions in the form of anonymous subroutines, and they are also closures.

So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.

What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).

That is probably the one major thing that Perl 6 will need in order to truely surpass Lisp's flexibility for general purpose tasks, and while it has been much discussed on the mailing lists, it won't be realistic to decide on it, and nail it down fully for a few itterations of the apocolypses. But it's certainly clear that Perl needs some form of macro system that is at least very nearly as flexible as Lisp's.

Perl's eval is a red-herring. It's really a totally different (pair of) functions from Lisp's eval, acting as either parser or exception-handler. Lisp's eval is much more comparable to Perl 5's ->() operator which dereferences and executes a code reference which can be a reference to an anonymous or named closure, a subroutine or a regular method.

You can also build CVs, which are just data-structures, in C and present them to Perl as a code reference. That does give you all of the power of Lisp, but you have to drop down to C to do it, so it isn't at all trivial or useful for routine use.

Re:Perl 6 \not\in Perl ?

[chromatic]

It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See ... And Now For Something Completely Similar, also by Damian.

Backwards compatibility is a huge concern. That's why Ponie exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)

Re:For those who don't know....

[n1vux]

In addition to the Apocalypses and Exegeses, Damian and Allison have produced two

• Synopses, which are shorter and quicker to market.

The names are a running gag on church-latin, that interconnects Larry's linguisticism, Damian's eclecticism, and the monastic themery of the Perl Monks' alternate retroynm for .PM. Larry's Apocalypses are not apocalyptic in the common figurative sense (although the neo-Luddites who think the only improvement on Perl5 is PHP or Python may think so), but are the Revelations of the gur, which is the original sense of the word, before it came to be used to refer to the particularly apocalyptic content of St.John's Revelations also called Apocalypse in the latin. The churchly Exegeses are non-canonical explanations of the deeper meanings of the canonical texts. And of course, synopses are shorter summaries, like Cliff Notes (TM) or Master-Plots (TM), and were originally applied to religious writings of course.

require sig 1.3;

Re:Perl 6 \not\in Perl ?

[chromatic]

Would that everyone were so blind!

• I have had code in Parrot for years. I have commit access.
• I've taken hundreds of kilobytes of notes during Perl 6 design meetings.
• I read the Apocalypses, Synopses, and Exegeses as they're being written and revised, weeks and months before they're released.
• I helped quadruple the number of tests in the core test suite between Perl 5.6 and Perl 5.8.

I think I have a pretty good sense of Perl 5, Perl 6, and Parrot.

I also know how many Perl Foundation dollars have been spent to get Parrot where it is today. It might be enough to hire one of the top .NET folks for most of a year. For the money, Parrot's a bargain.