Damian Conway Publishes Exegesis 5 125
prostoalex writes "Come gather round Mongers, whatever you code,
And admit that your forehead's about to explode,
'Cos Perl patterns induce complete brain overload,
If there's source code you should be maintainin',
Then you better start learnin' Perl 6 patterns soon, For the regexes, they are a-changin'. This remix of Bob Dylan serves as an epigraph to Exegesis 5."
back to school (Score:1)
quoting from the article
"Even more importantly, as powerful as Perl 5 regexes are, they are not nearly powerful enough. Modern text manipulation is predominantly about processing structured, hierarchical text. And that's just plain painful with regular expressions. The advent of modules like Parse::Yapp and Parse::RecDescent reflects the community's widespread need for more sophisticated parsing mechanisms. Mechanisms that should be native to Perl."
Will these be compatible with the older, i mean backward compatibility, i certainly hope so.There's a lot of new syntax there, so let's step through it slowly.
this goes a real whoa over my head man. Seriosly i dont wanna be trolling, but i wish the language used was simpler. For a regex expert this is good, but for a newbie or mediocre level guy like me this is bad!! And there are not many free regex courses on the net!
Re:back to school (Score:4, Informative)
Re:back to school (Score:2)
Re:back to school (Score:2, Informative)
Monty Python and the Holy Grail Sinking Castle (Score:4, Funny)
-Don
Re:Monty Python and the Holy Grail Sinking Castle (Score:4, Insightful)
Re:Monty Python and the Holy Grail Sinking Castle (Score:1)
Re:Monty Python and the Holy Grail Sinking Castle (Score:2)
-Don
Re:Monty Python and the Holy Grail Sinking Castle (Score:2, Interesting)
On another troll note, that extra syntax and abbreiviations for the "rule engine" (is that anything like a python service? probably not...)- a whole new other World Of Pain to enter. Less is better, IMTO. At least we won't see the end of messages saying "have you tried perl -w?" It's a pity somebody didn't build a Perl with -w, use strict and limiting the scope of $_ *switched on as default*. This would get rid of most the frustration.
With Perl6 scavenging CPAN for functionality, CPAN6 should be a lot smaller (if One True CPAN is retained, there will be even more Chaos, and I had enough trying to install the Multitude of Modules to get SoapLite.pm installed).
grumble, grumble, grumble
hachete
born to troll
Re:Monty Python and the Holy Grail Sinking Castle (Score:1)
Sad to hear that. On my system, it was a matter of apt-get install libsoap-lite-perl. The purpose of maintaining a package in a distribution is to ease the work of others. =)
Re:Monty Python and the Holy Grail Sinking Castle (Score:2)
Um, sorry, but those features have been in Perl regexes since the beginning.
Re:Monty Python and the Holy Grail Sinking Castle (Score:2)
It's a pity somebody didn't build a Perl with -w, use strict and limiting the scope of $_ *switched on as default*. This would get rid of most the frustration.
While I see your point here, I think making 'use strict' and -w the default would push a lot of newbies choosing between Perl and PHP over to PHP. Not that this is a competition for programmers or anything, but Perl was the first language I learned primarily because you could pick it up and write (admittedly) bad code that would actually DO something. Over time as I because familiar with Perl and programming in general, I was able to improve my habits and now I use -w and 'use strict' in everything I write. Yeah, you can argue that forcing good programming practice makes better code and better programmers, but at the expense of how many would-be Perl programmers?
To me, Perl 6 in "strict mode" is basically going to be Java with a better regex engine. Java's lack of a relaxed mode (and its commercial nature) kept me away from it when I was picking a "primary" language for my programming arsenal. Of course, now that I have some much time invested in Perl I'll eventually make the leap to Perl 6 - and maybe I'll be a better programmer for it - but I think picking up Perl 6 is going to be hard enough for the newbie programmer.. I certainly would hate to force 'use strict' and -w on them.
Shayne
Re:Monty Python and the Holy Grail Sinking Castle (Score:2)
I always read that as a metaphor for civilisation, myself...
Finest Code in These Islands (Score:1)
Finally? No: [stone-dead.asn.au]
OK, so it was the fifth or sixth one ... but it's still the finest code in these islands!
Re:Monty Python and the Holy Grail Sinking Castle (Score:3, Insightful)
Don't forget, the last one stayed up. And it was the strongest castle in all of Britian.
Ugh (Score:4, Interesting)
Re:Ugh (Score:3, Insightful)
If you don't like it, you don't have to port it.
There are still people using emacs 18 to edit their files because it's small and it works.
There are still people running Windows 98 to run their games because it works.
Nobody's forcing you to move to Perl 6. That's the beauty of Open Source. Perl 5 is going to be developed for a long time to come. Don't give up hope.
-Dom
Re:Ugh (Score:2)
Change for the sake of change; go Ruby! (Score:2)
The rationale for losing arrow was that it made more operators available, and that it was more familiar to users of other OO languages. I suppose it's also easier to type; not only one less character, but no shift key. But it seemed like a change just to force old programs to be rewritten.
And ARGV? Simply because it was supposed to be old fashioned, unfamiliar, not obvious. BAH. Change for no reason other than to commit breakage and force a rewrite.
I will probably switch as time goes by, but to Ruby rather than Perl 6. If I'm going to have to touch every file, I may as well do it the right way.
Re:Change for the sake of change; go Ruby! (Score:2)
Keep a
If I'm going to have to touch every file
But you're not, are you? You can keep writing in Perl 5 for as long as you feel happy, even to the point of porting separate subroutines to Perl 6 as you feel the need.
Re:Change for the sake of change; go Ruby! (Score:2)
I don't mind most of the changes. I think the regex changes are good, on the whole. I object to change just to cause breakage, like ARGV. There is no other reason for that, except to cause breakage. What else is going to be changed just for the hell of breaking things? If I have to put up with that, I may as well go whole hog, and go to Ruby.
Re:Change for the sake of change; go Ruby! (Score:2)
Re:Change for the sake of change; go Ruby! (Score:2)
Theory be damned. Practice says it's Perl 6 or something else. I choose something else because I don't like change for the sake of change, it makes me wonder what else will break just to be broken, and that is something up with which I shall not put.
Re:Change for the sake of change; go Ruby! (Score:1)
Re:Change for the sake of change; go Ruby! (Score:2)
Sure, and you have the advantage that Ruby works now, while Perl 6 will take years. However, I imagine Ruby will make some changes as it matures, which may lead you to think "Hmmm, I can't be bothered putting up with this, but Perl 6 has just been released. Maybe I'll play around with that for a while..."
CPAN is one of the best things Perl has going for it, and that's not (only) because of the langauge, that's because of the community. I don't necessarily know that all of the community will ever move to Perl 6 (maybe less would if it were called something else), but if they do, it may make learning Perl 6 worthwhile, just to continue to access large amounts of useful, Free code.
Re:Ugh (Score:2)
My observation about PHP: some things are over done and other things are completely underdone. Nothing feels completely right. I spent hours pulling out my hair the other day just trying to find an extension that can parse HTML decently (mostly what I found were people's half-baked regex solutions
Anyway seriously Perl 6 looks really awesome and you won't have to port stuff that works because it has a Perl 5 compatability mode. If you're going to learn a new language anyway why not learn Perl 6?
Re:Ugh (Score:2)
You've got PCRE and POSIX regexp, what else do you need? How is PCRE nowhere "near as powerful as Perl"?
Because there are over 1,000 of them all sharing the same namespace. What's especially irritating is they don't all follow the same naming convention.
Because it's not very interesting. Learning new languages helps you gain multiple perspectives on problems, sticking with the same language sticks you in a rut where you only have a few views of how to solve a problem, none of which are necessarily optimal.
Personally, I'm looking at SmallTalk after Ruby, or maybe Lisp.
Re:Ugh (Score:2)
Feel free, I'd be the last person to dissuade someone from learning another language. It'll be more like a wade than a plunge, of course, but if all you do is "web stuff", perhaps PHP or cold fusion are more your style. Personally I use things like Parse::RecDescent, Safe, POE, and Tie::MLDBM, but I do things slightly more complex than guestbooks.
Personally I can't see why people complain that such an ugly language is becoming not uglier but just a different shade of ugly. Only thing that really tweaks me is the awful _ operator. I think I'll be doing more interpolation now instead. My main complaint was that all these apocalypses were turning perl6 into vapor, then out of the blue, the parrot crew writes what amounts to an alpha release of perl6...
Still, I now have extension work in C and C++ to do , and when it comes to that, it's hard to beat python. Perl5's source gave me the screaming fantods, so I don't hold out a lot for perl6's hackability. Perl6 is definitely not too little, but for this hacker, it may well be too late.
Sticking with Perl5 (Score:1)
I think that's not merely acceptable but actively encouraged. Perl6 is meant to be pretty much a different language from Perl5 - a nice, shiny new toy that will great for some things and less good for others. Just like, say, Java. But you don't feel apologetic about not porting your Perl5 programs to Java, and neither should you about not porting them to Perl6.
Will Perl6 be a better new language than Ruby, Python and the rest? Aye, there's the rub. No idea.
Re: (Score:1)
Re:Sticking with Perl5 (Score:1)
That is not an accurate assessment. As this article [samag.com] illustrates, many real-world Perl 5 programs will port to Perl 6 with little (and sometimes no) changes required.
In Exegesis 5? Of course not. Because the Exegeses supposed to explain the Apocalypses, which are specifically about the differences between Perl 5 and Perl 6.
When I'm writing code [samag.com] to illustrate the similarities between the two, then the Perl 6 code looks very much like Perl 5.
The problem here is that you have a language being developed by a linguist, not a computer science guy.
Actually, no. Perl 5 was the language that was developed by a linguist [perl-foundation.org], not a computer science guy. Perl 6 is the language being developed by a linguist [perl-foundation.org] and a computer science guy [yetanother.org] (amongst others [perl.org]).
The simple fact of the matter is, all of the grammar is changing.
No it's not. Not even close. Something less than 20% of the grammar is changing.
All of the keywords are changing.
Again, simply not true. Not one of the following keywords is changing: for, while, if, unless, until, goto, BEGIN, END, INIT, CHECK, DESTROY, bless, caller, chomp, close, defined, delete, die, exists, exit, fork, getc, goto, grep, index, int, join, keys, kill, last, lc, lcfirst, length, lstat, m//, map, my, next, no, open, ord, pack, package, pipe, pop, pos, print, printf, push, q//, qq//, quotemeta, qw//, qx//, rand, redo, require, reset, return, reverse, rindex, s///, scalar, seek, shift, sleep, sort, splice, split, sprintf, sqrt, sub, system, tell, tr///, uc, ucfirst, undef, unpack, unshift, use, values, vec, wait, warn, y///.
Those of us on the design team certainly understand that it can sometimes feel like Perl6 is nothing close to Perl 5, and like all the grammar and keywords are changing, and that the linguists are now running the asylum. But the reality is -- as usual -- considerably less fearsome, uncertain, or doubtful than our fears might lead us to believe.
Re:Ugh (Score:5, Informative)
You might want to have a look at this article [perl.com] which highlights some of the ways in which Perl 6 is not changing.
"Ugh" is what I say when I think of PHP (Score:2, Interesting)
Look, I'm sorry but exactly what was supposed to be great about PHP? the fact that you can easily embed it in HTML code, that it integrates cleanly with MySQL and that you can pass args to it easily. Let us demolish each of these in sequence
* HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like this:
<ul>
<?php foreach ($users as $user) { ?>
<li><a href="user.php?userid=<?php echo $user->userid ?>"><?php echo $user->username ?></a></li>
<?php } ?>
</ul>
and, say, the equiv in Template Toolkit:
<ul>
[% FOREACH user = users %]
<li><a href="user.pl?userid=[% user.userid %]">[% user.username %]</li>
[% END %]
</ul>
now you tell me which looks neater? HTML-like templating syntax just looks dire because it all falls apart when you have to include stuff inside attributes. Not only is it ugly but it's unmaintainable. Want to skin your site in PHP? forget it. Want to skin it in perl/TT/CPAN templating engine of your choice? no problem, just supply a different base path to your template engine of choice. Of course most PHP coders have realized this so they've created their own templating engine, or use something like Smarty and just wrap everything in one great big PHP tag. Which quite frankly just defeats the entire point.
* Argument passing - this is hellish. Anything that comes in in a query string, cookie or post variable immediately enters your global namespace, where your often CRITICAL state variables are - hope you initialized them! I can't tell you how many times I got exploited by some stupid XSS exploit or the totally useless ability of include() to pull stuff in over HTTP. It's bad enough when a script kiddie just needs a unix system and the ability to use a compiler to root a machine but when 'h4xx0ring' can be done just by typing http://phpbb.mysite.com/includes/db.php?phpbb_roo
* MySQL integration - eh?! I'm sorry but I HATE the PHP MySQL API. The error handling is a joke so most people write their own wrappers around MySQL to catch errors and deal with them (that or it's back to checking the return value of every little thing. Thanks but if I wanted to do that I'd program in C). That and don't get me started on slashing. php.ini is set up so that your incoming variables may or may not get slashed. Again, you can't influence this or count on it if you've got shared hosting of some sort so either you've got to manually strip all the slashes out again or put them in - in which case you either have to deslashify something if you're using it internally or slashify it when passing it to mysql_query() to make sure someone doesnt take a great big shit all over your SQL. And that's if you're using MySQL. If you're using Postgres, there's a different API, and if you're using Oracle then there's a third. The fact that there's TWO different database abstraction systems built into the core of PHP (DBx and ODBC) and then some in PEAR shows that something is really horribly wrong.
Now compare to Perl DBI or Java JDBC or anything else which actually has a sane DB access API.
eval {
my $sth = $dbh->prepare('SELECT userid FROM user WHERE username = ?');
$sth->execute($username);
my $userid = $sth->fetchrow_array;
} if ($@) { confess "SQL Error: $@"; }
which in PHP looks like
if (!get_magic_quotes_gpc()) {
$username = addslashes($username)
}
$q = mysql_query("SELECT userid FROM user WHERE username = '$username'")
or die("Query failed: " . mysql_error());
if ($r = mysql_fetch_row($q)) {
$userid = $r[0];
}
I know which one I prefer. That and let's not forget the fact that every time you access a page, that page is parsed, its dependencies are parsed, initialization is performed, and then it handles your request. Also the standard library that comes with it is cack - everything is in the global namespace, there's no object orientation at all, parts of it look like the C standard library's been retrofitted into it because the designers were too damn lazy, it's inconsistent, there's several conflicting ways of doing everything and it's so badly designed that you're usually working AGAINST it than with it. (want to slurp a file? well you can use the file() command to make an array of lines, which you can join together again, or you can use readfile() which sends a file directly to the client, however you can get round that by using output buffering to capture it. Or you can use fopen() and the related commands to open the file, find its size, read it into a scalar then close it again. Aargh!)
Now, look, I must admit Perl isn't great either. mod_perl is fast as lightning but it's got a ton of idiosyncracies of its own (mainly in the way of including things, eg include paths, namespaces, etc) and a lot of weird side-effects that are far from obvious and get in the way most of the time. I've written my own mini-wrapper around it that irons most of it out but it's still quite a pain.
As for PHP though, it does have its place, but remember what PHP stands for - PHP Hypertext PREPROCESSOR (I think). As SSI on steroids with some ability to interface with MySQL, it's a great system. But writing things like messageboards or shopping carts or portals in PHP is sheer lunacy. I've managed a PhpBB and a vBulletin as well as writing a mini news system that integrates with vB so maybe my experience isn't that great and someone ought to hit me with a clue-by-four. But if you can, please do because from what I've seen I find it very hard to like this language.
OT: Re:"Ugh" is what I say when I think of PHP (Score:2)
You can also do this:
<? foreach ($users as $user)
{
include "templates/user/usertemplate.php";
}
?>
Then usertemplate.php contains
<li><a href="user.php?userid=<?= $user->userid ?>"><?= $user->username ?></a>
or
<? echo "<li><a href="user.php?userid= $user->userid">$user->username</a>" ; ?>
The trick is if you tuck most (or all) of your html in the templates directory then you can have skinning. Just make multiple templates directories and keep track of which one you're pulling the content from. This forces you to split your html from your objects, and as a bonus you get more code reuse. Your object's html templates are neatly tucked away in their own directories.
RE: * Argument passing
Turn off register_globals and use $_REQUEST and the other superglobals to do what you need. Never trust user input, yadda yadda. This has been a weakness in the past, but now it's a bit harder to get burned. I shot myself in the foot a couple times and had to learn how to deal with this stuff. PHP is a newbie friendly language, but secure PHP takes some experience to get right.
RE: * MySQL integration
Agreed. About this time last year I finally rolled my own DB wrapper that does what I need. My gripe with most abstraction layers is that they may claim to be DB independant, but cater to the lowest common denominator: mysql. Sorry, but if I'm using a "real" database I'm going to break out the stored procedures, transactions and more. If I get to use stored procedures, then my overall approach is going to change enough to break the abstraction layer. Things may have improved, but the last time I looked at it I went with the db specific funtions. I'd like to see some improvement here.
More notes:
As far as the 'parse, parse, reparse and initialize' cycle, you can alleviate some of that with caching. I've rolled functions to do this by output buffering entire pages (or significant includes), placing them on disk or in the database and serving those to the users. It depends on how often you update your site, but for fairly static pages it works OK. You can also break out the Zend cache or other products if you want to 'do it right'.
I don't see a problem with three different ways to open a file. Each one has a use and a historical reason for existing. Each one also gets the job done for the general case. Yes the namespace is a bit cluttered but the docs are very good. It seems like a design goal for PHP has been to wrap every useful library they can. This brings in a bunch of the C style file operations. Then you get the design goal to make tools to build webpages. That gives you output buffering tricks and so on. Learning to deal with this is all a part of PHP.
Just because PHP makes it easy for a 'non-programmer' to submit a form to a database it doesn't mean that it is an easy language to use for large projects. Maintaining bad PHP is hell and refactoring can be problematic. However, I do think PHP is appropriate for portals, message boards, and online catalogs. You just need to take the right approach: Object orientation (or good procedural libraries), templates, php.ini tweaking, coding standards and so on. It's not the easiest language to scale up, but it can be done. The problem is that it is such an easy language to do litle things in, they screw up when they do big things with it. Just like Perl.
Re:"Ugh" is what I say when I think of PHP (Score:2)
* HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like [...] the equiv in Template Toolkit:
<ul>
[% FOREACH user = users %]
<li><a href="user.pl?userid=[% user.userid %]">[% user.username %]</li>
[% END %] </ul>
I'm surprised no one has pointed this out, but the equivalent PHP construct could look something like this:
<ul>
<?php foreach( $users as $user ) { ?> {
<li><a href="user.pl?userid=<?php echo $users[$user]['userid']; ?>"><?php echo $users[$user]['username']; ?></li>
<?php } ?> </ul>
Duplicating the obhect notation is also quite possible, I simply chose and array of arrays as an example. Of all your PHP indictments, that was the weakest.
Re:"Ugh" is what I say when I think of PHP (Score:1)
Ack. Too early on a Saturday morning. $users[$user]['userid'] and $users[$user]['username'] should simply be $user['userid'] and $user['username'], respectively. My PHP is a tad bit too rusty at the moment. :P
Let me get this straight (Score:4, Insightful)
Re:Ugh (Score:2)
I know that everyone has their opinion, but this one is mine.
Just my 2c.
Hey, cut it out! (Score:2)
Oh, wait, he's not dead yet.
Carry on . . .
Re:Hey, cut it out! (Score:2, Funny)
<dad> Son, do you even know who Bob Dylan is?
<doug> No, But I know he died of drugs.
<dad> No Doug, he's alive and well, as a matter of fact I produced his last two albums.
<doug> Oh Uncle Robert?
Re:Hey, cut it out! (Score:1)
"I'm Doug, and I'm out-ta-here."
Re:Hey, cut it out! (Score:1)
backwards compatibility? (Score:2)
I know guys who can regex in their sleep, and they've been using mostly compatible syntax for YEARS! This new stuff looks completely different, and if perl isn't going to be backwards compatible, i forsee a huge backlash, or a AnotherGNUPerl fork or something. (AGP is taken... doh)
it's important to allow people to use existing skillsets while expanding into the new syntax.
Re:backwards compatibility? (Score:2, Insightful)
This is standardising cutting-edge (even compared to most lisp + prolog AI-related parsing stuff, and that's always ad-hoc) parser as part of the standard language.
Re:backwards compatibility? (Score:2, Insightful)
From what I've read, Regexen are staying _basically_ similar (basically), but Damian Conway being the sick evil bastard he is, they're going to incorporate some higher capabilities into the engine that look an awful lot like his Parse::RecDescent [cpan.org] grammar parsing module.
I mean, really, at their base, he's moving around flags a little, making whitespace default insignificant, and tinkering a few flags. It's when he starts making rules and backtracking capabilities (which exist in the current language, in clunky form, as he demonstrated) that it starts getting wacky.
What it comes down to, though, is that noone should be thinking 'Oh, man, now I'll have to port all my perl to perl 6.', because Perl 5 isn't going to die out or anything, just get phased out like perl 4 - left at a stable rev for support purposes.
Re:backwards compatibility? (Score:2)
Re:backwards compatibility? (Score:2)
Nonsense. Perl 6 will continue to use
(ooo. should I have said \\'s? )
Flamebait - it'll never fly (Score:1)
Sorry!
Re:Flamebait - it'll never fly (Score:2)
it's like Sexy Jesus (Score:2)
-c
skimmed the article (Score:1)
This might be a good thing, since parsing XML is becoming more important. Anyone get the same feeling, or am I smoking weed?
Re:skimmed the article (Score:5, Informative)
Re:skimmed the article (Score:1)
Re:skimmed the article (Score:1, Informative)
By the way, it's "Perl," not "PERL." [perldoc.com]. The language is "Perl," the interpreter (the actual program itself) is "perl." Perl is not really an acronym (that was made up after the fact), so "PERL" is not correct.
What does this mean for CPAN modules? (Score:4, Interesting)
CPAN is a powerful resource. If all those modules get left behind, I fear we may end up with a more eloquent language in Perl 6 but with substantially less usability.
Re:What does this mean for CPAN modules? (Score:3, Informative)
Since most existing CPAN modules lack this keyword they will all run with the Perl5 interpreter. There may be some oddities with modules that use native code or other odd features, so obviously there will be a testing phase.
Additionally, at least for OOP-type modules, everything you can do with objects in Perl5 can be done to objects in Perl6 (albeit with minor differences in the syntax), so and Perl5 module should work cleanly in a Perl6 codeblock. Obviously, since Perl6 objects have a bit more power, you can't necessarily take those back to Perl5.
Of course, there will probably be some mechanism to update CPAN modules from Perl5 to Perl6, leaving the Perl5 version in place, but exactly how this is do be done, it's way too early to tell.
Re:What does this mean for CPAN modules? (Score:3, Informative)
This will be for modules, not programs. A Perl 5 module begins with 'package Acme::Foo;'. A Perl 6 module will begin with 'module Acme::Foo'. This is explained in Exegesis 4 [perl.com].
CPAN will be just fine, thank you (Score:2, Informative)
Looks like it's needed, but ... (Score:2, Insightful)
Perl6 FAQ (Score:5, Interesting)
- Why is Perl changing so much?!
- But what about my programs? Why break them?!
- Why would you want to break compatibility with other regular expression engines?
Some of this will be good for everyone. Some of it some of you won't like, but a lot of it you will. Give Perl 6 a chance, and don't react as if we've shot your pet.Because it needs to. Perl is the legacy of something like 15 years of development and evolution. It started as a simple text processing system, and is now used in every field of endevor where computers are used. There are some old things that needed to go, some new things that were needed and generally a need to re-examine the way "stuff" was done.
Perl 6 is two things (at least): a parser for Perl 6 and a back-end virtual machine, much like Java or C#. One of the design criteria for the release of Perl 6 is a Perl 5 compatible parser front-end that outputs Perl 6 virtual machine bytecode. This means that your Perl 5 programs will run with no modification in a Perl 6 environment (or at most a path change to the interpreter, that much is still under some debate).
Remember that Perl has been leading the pack in terms of regular expression handling for a long time. Now Perl is moving beyond regular expressions to grammar specification. This is a good thing, as long as the benefits of regular expressions are preserved.
Re:Perl6 FAQ (Score:2)
Heh, yeah I see a lot of that, and while I imagine you're joking, this is almost the attitude. In the end, I think learning Perl6 patterns will be hard for some people who never really got regular expressions in the first place. For them, there's the Perl5-to-Perl6-bytecode compiler.
For the rest of us, the future is very bright indeed.
The song continues (Score:1)
So we'll march day and night
Glennross and Glenngarry
Our syntactical structures are subject
To the whims of god Larry...
Beautiful! (Score:3, Insightful)
Regex's in Perl have accumulated too much cruft to be called regular expressions anymore. So now they're full grammers.
That's right. Now you can pattern match with a very readable grammer syntax that is easily decorated with Perl code to do parsing. YACC for Perl. You can find packages for this on CPAN, but this is integrated with the language.
No whining about the bad old days of Perl regex syntax for me... now I'm actually excited by the prospect of needing to buy a new llama book.
Or don't switch regexes yet... (Score:2)
Gotta love the sense of humour. After describing one, two, and three colon rules (read the article, page three), they get to the potential fourth...
Basically the new rule (not 'regex') syntax seems to be bent on destroying Perl's "Line noise with a purpose" reputation...Re:Beautiful! (Score:3, Funny)
Re:Beautiful! (Score:2)
Perl 6 will be largely backward compatible (Score:5, Informative)
Almost all of the most useful Perl5 code of today will be runnable by Perl6 tomorrow: the compiler will fall back to perl5 and the VM is language neutral (even moreso that
In addition to running most perl5 modules as-is, Perl6 matching rules will have a perl5 backwards compatability mode built in so you can continue using the Perl5 regular expressions you know and love from Perl, Java, and everywhere else that's adopted them as needed in Perl6 code.
Yes, Perl6 is a rewrite and introduces a lot of deep CS concepts and ew syntax, but some care is being taken to assure that most Perl5 code will be runnable as is, while people learn about the power of some of the advanced tools Perl6 will provide.
Please Don't Panic (or incite others to): the apocolypses and exegises are technical documents, they are not meant to be smooth, easy reading or to reassure today's perlers that their hard won skills will be useful. They're meant to describe what's new and different and usually why. Don't be scared by the new and different, just as with existing Perl, you should be able to adopt the powerful new concepts and syntax as you need to without having to swallow it whole or unlearn everything you already know.
Perl6 will be stunningly more powerful, expressive, and provide (optionally) the safety features required for average coders to implement large systems while letting experts use extremely powerful tools like closures, continuations, intricate pattern matching that have mostly been accessible in academic languages to this point. And it will still allow convenient scripts to be generated if that's what you need to do.
Remember folks, other languages can make shitty code smell nice, but it's still shitty code and you wouldn't want to eat^Wmaintain it.
- Barrie
Re:Perl 6 will be largely backward compatible (Score:2)
I think the Perl heads are doing a commendable job providing a reasonable transition path. There will always be the conservatives calling them radical, and the liberals calling them reactionary.
As long as the noise from the peanut gallery is evenly split, they've approached doing it 'right' about as closely as you ever do.
I'm waiting for Perl6 to delve seriously into these 'rules'. How long?
Re:Perl 6 will be largely backward compatible (Score:1)
Re:Perl 6 will be largely backward compatible (Score:1)
Got it, thanks! We'll all stop now. You've saved us quite a bit of time.
Question about :any modifier (Score:1)
Anyway, in the article, it says there will be an :any modifier that matches a string any way possible, and gives the example:
Ok.. so i get how it returns "ahhh", "ahh", and "ah" - but how the heck does saying "match any string that looks like 'ah*' any way possible" return "a" ?
Is this an error in the article, or am i missing something extremely obvious?
Thanks!
Re:Question about :any modifier (Score:2, Informative)
@matches = $str =~ m:any/ah*/; # returns "ahhh", "ahh", "ah", "a"
@matches = $str =~ m:any/ah+/; # returns "ahhh", "ahh", "ah"
Re:Question about :any modifier (Score:1)
These regexp's are tricky! But this kind of thing makes me look forward to learning perl6 and really digging into them.
Re:Question about :any modifier (Score:1)
ahhh then the ahh then the ah then the a
but in the new version you'd get:
a
ah
ahh
ahhh
a
ah
ahh
a
ah
a
A much longer array.
Wow. A perl 4 geek's summary (Score:5, Interesting)
I first used perl back in version 3, something like 12 years ago. I first really learned perl, v4, about 9 years ago. It did everything I ever needed.
Then, perl 5 came out. I didn't bother "learning" it -- that is, I've been using it, and when I really need to, I've used some perl 5 features, but I've learned them as I go (by example), and I know I'm not really using the full capabilites. (plus, though I know what I'm doing, I don't always know what to call what I'm doing -- I got stumped the other day when someone asked me how to do pointers in perl. I drew a blank, not making the connection to all the weird hash magic I'd been doing lately. But I digress.)
Anyway, the bottom line of this is: Perl 5 looked interesting, but like more of the same, and wasn't really compelling for me to buckle down and learn all the new features. Perl 6, on the other hand, scares me. In a good way.
Here's a page-by-page description of how I read the article:
- Page 1: Hm. Looks like they're describing a grammar with regex. Cool.
- Page 2: I can intuitively match against a set of strings! Wild. These strings can be expressions themselves? Even better!
- Page 3: It's a grammar. A full, honkin, real, honest-to-goodness grammar. That I can match against. Are those angels I hear singing?
- Page 4: <head explodes>
- Page 5: <drools>
Seriously, though, I was concerned at first that I'd have to learn something new, crazy, and difficult (given how screwed-up much of perl 5 has seemed, at times). I'm impressed. I'm very impressed. Yes, I have to learn somthing new and crazy, but it's not at all difficult. In fact, I think I've already learned it.The power that this new system holds, and, more importantly, the simplicity of it all, is amazing.
So, unlike some other posters, I can't wait for Perl 6. When does this come out, again? And, more importantly, when can I buy the new book?
(also, was I the only one who expected, after the demonstration of matching method invocations, to be told that the entire source code for perl6 was just one giant RegEx/Grammar?)
Re:Wow. A perl 4 geek's summary (Score:1)
Could <head explodes> be a legal rule invocation? Rule with an argument?
Jeroen Nijhof
Re:Wow. A perl 4 geek's summary (Score:1)
Yeah, well, same for me, except that I started with perl 5.0xx (with very little Perl 4 before that - didn't do much with it, because the Big Honkin' ManPage was pain to read in DOS!)
I know that for me, Perl 5.6 was not that big of a change. ("Oh, I can use 'use warnings;' instead of '-w'? That's readable! Oh, and 'our ($a, $b, $c)' instead of 'use vars qw($a $b $c)'? Gets better!")
And I know Perl 6 is not going to be a porting nightmare, and will make Perl much more readable in long run. I heard, for example, that the hilariously obscure-sounding scalar(@arr) or unreadable-sounding $#arr+1 will be @arr.length (or something similar) there, which is only positive...
Re:Wow. A perl 4 geek's summary (Score:3, Interesting)
That's correct, and has been Larry's plan since the beginning. The Perl6 eval will be a rule like so:
if
Parrot.execute $code.bytecode;
}
Add command-line handling and that's your
DON'T PANIC (Score:1, Insightful)
I'm glad that support for the
I hope there will be a Camel 6 book! (Score:1)
T-Shirts (Score:2, Funny)
The first thing to note is that, like a Perl 5 qr, a Perl 6 rx can take (almost) any delimiters we choose. The $hunk pattern uses {...}, but we could have used:
rx/pattern/ # Standard
rx[pattern] # Alternative bracket-delimiter style
rx<pattern> # Alternative bracket-delimiter style
rxforme # Délimiteurs très chic
rx>pattern< # Inverted bracketing is allowed too (!)
rxMuster # Begrenzungen im korrekten Auftrag
rx!pattern! # Excited
rx=pattern= # Unusual
rx?pattern? # No special meaning in Perl 6
rx#pattern# # Careful with these: they disable internal comments
Are these allowed for the sole purpose of creating new T-Shirt patterns?
Re:T-Shirts (Score:1)
Awful lot of fuss around regex (Score:1)
Re:Awful lot of fuss around regex (Score:2, Informative)
Re:Awful lot of fuss around regex (Score:1)
So wait a year.
Ruby Rising? (Score:1)
Ruby seems to offer a lot to current Perl programmers, especially when it comes to OO programming - I don't think anyone will argue that Ruby's OO model is much cleaner and more beautiful than Perl's.
Perl6 does seem to have some promising features (like being able to define grammars as shown in the current exegesis) though.... however, I suspect that these ideas don't require wholesale changes to a language (this could be a Ruby module for example).
Re:Ruby Rising? (Score:1)
Re:Ruby Rising? (Score:1)
Indeed, Parse::RecDescent has been available in Perl for years. Of course, it doesn't do all of the things mentioned. More importantly, it's not the internal parser for Perl. You can't use it to change the parsing rules of Perl on the fly.
I'm not sure how you'd do that without making wholesale changes to a language.
Re:Ruby Rising? (Score:2)
Learn both. They both have good points, and bad. I'd love an easier OO model in Perl5, but I'd also like more control over scoping in Ruby. The Ruby and Perl development communities are both listening to each other, from what I've seen, and drawing on their shared and unique experiences to further both languages. Why shouldn't the users of these languages do the same?
Re:Ruby Rising? (Score:1)
Sure, but everyone tends to have a favorite language, a language they reach for first when doing something. Often the problem domain dictates which language you will reach for. Perl was my language of choice for several years, with C/C++ being my secondary language of choice if speed was a requirement (though for text processing Perl often can beat out C/C++). Now my language of choice is Ruby and if I need better performance I write a C/C++ extention. I guess the point I'm trying to make is that for my purposes Perl and Ruby overlap quite a lot and I've found that Perl became unneccessary after I started using Ruby because of the advantages that I found in Ruby (I haven't found myself reaching for Perl for a while now).
What if you had made this statement about 8 years ago:
" I fail to see why people feel that Awk and Perl need to compete. Both can happily live side by side"
After finding Perl most people found that they never used Awk again - that was my experience anyway.
"I'd also like more control over scoping in Ruby"
Can you give more information about what you mean?
Re:Ruby Rising? (Score:1)
As to the users of each language, I think there is a lot of cross-over... but whereas Perl seems to attract a lot of new or returning programmers to its ranks, Ruby seems to be a language chosen by people who've studied at least one other language for some time. And I don't know about the Perl community (although I've certainly put in some time at perlmonks.org), but the Ruby community is generally very open to learning other languages-- witness the HUGE thread on ruby-talk the last week about what language to learn next (inspired by the Pragmatic Programmer's "Language of the Year" project).
Re:Ruby Rising? (Score:2)
"What more control could you want over scoping in Ruby?"
Oh, Ruby's good at this. But going back to Perl the last several months for reasons including Parrot, I've come to appreciate "my". Wile I generally like how Ruby handles scoping, every once in a while there's a problem where I think "everything else makes Ruby a good fit to this, but there's a really nifty Perl trick with my that I could apply here."
I will be happy when they implement (Score:1)
I'm glad... (Score:2)
But because they're sooooo smart, they write things like this:
In other words, a raw variable in a Perl 6 pattern is matched as if it was a Perl 5 regex in which the interpolation had been quotemeta'd and then placed in a pair of non-capturing parentheses.
OK. OOOOK. I'm really looking forward to Perl 6 For Dummies. Now pardon me while I go back to reading something easy, like differential geometry.
But seriously, what really excites me about Perl 6 is Parrot. It's going to be just ultra-cool to be able to link to Python and Ruby (and C) with no fuss and no muss. To me, the rest is just syntactic sugar.
Re:I'm glad... (Score:1)
Re:until any language is as elegant as mathematica (Score:1)
"It is possible to write spagetti code in any language "
Remember that when you are using your favorite programming tool.
You can write very readable and clean code in Perl...
it just takes some dicipline.
Re:until any language is as elegant as mathematica (Score:1)
I thought it was "The determined programmer can write a FORTRAN program in any language." Or something.
Re:until any language is as elegant as mathematica (Score:1)
There is a Perl/Tk spreadsheet. The fact that the underlying data structures of the spreadsheet are exposed to the macro language allows for some pretty incredible formulas.