What Is Perl 6
by chromatic
|
Pages: 1, 2, 3
Better Object Orientation
The de facto OO technique in Perl 5 is blessing a hash and accessing the hash's members directly as attributes. This is quick and easy, but it has encapsulation, substitutability, and namespace clashing problems. Those problems all have solutions: witness several competing CPAN modules that solve them.
Perl 6 instead provides opaque objects by default, with language support for creating classes and instances and declaring class and instance attributes. It also provides multiple ways to customize class and object behavior, from instantiation to destruction. Where 95 percent of objects can happily use the defaults, the 5 percent customized classes will still work with the rest of the world.
Another compelling feature is language support for roles--this is a different way of describing and encapsulating specific behavior for objects apart from inheritance or mixins. In brief, a role encapsulates behavior that multiple classes can perform, so that a function or method signature can expect an object that does a role, rather than an object that inherits from a particular abstract base class. This has powerful effects on polymorphism and genericity. Having role support in the language and the core library will make large object-oriented systems easier to write and to maintain.
Improved Consistency
Sigils, the funny little markers at the start of variables, are invariant.
Return codes make sense, especially in exceptional cases.
Similar things look similar. Different things look different. Weird things look weird.
All blocks are closures; all closures are first-class data structures on which you can set or query properties, for example.
Rules and Grammars
One of Perl 5's most useful features is integrated regular expression support--except they're not all that regular anymore. Nearly every problem Perl 5 has in the whole (inconsistency, wrong shortcuts, difficult reusability, inflexible and impenetrable internals) shows up in the syntax and implementation of regular expressions.
Perl 6 simplifies regular expressions while adding more power, producing rules. You can reuse and combine rules to produce a grammar. If you apply a grammar to text (or, perhaps, any type of input including a recursive data structure), you receive a match tree.
That sounds quite a bit like what a parser and lexer do--so there's little surprise that Perl 6 has its own locally overridable grammar that allows you to make your own syntax changes and redefine the language when you really need to. Perl 5 supported a similar feature (source filters), but it was fragile, hard to use, and even harder to re-use in serious programs.
By making a clean break from regular expressions, the designers had the opportunity to re-examine the regex syntax. The new syntax is more consistent, so it's easier to type and to remember the syntaxes of common operations. There's also more consistency, so that similar features look similar.
Perl 6 has a Perl 5 compatibility layer, if you prefer quick and dirty and familiar--but give the new syntax a try, especially for projects where quick and dirty regular expressions were intractable (more than usual, anyway).
Where is it Already?
Larry announced the Perl 6 project at OSCON in 2000. Why is it taking so long? There are several reasons.
First, Perl 5 isn't going anywhere. If anything, the rate of patches and changes to the code has increased. Cleanups from Ponie and the Phalanx project continue to improve the design and implementation, and new features from Perl 6 are making their way into Perl 5.
Second, the opportunity to do the right thing without fear of breaking
backwards compatibility opened up a lot of possibilities for impressive new
features. Reinventing regular expressions as rules and grammars, for example,
would have been difficult while retaining the flavor and syntax of
awk and Henry Spencer's original implementations. The new power
and consistency makes rules well worth the reinvention.
Third, the project is still a volunteer project. Though other languages and platforms have major corporate support, only a handful of Perl 6 hackers receive any form of funding to work on the project--and none of them on a full-time basis.
If you want to write actual, working Perl 6 code, it's possible. Pugs has been able to run quite a bit of the language since last summer. It will soon connect directly to Parrot again. When that happens, watch out!
Learning More
This article is merely an overview of some of the reasons for and features of Perl 6. There are plenty of details available online in writings of the designers, the mailing lists, and the source code repositories.
Design Documents
The Perl 6 home page holds links to most of the design documents for the language. In particular, Larry's Perl 6 Apocalypses explore a subject area in depth, identifying the problem and outlining his thinking about what the solution might be. Damian Conway's Perl 6 Exegeses expand upon the idea, showing concrete examples written in actual Perl 6 code.
In the past several months, the design team has started to update the Perl 6 Synopses instead. Perl 6 pumpking Patrick Michaud keeps these fresh with the current design. The Apocalypses and Exegeses remain online as interesting historical documents that take too long to write and revise as changes occur.
Implementations
Parrot has monthly releases. The Parrot distribution includes the Parrot Grammar Engine (PGE), which is Patrick's implementation of rules and grammars, as well as several languages that target Parrot. The most complete implementation is for Tcl, though the Punie project (Perl 1 on Parrot) shows the entire suite of compiler tools.
Audrey (nee Autrijus) Tang's Pugs is an unofficial Perl 6 implementation, optimized for fun. As of the time of the writing, it supported much of Perl 6, including junctions, multimethods, and objects. It targets multiple back-ends, including Haskell, JavaScript, Perl 5, and Parrot, and moves very quickly. Pugs is a great project in which to participate--it's very easy to get a committer bit and start writing tests and fixing bugs. It's currently the main prototype and reference implementation. Time will tell what its role is in the final release.
Ponie is a port of Perl 5 to Parrot. It's a huge refactoring project with little glory but a lot of potential usefulness. C hackers are more than welcome.
Discussion
Most development discussion takes place on several Perl 6 mailing lists:
- discusses Perl 6, the language and features.
- discusses the design and implementation of Parrot and various languages targeting Parrot.
- discusses PGE, Pugs, and the interaction of various components of the compiler tools.
The #perl6 IRC channel on irc.freenode.net talks about Pugs and Perl 6, while #parrot on irc.perl.org concentrates on Parrot. There is almost always someone around in #perl6 to answer questions about Pugs or Perl 6.
Planet Perl Six aggregates weblogs from several designers and developers of various related projects.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 35 of 35.
- Compiled Perl
2007-01-16 18:46:10 sefnet [Reply]
Larry Wall and Perl 6 Developers,
I understand that Perl 6 won't have the ability to produce compiled code. If true I think this is a mistake. The old Perl was an awesome development language. But a major prob was the ability to reliably produce executables. This would be a major advantage over competing languages. It also sounds as like you are eliminating features for the sake of academic conformity. For shame! Stick with your original instincts. That's what made Perl great. Features that add usefulness to the language should be kept and expanded upon eg: yes, regular expressions! Forget the academic code snobs and the java snipers. They wouldn't be looking at this site if they were satisfied. End of rant.- Compiled Perl
2007-05-18 13:17:31 fusfus [Reply]
Compilation is a thing of the past. Nowadays you want to write cross-platform applications, so what you need is a virtual machine and object code for it. Consider JAVA vs Perl; JAVA runs on a handful of platforms, while perl runs on 70+ platforms, so you are better off with Perl+encryption+packaging.
- Compiled Perl
2007-01-16 19:01:56 chromatic1 [Reply]
As far as I know, an optional compilation phase is still part of the plan. It's a feature of the Parrot implementation, at least.
- Compiled Perl
- GUI Presentation
2006-10-17 08:49:26 dgui [Reply]
IF Perl would fix their GUI presentation (launch problem), I might switch over to using Perl instead of TclTk.
Problem: double clicking on a Perl icon, with a windows operating system, results in the old black Command Prompt window for a split second before launching the real program. I understand that Perl uses a command line interpreter for this function and maybe that's why?
Comments welcome...- GUI Presentation
2006-10-20 15:36:40 chromatic1 [Reply]
Hm, I think that you can use wperl.exe instead of perl.exe to suppress the command-line on Win32. I don't use Windows, so I don't know for sure, but I'm pretty sure ActiveState has a FAQ on this. I also think it's a feature of Windows, not Perl, but see the disclaimer in the previous sentence.
- GUI Presentation
- Perl needs a concise BNF grammar
2006-09-18 09:58:00 longtime_programmer [Reply]
Although it's too late for Perl 5, I hope that Perl 6 is defined by a *concise, formal (BNF) grammar*. This would REALLY make it easier for programmers to learn and remember and for the implementers of Perl 6 to anticipate the consequences of language "features". It would also allow for more efficient language parsing. There is no downside to it.
Also, I hope they take some of the "magical" Perl language behavior and toss it out. Really, I don't need to guess what my program is actually going to do. I'd much rather have it do what I tell it (and no more) than for it to try to do me any "favors". I don't care for that in operating systems and I don't care for it in programming languages.
Lastly, I wonder if the lesson has been learned that a "growable" language puts a lot of functionality in standard libraries rather than baking it into the language itself. You can always replace a library... you can't replace the language syntax.
Has this been done?
- Why Perl5 has lost the lead
2006-05-11 09:29:13 KeeHinckley [Reply]
"Too much recently has Perl been backburnered because the world focusses its attention on shiny new languages like Python and Ruby. This is where Perl takes back the lead."
Some of the lead-loss has been due to ease-of-use and lack of simplicity (e.g. to PHP) and some to lack of features (easy API integration). But I think the main danger to Perl is a lack of solid development environments for specific types of tasks. CPAN is fantastic for pulling pieces together. But once you have an integrated system, where do you put it? RubyOnRails isn't popular because of Ruby features, it's because of what the overall system provides. I'm a huge fan of Embperl--but it's basically a one-person project. We need some concerted group projects to make real-world packages that make it easy for real people.
Perl is the Emacs of programming languages for large scale development. Too hard for the beginner, and by the time you've put the effort into figuring it out, you no longer care about making it easier for those who follow on.- Why Perl5 has lost the lead
2007-05-18 13:23:09 fusfus [Reply]
Too hard for the beginner? I remember I had easy life with it, and the perldocs and cpan are a major boost to productivity. JAVA, by comparison, is a shoot on one's foot.
- Why Perl5 has lost the lead
- It's a new language
2006-01-30 07:11:05 peterscott [Reply]
To those people annoyed over some backwards incompatible change from Perl 5 to Perl 6, I would say: Think of it as a new language. It just has "Perl" in the title because it has so much in common with Perl 5, but don't take that to imply some sort of promise of compatibility. Most of the Perl 5 syntax was frozen 18 years ago; Larry's entitled to new thoughts based on what he's learned since then, and lucky we are that he creates a language for us from them.
You can always keep using Perl 5 if you want, I'm sure it will be flourishing for decades. But its star will never again ascend as far and as bright as Perl 6's is about to. I find the changes and the new learning more than compensated for by the exciting new features and ease of use. Too much recently has Perl been backburnered because the world focusses its attention on shiny new languages like Python and Ruby. This is where Perl takes back the lead.
- Perl is a mess
2006-01-17 03:15:20 NotAProperLanguage [Reply]
Perl 5 will always be a nasty mess. I guess forking the language is one solution, but since Perl6 really badly breaks backwards compatibility, why not just abdandon the whole doomed enterprise and move to a language that started out with a sensible design? Python, Ruby or Groovy will do the job if you want something quick and/or dirty. For large scale projects, Java is your friend.- Perl is a mess
2007-05-18 13:09:37 fusfus [Reply]
JAVA is a mess. A certified JAVA programmer takes two weeks to do what I do in four hours with Perl.
- Perl is a mess
2006-01-17 12:29:09 Dawson [Reply]
No one will make me think that Java is my friend. I work in a Java shop as a PHP/Perl guy. I've seen their JAR files and CVS repositories. Poor Sam upgraded his server version and now his JDBC calls don't work. He's trying to edit XML files to fix it. I install Perl, download modules from CPAN, save changes and run. No CLASSPATH and no compiling. Java is in no way a perfect language.
Now, I'm not the type of guy that things Perl is the end-all of programming languages. And, I would like to learn Java. I use ASP, PHP, Javascript, Perl or whatever is the right tool for the job.
Only a Java zealot would say "get rid of Perl"...- Perl is a mess
2006-01-18 08:15:38 EightBit [Reply]
I completely disagree with you. I was a Perl guy that made the switch to Java, and I don't regret it one bit. If you're having problems with classpaths, you're using the wrong tools. Yes, you might argue that you shouldn't need an IDE to get your job done.. hey! it's 2006 not 1970! Perl, for me, has gone from being the workshop to nice pocket knife (a leatherman maybe).
I'm interested to see what happens with this Perl 6 beast, but for now, I'm tired of waiting. I was at OSCON in 2000 and heard Larry's speech with great excitement.
Yes, I also work with PHP on a daily basis and really don't care for it much either, though I can understand why our web developers love it.- Perl is a mess
2006-05-20 21:17:06 geber22 [Reply]
Java always has to promote itself, unlike Perl which has simply been developed, used, and loved by programmers all over the world. Java initially became popular due to applets, which at the time were great, but are they really necessary? Then the big thing with Java was EJB, RMI, Enterprise wide ... Taking a regular application and developing it within an enterprise framework doesn't make it an enterprise application. (Repeat that 3 times)
How about implicit getters and setters? Not, but feel free to auto generate those getThis, setThis,... Remember that movie the matrix where everything was a program; Can you imagine writing all those getters/setters?
Have a look at the Spring framework, it's the next big thing in Java. It's got such huge holes in it that redirects are a common work around?
I've always like the practicality of perl, it's honest, the perl community is honest, god bless it. (No I didn't just make it an object) I wish I could say the same thing about Java, and it's enterprise marketing schemes.
- Perl is a mess
- Perl is a mess
- Perl is a mess
2006-01-17 11:00:18 chromatic1 [Reply]
If I use Parrot, I can migrate my existing Perl 5 code to Perl 6 in small pieces or leave it as it is and interoperate with Perl 6 code. If I migrate to another language that doesn't run on Parrot, I have to abandon all of my existing code.
I'll take door #1.
- Perl is a mess
- List of mailing lists?
2006-01-13 09:51:56 aufrank [Reply]
chromatic--
I think in the discussion section of page 3, where you list the three p6 mailing lists, you've left off the names of the respective lists. Each bullet starts with "discusses"-- I imagine you wanted something like "perl6-language discusses..." rather than just "discusses..."
Great article, fun to read!
Thanks,
/au- List of mailing lists?
2006-01-13 11:04:44 chromatic1 [Reply]
The mailing list names appear for me. Do you have a setting in your browser that hides mailto: links? (We use JavaScript to obfuscate e-mail addresses; that may be it.)- List of mailing lists?
2006-09-21 04:13:31 spinclad [Reply]
I see from the page source that, with javascript turned off (I only turn it on when I know I need it, as a matter of personal policy), no mailing-list name is given. IMHO giving a noscript clause with at least the list name (as link or not) would be a better publisher's policy.
- List of mailing lists?
- List of mailing lists?
- pet peeve: why change -> to .
2006-01-12 21:50:39 dougseay [Reply]
Chromatic,
you seem to like this change. What is it really buying us? The . has been for the concatination of strings since day 1, or at least since I started using perl 4. Giving it up to so method calls don't need two characters with three whole key presses to get that shift just does not seem worth it. I learned with . but I've been using -> for a decade and I kinda like it. It makes the call more visible, which is goodness.
I know that I can whine until the cows come home, but that won't change anything. I just want to understand "why".
- doug- pet peeve: why change -> to .
2006-01-17 19:25:00 zeveck [Reply]
Personally, I find ~ very unnatural as a string concatenation operator. In addition, I tend to prefer -> for method calls because it makes the call more explicit and apparent.
Making this change just to save a few keystrokes isn't such a good idea.
- pet peeve: why change -> to .
2006-01-12 22:05:17 chromatic1 [Reply]
Primarily, it's a lot shorter -- and that's very nice for such a common operator. With method access on builtins becoming more common, it's nice to be able to type less.
Aesthetically, it's one point of commonality with many other popular languages that do OO. It's also a nice visual break between two separate things (invocant and method name) but not too distracting, as two punctuation symbols in the middle of the line are.
I do understand what you mean about string concatenation. Fortunately, moving to the ~ operator affords better consistency with other operators; there are a handful of other uses for the dot in Perl 5 that just weren't consistent. If you ever look in the parser (not that I recommend it), you'll see how many weird special cases there are.
The dot is pretty convenient for concatenation, but with better string interpolation I don't miss it too much. ~ isn't much more difficult, and . feels pretty good for method calls.- pet peeve: why change -> to .
2006-01-16 23:51:27 dougseay [Reply]
Saving a single character worth of typing is not reason for breaking a time honored convention. Nobody is that lazy. And I still don't care what other languages do. If they all jumped off a bridge ....
I do agree that with good string interpolation, the need for concatination drops off. The two reasons I use . instead of interpolation today are for method calls and constants. As it looks like both of them are going to churn with p6, maybe the landscape will be different enough that . won't be needed.
- doug- pet peeve: why change -> to .
2006-01-17 00:02:13 chromatic1 [Reply]
Just because a poorly optimized feature is old doesn't mean the backwards compatibility recycling monster won't eat it!
Maybe all of those other languages Huffmanized the operator correctly and Perl 5 did it wrong. (Maybe lifting it from C and C++, if that's where it came from, was the wrong idea.)
You can still write a macro to get the arrow back, though.
- pet peeve: why change -> to .
- pet peeve: why change -> to .
- pet peeve: why change -> to .
- Hash overloads?
2006-01-12 19:24:38 ChrisDolan [Reply]
On Page 2, chromatic says that Perl 5 overloaded hashes in six ways. I have come up with only five. What's the sixth?
1) Blocks - "sub { ... }" or "map { ... } ..."
2) Hash lookup - "$foo{bar}" or "$foo->{bar}"
3) Anonymous hashes - "$foo = {bar => 1}"
4) Hash slices - "print @foo{'bar','baz'}"
5) Dereferencing - "@{$array_ref}" or "%{$hash_ref}" etc
6) ???
-- Chris Dolan- Hash overloads?
2006-01-12 21:46:45 autarch [Reply]
Well, I'd consider 1 and 5 basically the same (hash key lookup), but here's another ...
"\x{1234}"
for expressing Unicode characters via hex numbers in strings.
- Hash overloads?
2006-01-12 21:40:31 dougseay [Reply]
Variable delimiters in strings is the only thing I can think of. "${foo}bar" is not the same as "$foobar"
- Hash overloads?
2006-01-12 20:03:20 chromatic1 [Reply]
#6 is variable name disambiguation -- "${name}_string".- Hash overloads?
2006-01-12 20:34:37 MichaelCartmell [Reply]
and in regular expressions they are used to delimit quantifiers for example /\d{2,4}/ matches 2 to 4 digits.
- Hash overloads?
- Hash overloads?
- Nice explanation (and minor correction)
2006-01-12 18:47:23 pmccann [Reply]
Thanks very much for the overview; the perl 6 project makes a whole lot more sense when embedded in the larger context you provide.
(I think "Harry" should be "Henry" Spencer.)
Cheers,
Paul- Nice explanation (and minor correction)
2006-02-16 10:38:11 laodaye [Reply]
Perl 6 has been in design for more than 6 years, but it still doesn't come out. When it is finally released, few people will be interested in it.
- Corrected!
2006-01-12 20:02:36 chromatic1 [Reply]
Thanks; I've corrected the article now.- Corrected!
2006-01-13 13:18:07 matijapapec [Reply]
Shouldn't be there Autrijus Tang instead of Audrey Tang? ;)
- Corrected!
2006-01-13 13:26:32 chromatic1 [Reply]
Actually, Audrey recently underwent a name change.- * Tang
2006-01-16 22:23:17 perlpilot [Reply]
In order to avoid confusion, it might be best to write something like "Audrey (nee Autrijus) Tang" so that people can more easily make the correspondence.
- Corrected!
2006-01-13 15:41:40 matijapapec [Reply]
Didn't know that; tnx for the info.
I'm looking forward for your next perl article.
- * Tang
- Corrected!
- Corrected!
- Nice explanation (and minor correction)



