Perl 5.10, 20 Year Anniversary

alfcateat writes "Perl 1 was released to the public by Larry Wall 20 years ago yesterday. To celebrate, Perl5Porters have released Perl5.10, the latest stable version of Perl 5. Happy Birthday Perl! Perl 5.10 isn't just a bug fix version: it's full of new features that I'm eager to use: named captures in regular expressions, state variables for subroutines, the defined-or operator, a switch statement (called given-when, though), a faster regex engine, and more. You can read more about the changes in perldelta."

Comments

Hmmmmmm

[Billosaur]

I was right... we hit double-digits with Perl 5 before Perl 6 became available... and don't go on about Parrot -- it's not Perl 6. I'll be interested to download 5.10 and see what it can do. The speedier regex engine is going to be a great boon.

Re:Hmmmmmm

[fbjon]

The speedier regex engine is going to be a great boon. Not to mention the named captures. Finally, no more empty capture vars because some parentheses were removed in the middle of the expression!

Re:Hmmmmmm

[Tony Hoyle]

I always though of Parrot as of a project that was born dead.

You *know* what kind of responses you are asking for when you write something like that don't you....

Re:Hmmmmmm

[Ed Avis]

I think the Perl hackers want something to run Perl 6 on, and the existing perl5 interpreter isn't up to the job (it is fast and well-tested, but the internals are somewhat kludgy). So they need to write a VM. The idea of running Perl, Tcl, Python and others on the same VM is a good one, it would be nice if the world could live together in harmony and all work on the same underlying interpreter, but I don't think the Python or Tcl maintainers will be interested. Which is a shame.

Re:Hmmmmmm

[doti]

I always though of Parrot as of a project that was born dead. It's not dead, it's resting.

Re:Hmmmmmm

[metallic]

I understand, that writing a VM can be fun, but I'm just wondering, are there any other reasons for working on this project? What merits it has?

The reason you want a VM is for performance reasons. If you take a look at a high-performance VM like Java's HotSpot VM, it can actually do code analysis while the program is running and then do optimizations on the fly. YARV, which is being developed by the Ruby team, will give Ruby somewhere around a 3x performance increase. I expect to see continued performance increases as they improve YARV.

Also, Parrot isn't intended just for Perl. It's goal is to be a general VM that any language can run on. So if someone writes a compiler for Python, that language will gain any performance improvements that Parrot can offer.

Re:Hmmmmmm

[tha_mink]

I always though of Parrot as of a project that was born dead.

It's not dead, it's resting. the norwigian blue prefers kippin' on its back. its a beautiful bird....loverly plumage

Re:Hmmmmmm

[$RANDOMLUSER]

It's not dead, it's resting.

I bloody well know a dead parrot when I see one!

Re:Hmmmmmm

[ricegf]

are there any other reasons for working on this project?

If Parrot becomes "efficient enough", then hosting Perl, Python and Ruby on Parrot should permit writing programs in a mixture of all three. Python has a very extensive library, but I certainly wouldn't mind having all of CPAN for which to choose as well - or access to Rails, for that matter. (Yes, I know, much of Rails' value is in its elegant fit to Ruby syntax, but I'd still like access from Python. Call me a library pack rat. :-)

For another example of recent interest to me, Perl and Ruby have excellent integrations with GraphicsMagick; Python has Python Image Library (PIL) instead. Why can't I choose the graphics library I want from any of the big three dynamic languages?

Nor would Parrot implementations of those languages need to replace the main implementations to be useful. The JVM has Jython and JRuby, granting access to Java libraries like Swing. Similarly, Microsoft's .NET has IronPython and IronRuby to avoid the much-maligned VB6. Interoperable implementations of Perl 6, Python 3, and Ruby 2 on Parrot would be very nice indeed.

Well, for a dynamic language junkie like me, at least. ;-)

Re:Hmmmmmm

[chromatic]

what is in it for me? Why should I care?

