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

[Anonymous Coward]

The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?

Python syntax is close enough to C, C++, Java et cetera not to cause most people any problem - except in the few places where it isn't, of course!

John Roth

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).

Re:Perl floats *all* boats

[Marx_Mrvelous]

Actually the parent is wrong. The bahavior os f2k($temp) is different than f2k($temp is rw) in that Perl will assume a constant variable by default. So no, you don't *have* do, unless you want to make your parameters read-write. Which could lead to less lines and variables later on.

Re:Keywords

[ajs]

You gave the example:

vtime = time()

Actually, that's a great example! Let's say you write that in C. Then, a year later ANSI C 0x is published and lo, "vtime" is now a keyword!

In Perl, you are guaranteed that your variables will never conflict with keywords. Not ever. Not even if you try.

Re:Keywords

[Waffle Iron]

Can you see the advantage here?

int a=1;
WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());

What's the big deal about that? In Python, for example, you can do the same thing with much less fuss:

a = 1
print 'a is type %s and has value %s' % (type(a), a)

or with your positional parameters:

a = 1
print 'a is type %(1)s and has value %(2)s' % { '1': type(a), '2': a }

The same string conversions happen. 'a' is still an integer, and the language knows it. You just don't have to keep typing 'int' and 'toFoo()' over and over.

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:Keywords

[chromatic]

In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler.

Parrot has both today. (Okay, it just picked up the standalone binary compiler a couple of days ago.)

Re:Keywords

[Q2Serpent]

When they say "keywords", I'm sure they meant "functions in the global namespace".

Re:Keywords

[msuzio]

Actually, the following code (in Perl 5):

$foo = "bar";
$foo++;

Result in $foo holding the string "bas" right now ;-). I haven't puzzled out the Perl 6 stuff enough to know what would happen then (probably a compile time error in assigning "bar" to $foo if $foo is declared as holding only numerical types).

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:Perl 6 \not\in Perl ?

[Ed Avis]

I don't think it is any more different from Perl 5 than Perl 5 is from Perl 4. Huge amounts of extra stuff (most importantly objects and nested data structures) were added from 4 to 5, together with quite a few syntax changes.

However, backwards compatibility will be more of a gap, because perl 5 is pretty much source-compatible with perl 4, but it doesn't seem that 5 -> 6 will be the same. (No, having a separate interpreter specially built to run older scripts doesn't mean source-compatible in this sense - I'm talking about the language itself.)

Re:Troll-by-reference

[Ed Avis]

Your terminology, using 'variable' to refer to a whole typeglob slot, is nonstandard in the Perl world. Most programmers (and Larry himself AFAIK) would say that $x is a scalar variable and @x is an array variable. They are both variables and both different.

Referring to the whole typeglob with *var is rather esoteric (not saying it's never used, just it is used far far less often than accessing variables normally), and when you do use it, you talk about typeglobs not variables. *var is a typeglob, which brings together several different variables of the same name.

At least, that is the terminology almost everyone uses.

Re:Keywords

[bnenning]

.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing.

Java solved that problem many years ago, and Smalltalk solved it many years before that.

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.

Re:Perl 6 \not\in Perl ?

[chromatic]

Parrot's been around two years, not three. The oldest Perl 6 code I can find running on Parrot goes back one year.

Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Parrot work funded.

Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.

The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.

Re:Keywords

[jbolden]

Nice try but no. See apocolypse 1, you need a keyword to be in Perl 6 syntax otherwise it falls back to Perl 5 for the entire file. So absolutely nothing happens.

Re:Keywords

[ajs]

Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.

Oh so?

$complex{data}{structure}{of}[$n]{hashes}[2]{array s}{and}{an}->object(); = "Stuff";

That does not seem very nighmarish to me. What's more, manipulating complex data on the fly is trivial in Perl:

$struct = [1, 2, 3, { a => [5, 6, 7], b => [8, 9, 10]}]

which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are themselves arrays. Not that hard is it?

There is the container-access syntax that I find rather messy, but even that's not so bad, and it goes away in Perl 6 entirely, again without impacting that very clean way of identifying variables that lets you do things like

$foo = "dogs";
$bar = "cats and $foo";
$baz = qr{($bar)+};
while(<>) {
if (/$baz/i) {
print;
}
}

with one, uniform syntax.

Re:Keywords

[ajs]

There is no advantage

No, I pointed out a few already, and there are others. You simply happen to disagree. That's fine too. Perl is about accomodating disagreement in a single language, and that's hard to do with a limited keyword set.

You're carrying type-information around everywhere you go, because you think it allows you to add keywords

I've pointed out elsewhere that type information and variable glyphs are different. They do have an association to type, but it's a loose one.

For example:

$x = 1;
$y = [ 1, 2, 3];
$z = new IO::Socket::INET
PeerAddr => 'yahoo.com',
PeerPort => 'http(80)',
Proto => 'tcp';

Here you have three variables. One is a simple scalar. One is a reference to an array. One is an object that represents a socket, connected to the HTTP port of a remote server. The $ doesn't tell you a whole lot about type, it just indicates a scalar access-mode.

Do you know why C doesn't add new keywords

*I do*, but I wonder if you do....

C does not add new keywords because it is a syntactically simple language, and that's part of its attraction. Any attempt to change that (e.g. the way C++ did) would destroy that, and would need to justify such a change against the benefit.

I think that Perl does justify this increase in complexity, though to most outsiders that's not obvious. You really need to be able to think in Perl before you understand just how valuable all of that syntax is.

At one point, I knew C so well that I thought in it. That was long ago, but I still remember how powerful that was.

When I learned Perl well enough to think in it, I was introduced to a new kind of programming. I was suddenly able to write in a few lines of code, what would have taken pages and pages of C, even with a good set of libraries. Just the ability to say:

@foo = sort map {"$y{$_} $x{$_}"} grep {$_ > 0} @bar;

dwarfs the abilities of C.

That's not to say C is useless. I still use it from Perl all the time, via XS. If I had to write a device driver or any other low-level code, I would still use C. But for your run-of-the-mill software, Perl is leaves low-level languages, and even most high-level languages far behind... at least from my, admittedly limited, point of view.