|
|
|
| Pathologically Eclectic Rubbish Lister | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
recently i became more aware of the existance of the upcoming perl 6 and Parrot. I've read some flames about it why we might (not) want to use it, and i've seen some interesting nodes on perlmonks.Well, for one thing I wouldn't call it "upcoming". What i'm missing however, (not searched well enough?) is a good (and objective) chart whith the differences of these 2 languages, and some real pros and cons.There's not such a thing, and there can't be. The closest thing you can get are Apocalypses, Exegeses and Synopses. Be warned, though, that while Apocalypses are fixed for "historical reasons", the other docs are updated continuously. There are even Apocalypses which are not written yet, but of which there's already a synopsis available. In this sense no book was just as obsolete the very moment trees were being cut as "Perl6 essentials" is! Anyone know of such a chart / paper?Indeed many charachteristics of Perl6 are known. But even basic features keep being redefined and every now and again Larry pops out with a new idea or a rethinking of an old one. All in all the language will be made more consistent. I've often had the impression that it will be slightly less magic as well. But it will still perceivably be Perl. In some sense some amount of magic is being moved from ad-hoc deviations from orthogonality into basic features of the language. For example the way split() works with a regex will not be split() magic anymore, but it will be a well definite consequence of how regexes are evaluated in different contexts. Said this, evidence supports the claim that every single Perl programmer will find some charachteristic or another of Perl6 to be unpleasant or difficult to get used to, to say the least. The behaviour of sigils will be certainly changed. A scalar will always be a scalar, an array will always be an array and a hash will always be a hash. So, to explain with an example, you will have @_[0] instead of $_[0], and similarly for hashes. Some people like this, some people don't. It will be slightly less free-form: putting whitespace between certain tokens will either change the meaning of the program or result in a syntax error. Perl hacker extraordinaire Abigail is particularly upset by this choice. There will be unicode operators. Larry has no doubt about this. All of these operators will have an ASCII equivalent too. Some people like this, some people don't. It will have a complex type system, albeit optional: i.e. you may specify for efficiency that an array contains only integers, or 4-bit numbers or whatever kind of data you like. It will be a massively OO language, even if this won't be forced upon the user and a simple script could still look much like a Perl5 one. As a consequence of this, many predefined variables are going away, substituted by suitable predefined methods. An interesting idea in this sense is the syntax for calling a method on the topicalizer: you use .method() for $_.method(). Similarly you can even use $var.=method() for $var=$var.method(). There will be an ubiquitous presence of adverbs that will modify the action of verbs, that is of functions or operators. There will be improved function prototyping along with facilities for passing in truely named variables, optional ones, etc. This includes the ability of defining for example new binary operators (i.e. "simply" functions which accept a parameter on the left and one on the right), but also circumfix ones like parentheses that act on what's between them, and all sort of things like these. There won't be regexen any more... there will be rules, powerful enough to e.g. parse XML natively. But even more complex languages: in fact, just like in some sense classes group methods, a new concept will be introduced, that of a grammar such that grammars will group rules (incidentally this will be more than a passing similarity, they say) and there will be at least one predefined grammar: Perl6's one. So that modifying suitably that grammar you can modify the parser at compile time. Some people see evident risks in so much freedom. In the sense of the paragraph above "Nothing but perl can parse Perl" will be promoted to "Nothing but Perl can parse Perl". Another desirable feature will be given by the fact that there won't be two orthogonal variable systems anymore: lexical variables will "simply" be variables in the magic MY package. Personally I'd like this feature to leak into some major release of Perl5... What else? Well, lazy list evaluation, hyperoperators, traits, roles etc. Well, these were only a few randomly chosen topics anyway... What i also like to know if there is a mod_perl6 coming up etc. etc.Huh?!? You bet there will be, but it seems to me the least thing one should care about. Perl already is a full-fledged programming language and this won't change with Perl6. Indeed (too) many people think of Perl as of a web authoring tool, but notwithstanding the fact that it is actually well suited for it and it has a long tradition in this sense (IMHO with too many bad side-effects) it is quite limitative to think of it only in these terms. In reply to Re: perl5 vs perl6
by blazar
|
|