Slashdot Mirror
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."
I mean, whitespace hasn't even been made meaningful yet.
Where's $\space and $\tab ?
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?
--------
Free your mind.
- 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.sub Fahrenheit_to_Kelvin (Num $temp is rw) {
... ; :-)
Verbosity in coding, yeah that will go over well with people who are used to
int lbn, rax,
Don't get me wrong I'm a big fan of Perl, but not for its completeness as a language but for the ability to quickly write small utils to parse text.
But I suppose whatever floats peoples boats.
Tom
Someday, I'll have a real sig.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
Thank God Damian isn't working on the Apocalypses...
Yes.
You don't have to! You could just as well use:
Perl will allow either. It's your choice. You can do the quick one-off-hack-it-up-at-3am-after-two-large-pots-of- coffee, and you can have a large programming project that must be maintained for years to come.
You have the choice. Pick whichever method fits the task at hand.
20 mil and I will! Learn Esperanto with 20M others.
the language is becoming more obtuse if thats possible. The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax. Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either. I guess they don't go for re-use much in perl progging. I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)
TallGreen CMS hosting
I've never seen a language with so much syntax. Perl 5 had more than enough, now they've more than doubled it.
:= 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 { } for blocks, and for automatically parameterized blocks (ie. anonymous functions).
You have =,
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
Shortly after I started reading Exegesis 6 I was somewhat frightened by how complex Perl had become since I stopped keeping track of updates. Of course scripting languages have always been known for borrowing the best from other programming languages, so I kept reading in the hopes that I'd recognise something. I saw some features like the is constant declaration and started worrying that maybe they'd decided to borrow some features from the very popular but insanely evil Visual Basic. But then I saw this:
and realised that, just as Python is (alleged to be?) adding Lisp-like features, Perl is adding ML-like features! That line above is (minus the '::' and ';') straight out of a Haskell program. Then I started to notice more Haskell-like syntax:
feed (Cat c) =
feed (Lion l) =
And I'm sure a more thorough reading would turn up even more. (For example, the smart-match operator reminds me of the type inferences done in a Hindley-Milner type system.) So it appears that any sufficiently advanced language contains an implementation of a purely functional language, not specifically Scheme. :) Has Damian (who certainly has Haskell exposure) or Larry ever mentioned any of these influences?
One more thing:
I'm really happy to see Perl include currying, I can't think of a programming language that I would be completely happy using without it.
Perhaps the Perl motto should be changed from TMTOWTDI to TAMODVPCWDSSAAMSTWDI:
"There's a multitude of different visually pleasing constructions with deceptively subtle syntax and auto-magical semantics that will do it."
Okay, I love Perl 5... Perl 6 looks really cool but overwhelming. I'm glad they're adding the options for stricter type-checking and such, but remembering the syntactic shortcuts is gonna be even harder. I don't even want to know what the parser code looks like...
My bicyles
In the denotational semantics community it was long ago decided that real programming languages are too messy and too much of moving targets for serious theoretical research. As a result, the most popular language is known as Idealised Algol which is a simplified and cleaned-up version of Algol-60 (I'm told Algol-W is the closest implementation).
Now that Perl 6 has a rich operator definition system*, we can look forward to Idealised Perl (IP). IP would be a version of Perl stripped down to only the necessary syntactic building-blocks. Even if much of Perl 6 were implemented in C, it'd be possible to define all the syntax in terms of IP. If you're writing code for maintainability instead of prototyping, using IP as much as possible will ensure a smaller learning curve for non-gurus. IP will be simple enough to actually allow teaching Perl in universities.
IP could be the elegant yet expressive language we all (whether we like Perl or not) wish Perl would be.
* This is, IMO, the only really neat and elegant thing to come out of Perl 6 so far. If operators can be defined to the point where most mathematical formulae are executable, Perl will become a revolutionary tool.
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.)
how to invest, a novice's guide
I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.
That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,
In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.
Probably because he doesn't know what he's talking about, and there are numerous errors in his post.
For example, he claims that each variable has its own prefix in Perl 5. That is completely false. A "variable" in perl is a reference to a typeglob, which contains memory slots for each type of value a "name" ( variable ) in perl can store: a scalar, a hash, an array, a filehandle, and a subroutine. The prefixes before a name in perl determine which slot you access ( it is the context you are calling the variable in ).
For instance, @var for the array slot, $var for the scalar slot, %var for the hash slot, &var for subref, etc.
Each "variable type" does NOT have its own prefix. The prefixes specify the context that the variable is being called in.
By the way, *var references the entire "typeglob" at once, allowing you to do things like:
$var1 = "name";
@var1 = (1,2,3);
*anothervar = *var;
print $var1
name
print $var1[1]
2
Maybe if the person actually knew anything at all about perl, then his post would actually be worth paying attention to.
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.)
-- Ed Avis ed@membled.com
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.
-- Ed Avis ed@membled.com
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.
Would that everyone were so blind!
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.
how to invest, a novice's guide
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.
how to invest, a novice's guide
I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.
If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.