Having access to the CPAN from other languages would be useful (Ruby programmers take note). I want Pygame and Pyglet available to Perl 6 as well.

If I'm PHP, why should I compile to PIR?

Library support, primarily. mod_php is well-understood and widely deployed. However, it's possible that the Parrot security model may make mod_parrot more appealing to deploy than mod_php.

What is the fundamental "unit" of a library/application compiled in PIR. In .NET you deal in assemblies. In PIR, what do you deal in?

There's no real formal name, but a PBC file is as close as you get. It's just a bunch of bytecode. As yet we haven't decided on any formal interface that it needs to support.

Where is the boundary between something written in PHP and something in Perl? Is it a function? A class? A module?

It can be any of those. For example, my little Scheme-like language has self-hosted tests. They use a testing library I wrote in PIR. The testing library provides a series of multimethods that my language can call as if they were native functions -- and my language doesn't support multi-dispatch!

How does PIR handle the clash between objects and classes? Can I pass a blessed object created in perl to my PHP app?

Yes. The semantics of how that object will behave depends on its class, but as long as PHP on Parrot and Perl on Parrot use Parrot's calling conventions and its PMC interfaces for things like calling methods and creating objects, each language can have its own special semantics and can use objects defined in other languages.

What about namespace issues and how does PIR reconcile against language that have piss poor namespace support like PHP?

Each high-level language has its own top-level namespace. I imagine that the PHP implementation just lobs some three-thousand functions into that namespace, where Perl 6 stores things differently.

What about all the cool hashtable/hashref stuff that perl has? How will that work on something like PHP?

Data structures created in Perl and passed into PHP will have Perl semantics for all equivalent operations performed in PHP. If PHP supports a keyed lookup operation, Parrot will perform that operation on the data structure. How that structure's underlying object handles keyed lookup is up to the object, and it'll have Perl semantics.

What about inheritance? Can I derive a class in perl from a class written in Ruby?

Yes. (I don't know how well that works right now; I don't know if anyone has specifically tried it.)

What about debugging? If something chokes in my PHP library, will parrot let me see the PHP symbol table AND my python symbol table?

As long as the debugger knows about Parrot, it should.

How will any of this be useful without a very smart IDE? It is hard enough to keep track of large applications written in Perl because of the lacking tool support. If I'm calling a function/assembly written in PHP, am I now going to have to hop between to languages to figure it all out?

Reconstructing a language from PBC is non-trivial, but one of the goals of Parrot (and Perl 6) is to encourage better tool support by making it easier to plug an editor into the VM somehow. The answer is "it depends".

What is the baseline "your language needs to support XYZ before it works in PIR"? Or is this thing so low, the only thing I can bank on is a string? Does it define, for example, how and when a string might get cast as an integer

Switch statements are syntactic sugar

[morgan_greywolf]

Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing. There are also other constructs that you can use to get around the whole nested if/then/else thing too in many cases.

Re:Switch statements are syntactic sugar

[mccalli]

Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing.

Yeah, and who needs if statements anyway, or a high-level language come to that? Just syntactic sugar, I say we go back to sector-editing ones and zeros directly to the disk. Readability? Pah.

Cheers,
Ian

Re:Switch statements are syntactic sugar

[SamP2]

"Perl" and "readability" don't fit in the same sentence to begin with. :)

Re:Switch statements are syntactic sugar

[mccalli]

"Perl" and "readability" don't fit in the same sentence to begin with. :)

Lean on your keyboard for long enough, and you will eventually have produced a valid Perl script. Of course you won't know what it actually does, but then how does that differ from 90% of Perl scripts anyway?

Cheers,
Ian

Re:Switch statements are syntactic sugar

[chris_eineke]

Yeah, and who needs if statements anyway,

You wrote something accidentally insightful. Look at the following expression:
(if (> 3 2) 5 4)
which obviously evaluates to 5. But you know what? You can eliminate the if operator entirely if you let > (and any other predicate) return a two-ary function:
(define true (x y) (x))
(define false (x y) (y))
and stuff the arguments into separate functions for deferred evaluation:
((> 3 2) (lambda () 5) (lambda () 4))
:-)

Re:Switch statements are syntactic sugar

[ajs318]

At least Perl knows that adding numbers and concatenating string are different operations.

2 + 3 == 5 (Perl isn't that weird)
2 + "3" == 5 (not a TypeError as in Python)
"2" + 3 == 5 (not "23" as in JavaScript)
"2" + "3" == 5 (not "23" as in both JavaScript and Python)

Re:Switch statements are syntactic sugar

[mccalli]

>>Yeah, and who needs if statements anyway...
>You wrote something accidentally insightful. Look at the following expression:...

Away - away foul Lisp advocate, and darken not my doors again!

Cheers,
Ian
/tongue-in-cheek

Re:Switch statements are syntactic sugar

[beuges]

Switch statements are more efficient than nested if/then/else, at least in C/C++ (I dont use perl so I'm not sure if the same applies).

C/C++ only allows constants to be used as case values in a switch statement, you can't use a variable as a case label. This allows the compiler to optimise the comparisons based on the numerical value of each constant case label. Performing the case evaluations in different orders, using subtraction and addition and testing against zero can be more efficient than comparison to each value in turn.

So, a switch statement can be more efficient than nested if/then/else.

Re:Switch statements are syntactic sugar

[chicoryn]

Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing.

They do not! Not only do they increase readability of the code in many cases they do not even generate equivalent RTL. When you do a if-else if-else... you tell the compiler that it MUST check the first condition before the second, a subtle but important difference. What this means to the compiler is that an if-else if-else... must have O(n) complexity!

An switch statement on the other tell the compiler each item is independent of any other (and comparison is generally enforced as side-effect free). This means a switch statement can be converted to a binary-search or even a jump-table giving us a best-case complexity of O(1).

As you can see they are hardly equivalent but a really good compiler might be able to convert a if-else if-else... to a switch statement. But considering a switch statement is usually easier to read, write and understand in the first place why bother?

Re:Switch statements are syntactic sugar

[Fujisawa Sensei]

Not only do they increase readability of the code in many cases

Readability? You do realize this is Perl we're talking about?

Re:Switch statements are syntactic sugar

[Tony Hoyle]

While statemets? pah. setjmp and longjmp ftw.

Re:Switch statements are syntactic sugar

[SolitaryMan]

Well, most languages have a ternary operator ?:, which allows to get away without if in any situation. In Perl and Python you can do:

(CASE1 and STUFF_TODO) or (CASE2 and STUFF_TODO2) or ...

Where CASEx is boolean and STUFF_TODOx is some statement. It has to return true in order to halt the search though, so, in general case you have to go for something like

(CASE1 and (STUFF_TODO1 or 1)) or (CASE2 and (STUFF_TODO2 or 1)) or ...

As well as in your LISP example, this is ugly enough to be avoided whenever possible :)

Re:Switch statements are syntactic sugar

[Phroggy]

Hey now - those of us who write Perl code know exactly what our own code does, or at least we did when we wrote it. It's reading somebody else's code (or our own, years later) that's the tricky part. Perl is a lot of fun to write!

Re:Switch statements are syntactic sugar

[Chandon Seldon]

Lambda-calculus is in no way high level, it just doesn't happen to correspond to a machine model.

Re:Switch statements are syntactic sugar

[johannesg]

And how is ((> 3 2) (lambda () 5) (lambda () 4)) better than (if (> 3 2) 5 4), especially considering that you are apparently changing the meaning of true and false to something that is only extremely locally true? (disclaimer: ((lisp) ((not) (me)) () (speak))). This is a serious question, btw: is there really some advantage to doing this the difficult way?

And then I'm carelessly skipping over 3 > 2 ? 5 : 4, which is of course the *correct* solution ;-)

Re:Switch statements are syntactic sugar

[ajs318]

2<>"3"==type error in python and perl

Are you sure about that?

$ perl -e 'print 2 . "3", "\n"'
returns 23 on my system (perl, v5.8.8 built for x86_64-linux-gnu-thread-multi). Note you need a space before the dot, otherwise Perl gets its knickers in a twist because a dot looks like the fraction delimiter; but that's OK, because we don't have to strip out unnecessary spaces to make our code fit into the remaining 6KB of RAM (after allowing 20K for the framebuffer and 6K reserved for the system) anymore. And Python throws an error for "2" + 3. That's correct, strictly, but it goes against the Principle of Least Surprise (Perl gives you 5, which is both correct and Least Surprising. JavaScript gives you "23", which is neither correct nor in accordance with the Principle of Least Surprise).

Anyway, my point is that where there is an addition sign, there should be addition (and if a string has to be converted to a number, so be it; don't throw an error unless it's NaN. And provide a mechanism whereby NaN values can be silently treated as zero).

Is this the version

[$RANDOMLUSER]

that has the ORELSE operator?

Re:Is this the version

[supersnail]

If you are going to implement "COME FROM" can we have "ALTER GO TO" back please.

For the younger among you this was a fiendish COBOL construct which altered the
target of a plain "go to" somewhere else in the program. A wonderful tool
for sadists whith a particular dislike of maintenance programers.

Re:Is this the version

[Chysn]

> that has the ORELSE operator?

        This is Perl we're talking about here. It would be "orels"

Re:Is this the version

[vagabond_gr]

This is Perl we're talking about here. It would be "orels". Or whatever you set the $=] variable to.

Oh dear.

[Xargle]

"say() is a new built-in, only available when use feature 'say' is in effect, that is similar to print(), but that implicitly appends a newline to the printed string".

*sigh* Nice to see they're still adding to the elegance of the language :(

I wonder if threading actually works in production yet?

Re:Oh dear.

[macshit]

"say() is a new built-in ... similar to print(), but that implicitly appends a newline ..."
*sigh* Nice to see they're still adding to the elegance of the language :(

Not to mention the new "lol()" built-in, which is like say(), but also removes random letters from the string, and appends 17 exclamation points.

Sometimes I wonder about Larry Wall.

Re:Oh dear.

[Speare]

Not to mention the new "lol()" built-in, which is like say(), but also removes random letters from the string, and appends 17 exclamation points. Better than the first draft of lol() which replaced letters from the string with l33t equivalents. They found it was a security risk because people could just inject eval { lol($_) } and it was valid Perl code to cause a kernel panic.

Re:Oh dear.

[funaho]

So Perl is getting kinky. You can tell it to "say my $name" now. :)

Re:Aren't these two unrelated events?

[supersnail]

Get real -- this is perl we are talking about.

A programming language used for poetry.

A programming language where "bless" is a basic operation.

A programming language which borrows the "understood" syntax from English.

A programming language where all published examples contain variables "Foo" and "Bar".

Of course they are going publish a new release on the twentieth anniversary. I dont think it occurred to anyone in the perl community not to.

recursive patterns

[hey]

The new recursive patterns should increase perl's readability.

Re:recursive patterns

[Kostya]

What? No mod +funny yet? Come on people!

Yeah, I saw recursive patterns and thought, "Crap, now I'm going to have to relearn how to look at regexes so that I see those too." Still, I'm excited about the power (while being daunted by the readability).

Much Thanks to Mr. Wall

[BodhiCat]

Much thanks to Mr. Wall for creating a fast and dirty lannguage. The Oscar Madison of programming languages, much easier to learn and use than Java, the script equivilent of Felix Unger. Perl has been great for small cgi web things, not a lot of fuss and bother. Wouldn't use it for anything over a few hundred lines, tho, too easy for variable to get confused, even when using strict. Now if I can just get the DBI to MySQL on OS 10.5 to work my life would be perfect.

Re:Much Thanks to Mr. Wall

[Goaway]

Uh, with Perl being one of the few scripting languages out there that even have something like use strict, I'd say it's one of the least likely ones to confuse variables in.

Re:Much Thanks to Mr. Wall

[mr_mischief]

It's more expressive in that it takes less syntax to achieve the same result than most other languages. I think that's a fairly common definition. Python and Ruby have the advantage of coming after Perl, and Ruby is actually the designer's idea of re-imagining Perl to be more regular and better at OO. They are more expressive than many other languages, too. C and C++ are not nearly as expressive as Perl. They can express the same programs, but it takes much more syntax to do so.

The flexibility isn't just CPAN, although that's a good thing. It's in the ability to express the same program in more than one way, too. That flies in the face of orthogonality, but orthogonality is a means and not an end. In Perl one can write a functional program, a procedural program, an OO program, or a largely declarative program. One can even use an OO module in a procedural program or a procedural module in an OO program with little hassle.

Perl has bindings into OpenGL, SDL, Qt, GTK, Tk, WxWidgets, and Motif. That is doesn't have a standard GUI binding is kind of sad, but it has lots of bindings from which to choose.

The language being more flexible and the end product of a program written in the language being more flexible are two very different things. A program written in Perl can be very rigid and inflexible, while a program written in RPG could be, at great difficulty to the programmer, fairly flexible. The difference is that Perl makes it easy to make the program you're writing either rigid or flexible.

While it's true that any Turing-complete language can in theory produce the same program as any other Turing-complete language, you've got to be kidding if you think 70 lines of COBOL vs. 10 lines of C vs. 3 lines of Perl means they're all equally expressive. Expressibility and expressiveness are not the same thing.

Re:Happy Anniversary!

[ekimminau]

And don't forget my favorite Perl export here.

Implicit vs. explicit parsing

[SamP2]

2 + "3" == 5 (not a TypeError as in Python)
"2" + 3 == 5 (not "23" as in JavaScript)

And this is intuitive, useful, or best practice, how exactly?

Implicit parsing a num to a string is straightforward and will pretty much always work, even if you may get wierd results like "1.66666666666666666667". But the other way is just too careless to let be implicitly done. You may unexpected errors when for some reason the string you use cannot be parsed, and you may get either an unexpected datatype or a truncated result when a parsed string would not match the other num you add to it (such as int a = x+5 where x is a string "3.5").

Casting from string to number should always be done explicitly, with precise definition of the data type you cast to, and ideally with an error catching block in case something goes wrong. Letting it be done implicitly is a recipe for headache.

Re:Implicit vs. explicit parsing

[ajs318]

Casting from string to number should always be done explicitly, with precise definition of the data type you cast to, and ideally with an error catching block in case something goes wrong. Letting it be done implicitly is a recipe for headache.

Let me guess: You like Pascal. The language that, if it was a car, would have only one pedal and two forward gears.

I program in high-level languages precisely because I don't want to have to think about whether something is a string or a number. I have bought and paid for, with my own money, earned by effort of hand or brain, enough RAM, disk space and CPU cycles to afford myself that little luxury. I grew up with 1980s 8-bit machines, learned to use instructions as numeric constants, when to bit-pack and when not to (the extra unpacking code can negate the saving), and all the other ways you can shave a byte off here or there (even putting code in the framebuffer and hiding it by palette-switching mid-frame). Now the computer is smart enough to take care of all that trivial crap, leaving me to sweat the big stuff.

Bold perl hackers, I salute you

[anilg]

With 'given-when', you have broken into lands no other languages dared. I now await the addition of 'conclude-basedon' and 'eithernot-ifonly' to complete the glory that is perl.

Re:what the FUD

[mr_mischief]

The Python community doesn't have to adopt it. There's a considerable overlap of community members among Perl, Python, Ruby, Scheme, Haskell, and other languages. So long as Pirate keeps close enough to the official Python stuff, people who want to use Python and Perl together will be able to put their Python code into a project using Pirate instead of Jython or whatever.