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

[SolitaryMan]

and don't go on about Parrot

I always though of Parrot as of a project that was born dead. What niche is it going to fit in, anyway? The same javish "write-once-support-anywhere" thing? Well, Java is doing pretty OK there: it has a pretty good market in small apps and games for cellphones, but I really doubt, that Parrot can make any difference there.

Large projects are usually targeted at some specific environment and nobody cares about OS independence, since OS is cheaper anyway.

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?

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

[Anonymous Coward]

"So if someone writes a compiler for Python, that language will gain any performance improvements that Parrot can offer."
But Python already has a working JIT with psyco, and a project with even greater goal than just yet another VM with PyPy. And PyPy unlike Parrot, is not vaporware and received funds from the European Union from 2004 to 2006.

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

[SolitaryMan]

It's not dead, it's resting.

I only now realized that there was a pun in my post :)

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

[davegaramond]

and don't go on about Parrot -- it's not Perl 6.

Perl 6 is a language specification, remember? It's no longer a single implementation. Anything that passes the Perl 6 suite will be Perl 6, be it Parrot, Pugs, ...

Anyway, we're seeing good progress recently with Parrot. We should be seeing a Perl 6.0.0 alpha "soon" ...

Re:Hmmmmmm

[smittyoneeach]

PyPy is a straight-up compiler, replacing CPython, is it not?
My understanding is that the value of Parrot is that you can mix and match code derived from any compiler that targets it. You could have some Python, some Perl, and some Scheme code (eventually) executing together.

Re:Hmmmmmm

[Dystopian Rebel]

Running scripting languages in a single VM is a cool idea. If I have to do practical extraction and reporting, it sure as hell isn't going to be in Java.

Knicker-twisting quibblers like to blame Perl for the fact that they need tabs to understand their own code. Perl is excellent for its purpose.

It is, however, ghastly for OOP.

Re:Hmmmmmm

[bytesex]

The above is a spamtroll who has reached new depths of depravity in his cunning to lead us onto his minicity website. Seriously dude - are you in it for the money or something ?

Re:Hmmmmmm

[Deanalator]

At my first software engineering job when I was in highschool, everyone on my team was hardcore into perl. My boss especially, since he regularly hung out with some of the perl oriley authors, and had written however dozen many of the cpan modules etc.

I remember how excited he was because perl 6 was going to be coming out "any day now". This was in 2001. I have been out of the loop for a while, but every time I do a linux install, I notice that perl hasn't hit 6 yet, and I find that slightly amusing.

Re:Hmmmmmm

[TheLink]

Will that be after or before Duke Nukem Forever is released? ;)

Re:Hmmmmmm

[Anonymous Coward]

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.

*Somewhat* kludgy?! Perl does not even have a spec - you can't even determine if your perl program (or perl interpreter) is "buggy" or not. I would ignore too if I was using/working on python/tcl and perl crowds knocks on my door.

Re:Hmmmmmm

[Billosaur]

Could someone please define "soon"?

Re:Hmmmmmm

[Anonymous Coward]

I was right... we hit double-digits with Perl 5 before Perl 6 became available

Also worthy of mention is that this .10 release is a development version and not a stable release, so as far as I'm concerned it might as well not even exist.

Re:Hmmmmmm

[X3J11]

Well 'e's... pining for the fjords.

Re:Hmmmmmm

[marklark]

Perl is sort of self-spec'd. There are many test suites that are used in the compilation. Modules are tested as they are built and installed from CPAN.

If you aren't able to tell when you're getting the wrong answers, perhaps you should: think of tests for your code; consider edge/extreme cases; consider pizza delivery...

Re:Hmmmmmm

[Anonymous Coward]

Kino deftly slipped his knife into the edge of the shell. Through the knife he could feel the muscle tighten hard. He worked the blade lever-wise and the closing muscle parted and the shell fell apart. The lip-like flesh writhed up and then subsided. Kino lifted the flesh, and there it lay, the great perl, perfect as the moon. It captured the light and refined it and gave it back in silver incandescence. It was as large as a sea-gull's egg. It was the greatest perl in the world.

Juana caught her breath and moaned a little. And to Kino the secret melody of the maybe perl broke clear and beautiful, rich and warm and lovely, glowing and gloating and triumphant. In the surface of the great perl he could see dream forms. He picked the perl from the dying flesh and held it in his palm, and he turned it over and saw that its curve was perfect. Juana came near to stare at it in his hand, and it was the hand he had smashed against the doctor's gate, and the torn flesh of the knuckles was turned grayish white by the sea water.

Instinctively Juana went to Coyotito where he lay on his father's blanket. She lifted the poultice of sea weed and looked at the shoulder.

"Kino," she cried shrilly.

He looked past his perl, and he saw that the swelling was going out of the baby's shoulder, the poison was receding from its body. Then Kino's fist closed over the perl and his emotion broke over him. He put back his head and howled. His eyes rolled up and he screamed and his body was rigid. The men in the other canoes looked up, startled, and then they dug their paddles into the sea and raced toward Kino's canoe.

Re:Hmmmmmm

[mr_mischief]

The specific niche for Parrot is as a VM for a register machine which works well with dynamic languages. Java is a very statically typed language, and the JVM is written to suit that (and I believe it's a stack machine, but don't quote me on that). Forth is a stack machine. CLR is a stack machine and mostly suited to statically typed languages.

Plus, Parrot and Perl6 aren't as tightly bound together as some may think. Perl6 runs on Pugs, which is written in Haskell. It's going to run on Parrot. It should also run on the JVM and CLR, but probably not as well as on Parrot. It may even run on top of Neko some day, as there's been talk of targeting that VM. It'll also be able to be compiled down to machine language, which is quite difficult to do with Perl5.

Parrot can be the target for more than Perl6. As Parrot is written and refined, several language implementations are being written and refined along with it as test cases. This helps iron out edge cases and corner cases, and helps drive the selection of features necessary to properly support those languages without a lot of extra fluff.

ABC, Tcl, brainfuck (called "bf"), a subset of Python, a subset of PHP, APL, a C compiler, Ruby, a subset of Common Lisp, a .Net to PIR translator, a couple of Scheme implementations, a Forth interpreter, Lua, Perl5, an Infocom ZMachine, and more are in different states of readiness at the moment. The goal is to standardize how to implement dynamic languages on Parrot and to standardize how to call into and out of languages on Parrot. Those will allow Perl6 and other languages to interact more cleanly than is possible with Perl5. Two languages implemented on Parrot will even be able to call subroutines written in each other.

ParrotCode has far more information about the Parrot project.

Re:Hmmmmmm

[Ed Avis]

I meant that the workings of the interpreter are kludgy, not the language itself. I agree that perl doesn't have a spec and so by definition, any bug report of perl's behaviour is invalid. (I've had a couple of bug reports dismissed as invalid, only to be fixed a couple of years later when the developers realized that "it's always been that way" is not a good justification for the way a program behaves.)

I don't think that applies to Parrot, which AFAIK is a pretty clean and general design. I'm just not optimistic that the Python community, Tcl community and so on will make the effort to use it. They are interested in their own languages and don't have time for grand unification projects.

Re:Hmmmmmm

[oldhack]

You are simply piling same faulty layers higher and higher on a landfill foundation.

There is presumption that I know what I am writing, and test is there to catch mistakes. With Perl, you don't actually know what you're writing (it is whatever the Perl interpreter determines it is), how are you to write test for it?

Say you are writing solid-state physics calculation that takes hours or days to complete. If I'm supposed to know the answer in advance for any arbitrary set of input, why bother running the code? How are you to verify a given implementation that is, in the end, a blackbox unless you dig into the underlying C implementation, which defeats whole point of using the high-level Perl?

Re:Hmmmmmm

[mr_mischief]

Larry has said that he went too simple for the object model in Perl5. It's different in Perl6.

You might want to check it out once there's something a little closer to the final Perl6 available. Right now, you can try it out but count on updating your kit quite often, as the language is still in quite a bit of flux. For those willing to live on that cutting edge, most of them prefer it to Perl5. They're mostly people who really liked Perl5 but wanted more Lisp, Prolog, Haskell, Ruby, Python, D, or Java niceties.

There's multiple dispatch in Perl6, optional static typing, a full grammar system instead of source filters, proper prototypes, a clearer idea of exceptions, a native switch statement (which there is in 5.10), and more. A large part of Perl6's default object system is available in Perl5 via the Moose packages on CPAN if anyone's interested.

One of the interesting things about Perl5's objects is that, like the language motto says, There's More Than One Way To Do It (often abbreviated TMTOWTDI or TIMTOWDI in the Perl community). There are half a dozen object systems for Perl5 as modules and it's quite possible to write even more. The Perl6 default object model is based on the strengths of some of the more popular Perl5 ones with nice touches from other languages. It'll still be possible to make an alternative object system for Perl6, but it'll probably be a lot more rare that someone does.

Re:Hmmmmmm

[rrhal]

Isn't one of Parrot's features a more efficient way of handling lists of arbitrary objects. I hope they get all this done in time to still be relavent.

Re:Hmmmmmm

[mr_mischief]

Perl has, since 5.6.0, followed the Linux-style numbering system. Anything with an even-numbered middle section is a stable release. The development branch leading to 5.10.0 was the 5.9.x branch.

Re:Hmmmmmm

[coryking]

It's goal is to be a general VM that any language can run on. Sorry. That has been done. See Mono, MSIL and .NET.

I love perl dearly, but if they think people are going to write language compilers on top of their VM stack, I've got a bridge to sell. The VM market will be locked up tigher than a nuns hoo-haa before perl pushes out anything to compete.

And who cares anyway? The reason MSIL is taking off is the rich API that .NET offers. What API is perl going to bring to the table that can compete with .NET? If you say CPAN, that is a good answer, but why am I going to write PHP on top of a CPAN module when I can just write perl on top?

Re:Hmmmmmm

[mr_mischief]

According to CPAN, 5.10.0 is a "release version", and 5.8.8 is still listed as the "stable version". This could be confusing, but generally a "release version" is stable, given the standard caveat about anything with a ".0" version. The 5.8.8 could still be considered "more stable", as a trusted version for conservative production environments.

Re:Hmmmmmm

[chromatic]

That has been done. See Mono, MSIL and .NET.

Built for static languages, controlled by Microsoft. Those properties make them less than universally useful.

Re:Hmmmmmm

[oldhack]

I realize that you're addressing the perl interpreter, not the language, but the same problem applies - difficult to implement something correctly if I don't know what that "something" precisely is. Parrot seems to address this sorta issue, as you noted, but then it will likely negate other features that made Perl popular in the first place (quick-and-dirty, it will probably do what you meant, etc.,), so not sure what the point of it is, other than that people work on whatever they work on for their own reasons.

Re:Hmmmmmm

[xfrosch]

> I don't think the Python or Tcl maintainers will be interested.

Oh, the Python people are interested all right, they've just settled on the JVM already.

Re:Hmmmmmm

[stu42j]

Before Christmas.

http://www.perl.com/pub/a/2002/09/p6pdigest/20020915.html?page=5

Re:Hmmmmmm

[stu42j]

Parrot is not vaporware. It just isn't finished yet. You can download the latest release from parrotcode.org.

Re:Hmmmmmm

[chromatic]

You could have some Python, some Perl, and some Scheme code (eventually) executing together.

Eventually? Today.

Re:Hmmmmmm

[BlackCreek]

he problem is that it isn't finished yet for what? 6 years already?

I remember reading that the parrot codebase was around 150.000 lines some years ago... so I reckon that there is a lot of real work that went in there. Still, it has been years, and who is going to run production code on an unfinished interpreter? How many jobs are asking for people with experience messing with Parrot?

The way I see it, Parrot is probably a great thing for people interested in researching, and experimenting with interpreters, but as far as actual coding is concerned, a (interpreter) project that doesn't release for so long *is* *vaporware*.

(note that I did play with Parrot back in the day (some 5 years ago I guess), and would love to see it fly ;-))

Re:Hmmmmmm

[arodland]

Wow, you must have been a genius to predict that... when the Perl folks were saying the same thing in 2002. :)

Re:Hmmmmmm

[smittyoneeach]

You'd know better than I, sir. If I'm not going to research a claim, I like to take a minimal approach.

Re:Hmmmmmm

[arodland]

That's just the indexer being cranky. Doesn't look that way anymore.

Re:Hmmmmmm

[plague3106]

Actually the CLR handles dynamic languages quite well. Check out IronPython.

Re:Hmmmmmm

[chromatic]

... but as far as actual coding is concerned, a (interpreter) project that doesn't release for so long *is* *vaporware*.

We've released twelve stable versions of Parrot this year alone, including one just yesterday.

Re:Hmmmmmm

[Ed Avis]

This could be one reason why running perl5 in the Parrot VM never really took off. Perl 6 will be a bit better specified, I hope, and so easier to write on top of a specified virtual machine.

Re:Hmmmmmm

[chromatic]

Actually the CLR handles dynamic languages quite well.

It's improving, yes. By the time we added sufficient features to the DLR to handle Perl 6 well, though, we'd have reinvented Parrot on the CLR -- and the DLR didn't exist when we started.

Re:Hmmmmmm

[BlackCreek]

We've released twelve stable versions of Parrot this year alone, including one just yesterday.

8-|

Oeps... my bad. Seriously.

I hadn't heard from Parrot in some time, and I do hear regularly about PyPy (though I have stopped reading Python specific sites for a while now). I guess I should spare you from silly questions I can get answered by downloading a tar ball.

Cheers

Re:Hmmmmmm

[chromatic]

If you do download the tarball, feel free to join #parrot on irc.perl.org. There's a fair bit of code, and having someone onhand to answer your questions can make it much easier to start!

Re:Hmmmmmm

[coryking]

First, I've been meaning to buy your perl testing book.

Second,

• what is in it for me? Why should I care?
• If I'm PHP, why should I compile to PIR?
• 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?
• Where is the boundary between something written in PHP and something in Perl? Is it a function? A class? A module?
• How does PIR handle the clash between objects and classes? Can I pass a blessed object created in perl to my PHP app?
• What about namespace issues and how does PIR reconcile against language that have piss poor namespace support like PHP?
• What about all the cool hashtable/hashref stuff that perl has? How will that work on something like PHP?
• What about inheritance? Can I derive a class in perl from a class written in Ruby?
• What about debugging? If something chokes in my PHP library, will parrot let me see the PHP symbol table AND my python symbol table?
• 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?
• 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?
• In Perl a variable ($var) set to "", undef or "0" all equate to false in:
  
  unless( $var ) { // i'm here if $var is "", undef or "0"
  }
  Does the PIR dictate other languages interpret a variable the same way? If not, how do I as a program deal with this?
• In Perl, subroutines get their variables typically by using:
  sub {
      my $var1=shift;
      my $var2=shift;
      my $var3=shift;
  }
  
  Other languages usually declare their subroutines formally:
  function($var1, $var2, $var3){ //code
  }
  
  How does PIR reconcile this very big difference?

This isn't a diss. What I asked above I think is a very reasonable set of questions and expectations. I'm very curious what the sales pitch is because if it worked correctly, it could be very cool.

Re:Hmmmmmm

[coryking]

And to answer some of my questions... here is the FM. The docs actually define a bit about how namespaces (should?) work as well as other things I left out on my list like threading.

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

Re:Hmmmmmm

[coryking]

Sweet. Thanks for the reply.

Dividing up the namespace by language is the perfect solution. I love it!

I suspect the biggest "problem" will be slop. Parrot cannot tolerate slop from languages. MSIL lays out some pretty important requirements before you can join the MSIL club. For example, if you want to compile C++ to "Safe MSIL", you cannot use the c++ standard library, you cannot use malloc/free, new/delete, or pointers. You've got to instantiate your stuff with gcnew. You can't use native data types, you have to use the .NET ones. And it has to be that way because otherwise you'd have a mess when you call the whole thing from C# or IronPython. That is the beauty of MSIL and .NET - as long as everybody agrees to the rules about what a string is, how inheritance works and how functions and objects behave, the party can go on and on.

As long as parrot requires some baseline functionally before you can join the club, life will be okay. What would suck is if I wrote something in perl that spat out a hashref into the world that wasn't able to get sucked up by another language in the club. Or I wrote a PHP function targeted to parrot that wouldn't work in your scheme-like language. If that was the case, each CPAN or PEAR library would start to have a list of supported languages. On MSIL and .NET, I know that my language plays by the rules, my library will work anywhere. It is the "If $LANGUAGE_X supports a keyed lookup operation, then..." that makes me nervous. How can I test that if there is no defined behavior?

How does parrot deal with calling external libraries (dll's or so's)?

Maybe my flaw is I'm thinking parrot is something it isn't. Does it even make sense to compare it to MSIL/.NET? If it doesn't, I suspect it should be stressed so we stop trying to apply it to where it doesn't belong :-)

Thanks!

Re:Hmmmmmm

[coryking]

Bah! See, I answer my own questions. how to make native calls.

I love perl. Everything is documented, you just have to know where to look :-)

Re:Hmmmmmm

[chromatic]

As long as parrot requires some baseline functionally before you can join the club, life will be okay.

If someone writes a bad PMC by hand, there's not much Parrot can do to fix that. What we can do is make it sufficiently easy to write a good PMC that people do that instead.

Likewise we hope that the standard features that Parrot provides, such as method resolution and control flow and compiler building, are sufficiently powerful and flexible that you can reuse them to build a new language, or customize them in a way that's still compatible with the rest of Parrot.

It is the "If $LANGUAGE_X supports a keyed lookup operation, then..." that makes me nervous. How can I test that if there is no defined behavior?

Perhaps we're talking past each other. I mean the language's syntax. For example, there are no associative arrays in C as a fundamental data type, while there are indexed arrays. It doesn't hurt C on Parrot to use a PMC that has keyed access, but you can't access that PMC by key with C's normal syntax; you need some sort of function to do it for you.

All PMCs have a vtable entry that allows you to access a PMC by key, but not all PMCs are aggregate containers or have some other semantically meaningful behavior for accessing a PMC by a key. Those that don't throw exceptions, but they don't crash Parrot.

Re:Hmmmmmm

[cpeterso]

we hit double-digits with Perl 5 before Perl 6 became available.

When I read this article's title, I thought today was the 20th anniversary of Perl 5.10! Seriously.

Re:Hmmmmmm

[adamkennedy]

Historically the 5.10.0 releases, being .0 releases, have been just the teensiest bit flaky, mostly when people like RedHat layer on patches.

Re:Hmmmmmm

[Anonymous Coward]

Before Christmas, 2002.

Re:Hmmmmmm

[Malevolyn]

For things like that, you'd simply perform a few calculations the old fashioned way, then run them through your Perl and see if the output is the same. It's called "testing."

Re:Hmmmmmm

[jonadab]

> The speedier regex engine is going to be a great boon.

If you say so. My experience has been that the existing regex engine is pretty much never a performance bottleneck for anything I'm doing. (Usually when I do see perf issues it's an I/O bottleneck at fault, typically either the network or the database.)

I'm much more interested in the new features. I'm really looking forward to Perl6, but meanwhile some new features in Perl5 will be nice to have.

Re:Hmmmmmm

[emilper]

And PyPy unlike Parrot, is not vaporware and received funds from the European Union from 2004 to 2006.

to 2006 ... does it mean that in 2006 the funding got split in two, and the competing projects PéPé and PüPü were created ? This would be the result of the "EU Funding Curse" which afflicted Airbus, Galileo, the EUropean search engine, the European Digital library etc.

Re:Hmmmmmm

[plague3106]

We? Are you a developer on IronPython?

Re:Hmmmmmm

[stu42j]

They have been working on PHP for 13 years. Is it "finished" yet? Over that time PHP has been growing, maturing, learning from its own mistakes to become what some might now call a respectable language.

Some languages (Perl 1-5 being another example) started small and have evolved over time. I believe one of the ideas behind the Parrot/Perl 6 development strategy was to take what has been learned from the last 20 (or more?) of language design and do it right the first time, even if it takes 10 years to develop. Of course, other factors such as limited resources have contributed to the slow development as well.

(Consider also that it took 6 years from the start of the open source Mozilla project until the 1.0 release of Firefox.)

Re:Hmmmmmm

[chromatic]

I'm a Perl 6 and Parrot developer, and I was speaking hypothetically, as if I weren't a Parrot developer and were instead helping to implement Perl 6 on the DLR.

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

[A beautiful mind]

Programming languages are syntactic sugar. We could all be programming in lambda calculus if not for the convenience a higher level language provides.

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

[LarsWestergren]

Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing. ...only in a less readable way. MOST language features in any language are syntactic sugar. Besides, if the fact that there is more than one way to do something bothers you, isn't Perl the last language you should be using? :)

Re:Switch statements are syntactic sugar

[Anonymous Coward]

Actually, in many languages such as C#, switch statements vs. if statements can have different performance as well, so it's not purely a syntax issue. For instance, in C#, a hashing is used with the switch so for a large number of cases, a switch is faster than multiple comparisons using if statements.

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

[IBBoard]

if...then...else statements? Pah, syntactic sugar. Don't you know that you can do all of your control flow with while statments?

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

[Anonymous Coward]

Well LISP allows you to define your own syntactic sugar, so I'd say lambda calculus is more high level than most of the "high level" languages in common use.

Re:Switch statements are syntactic sugar

[Instantlemming]

100 monkeys will eventually write something that isn't Perl, but will turn out to be the complete works of Shakespeare. It's possible to write obscure code in every language, so Perl's not alone there. Without comments even COBOL-74 source can be a mysterious black box.

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

[oliderid]

It looks like a step in the right direction (well structured human readable syntax).
I can't wait Perl 6 anyway especially for their promising new Object oriented syntax (and static types).

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

[rucs_hack]

I writ a lot of C, and don't often find much need for switch statements.

I find if-else statements to be quite sufficient. They might be less efficient when compiled, I'm not sure, but when it comes to the readable code, they're simpler to write and parse most of the time. Conditional jumps of any kind are wasted clock cycle intensive regardless. I suppose I could output the assembly and hand optimise that, I know how to do it (yeah, how sad am I...), but if I wanted to do that I wouldn't be using C in the first place.

No doubt some programming guru will blast me as being a bad coder for saying this :-)

Re:Switch statements are syntactic sugar

[Chysn]

It's all syntactic sugar! Just don't take my ternary operator away from me...

Re:Switch statements are syntactic sugar

[Eravnrekaree]

Lambda calculus is a high level construct. It would be more apt to say we could all be programming in ones and zeros, or assembly language, or entering in memory addresses and instruction codes by hand.

Re:Switch statements are syntactic sugar

[krog]

Lisp includes a version of the lambda calculus, but pure lambda calculus is about as useful as a Turing machine.

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

[DJProtoss]

+ is javascripts and pythons string addition operator, presumably because they didn't want to confuse by overloading the standard record deference operator (.), like perl does (which is the better choice is an argument best left to people with time for language bashing).
Now, if we look at the equivilent results when using the string addition operator (lets call it <>, to represent + in javascript/python and . in perl):

2<>"3"==type error in python and perl
"2"<>3=="23" in all
"2"<>"3"=="23" in all
hmm, when you do a comparison taking into account the fact that the languages use different operators for concating strings, surprisingly they act the same! shocking </sarcasm>

Re:Switch statements are syntactic sugar

[TomorrowPlusX]

Sure, technically that's true. But in C++ ( and I'm sure other languages ) I enjoy the fact that if I'm switching on an enum, I can get compiler warnings if I forget one. if/then/else can't do that.

You might as well say that objects are just sugar for structs with function pointers and isa/super class pointers. And that functions are just sugar for goto.

Grousing about a language feature that makes doing certain classes of operations more robust just tells me you don't write much code.

Re:Switch statements are syntactic sugar

[Phil John]

There are cases where a switch is simply syntactic sugar (however the argument for improving the readability of code goes a long way), however, implementing a "fall-through" with if/then/else is impossible (it would have to be done as a load if if/then statements that at the end set the variable to be checked so that it passes the next if test); That's just insane, and error prone when you add new items into the list.

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

[nuzak]

At least Python has polymorphic operators and knows that numbers and strings are different things.

Actually, perl has overloaded operators too. Now itdoes, anyway. Scalars are a remnant from perl 1, and themselves some sort of throwback to awk.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

The '.' isn't Perl's dereference operator. There isn't a single dereference operator, since it depends on the referent's type. The arrow "->" works in the context in which, say, Ruby's (and I presume Python's) '.' would.

Re:Switch statements are syntactic sugar

[Tony Hoyle]

While statemets? pah. setjmp and longjmp ftw.

Re:Switch statements are syntactic sugar

[bytesex]

Never mind that you can do all sorts of modifying behaviour inside the if/else if conditions (which would have to be evaluated by the compiler in the order that it encounters it in), and that you can do fall-trough in the case (!) of switch/case.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

Not to let facts get in the way of a good story, but switch statements are much more than mere syntactic sugar. Switch statements can be optimized much efficiently than one can optimize a chain of ifs. This is quite important in a compile-and-run style language like perl.

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

[Chandon Seldon]

What this means to the compiler is that an if-else if-else... must have O(n) complexity!

Since you're manually typing a constant number of cases, the if-else tree has O(1) complexity. Always.

Re:Switch statements are syntactic sugar

[TheDauthi]

Why would 2 . "3" throw a type error? Does it actually do that in other languages? 2 becomes stringified, becomes "2", and is concatenated into "23". For that matter, perl doesn't even care about the quotes 2 . 3 will return exactly what you would expect - "23".

Re:Switch statements are syntactic sugar

[jez9999]

Yeah, I used to look for a switch statement in Perl until I came along this type of construct, which is far more powerful (regexps) and basically better than a switch:

SWITCH: for ($checkme) {
            $_ eq "foo" and do
                {
                    # Foo stuff...
 
                    last SWITCH;
                };
 
            $_ == 123 and do
                {
                    # 123 stuff...
 
                    last SWITCH;
                };
 
            $_ eq "bar" and do
                {
                    # Bar stuff...
 
                    last SWITCH;
                };
        }

Re:Switch statements are syntactic sugar

[ajs318]

True; but Python {which is otherwise a high-level language} insists for you to call a function just to convert between a string and a number, all so it can recycle an operator. Perl treats numbers and strings interchangeably {and, be brutally honest, isn't the whole point of using a high-level language so you don't have to think about stuff like that?}, but uses distinct operators for distinct operations. JavaScript manages to balls it up both ways, treating things as being the same one minute and different another. Fortunately, you can just pretend that there is no addition operator in JS, and subtract negative numbers instead.

Re:Switch statements are syntactic sugar

[Inoen]

I always preferred the other way of writing conditionals without if:

(3 > 2 and 5) or 4;

Much prettier, and easier to read.

Re:Switch statements are syntactic sugar

[goatpunch]

Sometimes it's difficult to tell if the fall-through was intentional when maintaining old code, an explicit fall-through might have been better. Sometimes it help to put a "//fall through" comment in place of the break.

A better way to reproduce fall-through with 'if' statements would be to create a false boolean variable that names the reason for falling through, and set it to true in one or more of the earlier 'if's.

Re:Switch statements are syntactic sugar

[87C751]

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

I am pretty sure you can't construct Duff's Device using if/then/else.

Re:Switch statements are syntactic sugar

[tuffy]

Numbers and strings aren't interchangeable. What's the correct answer to 1 + "foo" ? A weakly typed language will likely make up some value, but I don't want to second-guess what that value might be. An explicit conversion step that turns strings into numbers is a better way of telling the language what I mean, and providing an error check for invalid numbers at the same time.

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).

Re:Switch statements are syntactic sugar

[chris_eineke]

It isn't. That's why 'if' is a special operator in Lisp. You *could* write it in the former style, but the second is much more readable: syntactic sugar. There's no advantage of doing it the difficult way. Except, maybe, that you can now pass true and false around as functions. :-)

BTW, why do you think that defining true and false as functions makes them 'only extremely locally true'? If you have a predicate, the only outcome is either true or false.

Re:Switch statements are syntactic sugar

[Abcd1234]

If you're implementing Duff's Device at all, let alone in Perl, you deserve to be shot, brought back to life, and shot again.

Re:Switch statements are syntactic sugar

[Sancho]

I don't know--how hard is it to implement Duff's Device with if instead of switch?

Re:Switch statements are syntactic sugar

[mstahl]

In lower-level languages like C, though, they become a multiway branch, which, when converted to machine code, results in fewer branch instructions. In C code, a good switch statement, particularly in a block of code that's already looped or gets called often, can save you a lot of pipeline flushes.

In high-level languages of *course* it's syntactic sugar, since there are some languages sophisticated enough to convert serial if/elsif/else blocks into multiway branches. Perl is all about that sort of thing though. That's why there's always six different ways to do a given thing in perl, and one of the reasons why it's such a great language. Also, I dunno about you, but I'm lazy and I like to write multiway branches instead of a bunch of if/else statements. That way in most languages it's pretty clear that the entire block is talking about the same variable. Was it Donald Knuth, Alan Perlis, or Edsger Dijkstra who said "Syntactic sugar causes cancer of the semicolon"?

Re:Switch statements are syntactic sugar

[Sancho]

Changing the order of case evaluation can break things. Remember, you don't always have to break; before your next case:.

Re:Switch statements are syntactic sugar

[mstahl]

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

When used judiciously, it can actually lead to succinct, readable code. Take for instance, in perl, the opening of a file:

open SOME_FILE, ">some_filename.foo" or die("Some kind of error occurred");

Using short-circuit operators like &&, ||, or ?: can actually greatly simplify your code if you don't go overboard with them, particularly if you can call them "and" and "or". Having more than two such statements in one big expression I would say is ill-advised if you ever want to read your code successfully again. Although, for many of us perl programmers, that's never something we worry about ;-P

Re:Switch statements are syntactic sugar

[ThePhilips]

There are also other constructs that you can use to get around the whole nested if/then/else thing too in many cases.

... amongst them hash of subroutines is best ^_^

There is no other language where pointer to function can be used with such ease.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

The ternary operator is unnecessary as well. Consider the following C code:

typedef void *(*f)(void *);
void *iff(int p, f a, f b, v param) {
      f funcs = { b, a };
      return funcs[p](param);
}

Use it like this:

// assume functions nop and printint are already defined
iff(x >= 32, printint, nop, &x);

I chose void * simply because it's the most universal C type but of course this example can be modified to take more convenient types. With this sort of thing and tail recursion, all control constructs become completely optional.

Re:Switch statements are syntactic sugar

[Sancho]

You can do fall-through in if-else with liberal use of GOTO, however it's pretty ugly.

Re:Switch statements are syntactic sugar

[Sancho]

You can if you add goto into the mix, but it's not nearly as elegant.

Re:Switch statements are syntactic sugar

[glwtta]

+ is javascripts and pythons string addition operator, presumably because they didn't want to confuse by overloading the standard record deference operator (.), like perl does

I mostly found this amusing because of the comment about language bashing. Let's see... wasn't there a somewhat popular language that had used '->' as a dereference operator for a couple of decades already, when JavaScript and Python were created?

Anyway, "type error" on string concatenation in Perl - nice one.

Re:Switch statements are syntactic sugar

[drew]

1 + "foo" == NaN

Re:Switch statements are syntactic sugar

[drew]

They didn't overload anything; (.) isn't the dereference operator in perl, (->) is. I code almost exclusively in JavaScript for a living, and I have a lot of complaints about various language features of Perl, but I will readily admit that this is one area that Perl got right and JavaScript got absolutely wrong. It's OK to use the same operator for addition and concatenation in a typed language like Java or C#, but they are still distinct operations, and using the same operator in a language that freely interchanges one type for another is the height of stupidity.

Re:Switch statements are syntactic sugar

[poot_rootbeer]

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

All statements in all high-level programming languages are syntactic sugar. Switch statempts, for loops, if/then/else, even GOTO -- they're all just sweeteners so the programmer doesn't have to think about native JMP and BEQ assembly instructions.

(Also, assembly is just syntactic sugar for machine code.)

Perl, as usual, is taking the approach that plain refined sugar is not enough; some coders prefer turbinado, and some prefer aspartame, and some prefer corn syrup. Thus we end up with ten different flavors of code, all dialects of the same language.

Re:Switch statements are syntactic sugar

[David_W]

... amongst them hash of subroutines is best ^_^

That's disgusting!

Yet intriguing...

Re:Switch statements are syntactic sugar

[CryoPenguin]

That has nothing to do with if vs switch. The compiler could apply the same optimization to a sequence of if/else statements that follow the same restrictions as switch. Likewise, Perl's new switch operator doesn't require the cases to be constant, but your optimization could still apply when they are. I'm not saying the current Perl interpreter does, just that the optimization is independent of the syntax.

Re:Switch statements are syntactic sugar

[DJProtoss]

I don't know, but it does:
String found where operator expected at test.pl line 3, near "2."3""
        (Missing operator before "3"?)
syntax error at test.pl line 3, near "2."3""
Execution of test.pl aborted due to compilation errors.

Re:Switch statements are syntactic sugar

[drew]

Nested if/else are not really identical; there's not a clean way to fall through to the next case when using if/else. I suppose some might consider that a feature rather than a limitation, but there are some types of algorithms that I just can't bring myself to think about implementing without a switch statement.

Re:Switch statements are syntactic sugar

[chromatic]

Look at the smart match operator in Perl 5.10. I think you'll like it.

Re:Switch statements are syntactic sugar

[DJProtoss]

fair cop, I missed the fractional bit,but weirdly: print (2).("3"); prints "2" - now whats going on there? shouldn't that also output "23"? I'm not sure I agree 100% with your interpretation of the PoLS. If I add two numbers together, the least surprising thing is clearly to get the sum. If I add two strings together, then the least surprising thing is to get the concatentation of those strings, so is there a necessarily a resolution to adding a string and a number together that is least surprising? Now in the example you gave, I agree for that one 5 makes the most sense, but what if one (or both) the values was in a variable? I don't think that would be as obvious, and I am unhappy with code that does different implicit type conversions based on the values rather than the types in the operation. oh, and to the last point: NaN's should never be treatable as zero, thats plain wrong and leads to sloppy coding. If you need that then either you haven't filtered your user input properly (most likely) or you haven't taken your systems floating point accuracy into account correctly (maybe).

Re:Switch statements are syntactic sugar

[TheDauthi]

Your quotes are in the wrong place - your code had "2."3"", which is a parse error (it becomes ["2.", 3, ""] with no operators between them) - I think you tried to quote the entire operation, which isn't needed. Try print 2 . "3", no quotes. That's the equivalent of python's print 2 + "3".

Re:Switch statements are syntactic sugar

[DJProtoss]

my apologies, I meant to say record member operator, not dereferencing operator.

Re:Switch statements are syntactic sugar

[morgan_greywolf]

Fall-through in Python (which has no syntactic sugary switch statement):


# menu
# A=FuncA
# B=FuncB
# and so on
if option in ('a','A'):
        functionA()
elif option in ('b','B'):
        functionB()
elif option in ('c','C'):
        functionC()
else:
        #fall-through
        print "Sorry, there is no option '%s'!" % option

Re:Switch statements are syntactic sugar

[Sean Hermany]

In C and C++, switch statements are far from syntactic sugar, they are a performance optimization.

Re:Switch statements are syntactic sugar

[mr_mischief]

That's certainly one way to do it. I prefer a hash of sub references. I find the control flow much clearer that way, but YMMV. BTW, you mention you can use regexps with your method in your post, but your example doesn't show any. You could also use regexps with this type of construct, but not as easily as with yours. You have the option of easily having equality in one place, a regexp in another, and some other condition in another.

#!/usr/bin/perl --
use strict;
use warnings;

my %choices = (
    'foo' => sub {
        ### foo stuff
        print "foo!\n";
    },
    123 => \&one23,
    'bar' => \&bar
);

sub one23 {
    ### 123 stuff
    print "123\n";
}

sub bar {
    ### bar stuff
    print "bar!\n";
}

my $checkme = 'bar';

if ( exists $choices{ $checkme } ) {
    &{ $choices{ $checkme } };
} else {
    ### default stuff
}

If you really need regexps with this, one way (which forces every condition to be a regexp match) is this:

my $match = join '|', ( keys %choices );

if ( $checkme =~ /($match)/ and exists $choices{ $1 } ) {
        &{ $choices{ $1 } };
  } else {
    ### default stuff
}

Re:Switch statements are syntactic sugar

[stu42j]

What is wrong with sugar? The smart match operator makes switch statements super sweet!

Re:Switch statements are syntactic sugar

[DJProtoss]

"using the same operator in a language that freely interchanges one type for another is the height of stupidity."
I agree (no, really) - lets throw away *all* implicit type changes to types which are not 100% overlapping in value ranges. That should clear out a surprisingly large number of bugs from systems. It would also make a lot of programmers moan like crazy, but /me shrugs.

Re:Switch statements are syntactic sugar

[jerrysiebe]

Put a space between the '2' and the '.' and it will be parseable by perl. '2.' is the same as '2.0', thus what perl is seeing is '2.0 "3"'.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

Hi, I'm a Python user. This feature is wonderful, indeed, almost as great as PHP features. Do you have to use triple equal sign to see if "5" is 5 or "5"?

Re:Switch statements are syntactic sugar

[TheDauthi]

print (2).("3")

I'll explain this one, but the real answer is that you're not telling perl what you think you're telling perl. And I wouldn't say you're wrong about it. Basically, print is a function. The function operator "()" has a higher precedence than the concat operator ".". You're calling the print function with parens, as print(2). The remainder of the line is appended to the return value of the print. Test this to see that in action:

my $i = print (2) . (3) . (5);
print "\n", $i;

BTW,

use warnings

would have caught that. Why it's not default by now, I can't say.
As to your second point - it is doing the implicit type conversion based on the operator, not the operands' types or values. "+" does a numeric add, "." does a string concatenate. Using either will do an implicit conversion if needed. The type does come into play to see if it's possible to convert from one to another because, for example, "foo" is somewhat hard to make into a number. If the value is in a variable ... it's treated exactly the same. If you're adding numbers, use "+". If you're concatenating strings, use ".". Perl will only make implicit conversions if they're possible.
On the third, I agree 100%. NaN shouldn't be treated as zero. It's sloppy. Fortunately,

use strict;

will catch that for us.

Re:Switch statements are syntactic sugar

[chromatic]

Why it's not default by now, I can't say.

Backwards compatibility.

It's on by default in Perl 6 for all programs executed from files, not as one-liners on the command line.

Re:Switch statements are syntactic sugar

[Carnildo]

fair cop, I missed the fractional bit,but weirdly: print (2).("3"); prints "2" - now whats going on there?

Perl's rule for function calls is that if it looks like a function call, then it is a function call. You're calling the function "print" with numeric 2 as its only argument, then string-concatenating the function's return with string 3 and discarding it.

Re:Switch statements are syntactic sugar

[Cyno]

If I'm adding an undefined value to a defined value I want to get the result and flag a warning, not get a compile or run time error and halt execution. And personally, I think print (2).("3"); should print "11".

Re:Switch statements are syntactic sugar

[Anonymous Coward]

Fall-through in Python (which has no syntactic sugary switch statement):

Congratulations, you have successfully proven that you don't know what you're talking about. I suggest you go and learn what fall-through is before you embarrass yourself further.

Re:Switch statements are syntactic sugar

[timothy]

What? No room for alternative religious celebrants? What kind of compression is *that*?! :)

timothy

Re:Switch statements are syntactic sugar

[Anonymous Coward]

I highly recommend looking at Ruby. The "case" statement actually uses Ruby's === operator, which checks not only for equality, but for matching. That means you can pass it regular expressions or ranges as well as single values:


case 1984
when 0..1949
    puts "Before 1950"
when 1950..1979
    puts "Fifties through seventies"
when 1980..1989
    puts "Eighties"
else
    puts "Nineties on"
end

(outputs "Eighties")

case "jim@email.com"
when /\d\d\d-\d\d\d\d/
    puts "Phone number"
when /[A-Za-z\.-\+\d_]+@[A-Za-z\.\d-_]+\.[A-Za-z\.\d-_]+/
    puts "Email address"
end

(outputs "Email address")

Re:Switch statements are syntactic sugar

[ajs318]

No. The === sign is a PHPism for equal in value and of the same type, and is necessary to override some of PHP's magick. PHP differentiates internally between strings, floating-point numbers, integers and booleans. So "5", 5 and 5.0 are different types even though they have equal values. The <, <=, ==, >=, &gt and != operators are being overloaded and this is potentially creating a problem when comparing different types; for instance, "5" "10". Note also that true and false are coerced to integers 1 and 0 respectively, if you try to evaluate them in any non-Boolean context (including printing); and that PHP4's typecasting would actually support the use of + as a string concatenation operator, if the . concatenation operator hadn't already been introduced in PHP3.

Perl uses altogether different magick. It doesn't distinguish at all between strings and numbers, at least not at any level that is exposed to the programmer; they're all just scalars as far as Perl is concerned. Instead, you have to use different equality operators depending on whether you want to treat the things being compared as strings or numbers. Using <, <=, ==, >=, &gt or != causes the arguments to be compared as though they were numeric (possibly generating warnings if they aren't). If you want scalars to be compared as strings, you use Fortran-style lt, le, eq, ge, gt and ne operators (note this is the opposite way round from how sh does it). Then "5" == 5 and "5" == 5.0. And "5" eq 5, but 5 ne 5.0.

The point is: either way works, but you can't have it both ways at once, because you'd be pitting operator-overloading magick against type-munging magick. 5 evaluated numerically is less than 10 but "5" evaluated as a string sorts later than "10", and you have to be able to specify which you mean. Either by using typecasting to bypass operator overloading, or by using non-overloaded operators in the first place.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

But wrong.

(3 > 2 and 0) or 4

doesn't do what you want it to. This is one of Python's few gotchas.

Re:Switch statements are syntactic sugar

[nuzak]

> The === sign is a PHPism for equal in value and of the same type,

Actually it's lifted from Javascript, where it means the same thing as lisp's eq (but not perl's), or python's is . But as usual, PHP got it head-slappingly wrong and now we're all stuck with it.

Re:Switch statements are syntactic sugar

[nuzak]

> open SOME_FILE, ">some_filename.foo" or die("Some kind of error occurred");

Just to nitpick, the recommended modern perl idiom looks like:

open my $file, '>', 'some_filename.foo' or die "Couldn't open file for writing: $@";

Or use Fatal qw(open); and skip the "or die" part altogether. Arguably it's behavior that should have been been in perl from the start, but perl still doesn't have a decent exception mechanism built-in.

Re:Switch statements are syntactic sugar

[ajs318]

If I'm adding an undefined value to a defined value I want to get the result and flag a warning, not get a compile or run time error and halt execution.

Then don't use strict; and your program won't die. Or wrap the code in an eval and test the result for definedness (hey, you might even get to use the spiffy new //= operator). If you omit the -w in the first line (usually #!/usr/bin/perl -w), then you won't even get a warning.

And personally, I think print (2).("3"); should print "11".

Ah, I get this ..... you want to evaluate two single-element lists as scalars (so returning the count of elements in the list), concatenate the results and print that. Unfortunately, Perl has different ideas about operator precedence. Lists evaluated in a scalar context do normally return the count of items in the list, but single-element lists evaluated in a scalar context -- which look remarkably similar to simple scalar expressions in round brackets -- magickally return the only member instead. You'd have to do an assignment in a list context to coerce such an expression to be a real single-element list, then evaluate the list as a scalar.

Re:Switch statements are syntactic sugar

[mstahl]

I'm torn . . . your code looks nicer because the ">" isn't included in the filename and because a $variable is used for the file handle, both of which I think throw a lot of people off, but . . . but . . . it just doesn't look like perl!

Seriously though thanks for the correction.

Re:Switch statements are syntactic sugar

[nuzak]

> There is no other language where pointer to function can be used with such ease.

Don't use many other languages, do you? To wit, in python:


dispatch = dict(foo=func1, bar=func2, blah=func3)
dispatch[op]()


The same code in perl:

my %dispatch = (foo => \&func1, bar => \&func2, blah => \&func3);
$dispatch{op}->();


Don't even get me started on Scheme.

Re:Switch statements are syntactic sugar

[hackstraw]

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

Switch statements can be optimized by the compiler, nested if/then/elses cannot.

Re:Switch statements are syntactic sugar

[johannesg]

Well, like I said I don't speak lisp, but the code seems to suggest that 'true' is being redefined for this specific test. But I'm probably just misunderstanding the syntax, the bit that says '(define true (x y) (x))'. I should learn lisp, one of these days, I just never seem to get around to it...

And I strongly disagree that readability can be equated with syntactic sugar. The ability to write syntactically shorter statements with the same meaning == greater expressive power == the ability to write more complex software in less time with higher reliability. That's not syntactic sugar, that's a measurable benefit. Alternatively, I'm willing to argue that every higher-level language is syntactic sugar compared to just typing raw hexcodes ;-)

Re:Switch statements are syntactic sugar

[workdeville]

You don't seem to know what high level means. The Lambda Calculus is certainly a high level programming paradigm, because it is expressive enough to do lambda abstraction and beta reduction without making the user deal with machine specific implementation issues. This is stronger than the definition of "high level" in this context, which only requires restricted lambda abstraction. Jeez, and you got karma for it too.

Re:Switch statements are syntactic sugar

[budgenator]

you can do all of your control flow with while statments
Young whippersnapers don't know when they got it good, all we had was IF THEN's, and GOTO's and were lucky to have that! Scoped variables are for woosie and we had to punch our own Hollerith cards, next your going to tell me that you need more than 16k core; now get off my lawn.

Re:Switch statements are syntactic sugar

[Anonymous Coward]

No you can't in general because if is a special form that does not evaluate the operation not chosen. Your version does. So if there is a side effect of evaluation that you want to avoid, your version does not avoid it while the built-in does.

Re:Switch statements are syntactic sugar

[berbo]

XKCD on lisp

Re:Switch statements are syntactic sugar

[ThePhilips]

Interesting.

But do they support dynamic number of untyped arguments? i.e. analog of Perl's @_ variable?

Re:Switch statements are syntactic sugar

[ThePhilips]

my %dispatch = (foo => \&func1, bar => \&func2, blah => \&func3);
$dispatch{op}->();

That's actually what I had in mind (in context of switch/case):

my %dispatch = (
foo => sub {
return "foo result";
},
bar => sub {
return "bar result";
},
baz => sub {
return "baz result";
}
);
return &{$dispatch{$event}}( @_ );

That's how i usually do switch/case in Perl. That's very convenient, since Perl allow the subs to use variables in context.

Re:Switch statements are syntactic sugar

[Pentagram]

I should learn lisp, one of these days, I just never seem to get around to it...

Yes you should :)

Practical Common Lisp

Re:Switch statements are syntactic sugar

[Anonymous Coward]

And personally, I think print (2).("3"); should print "11". Ah, I get this ..... you want to evaluate two single-element lists as scalars (so returning the count of elements in the list), concatenate the results and print that. Unfortunately, Perl has different ideas about operator precedence. Lists evaluated in a scalar context do normally return the count of items in the list, but single-element lists evaluated in a scalar context -- which look remarkably similar to simple scalar expressions in round brackets -- magickally return the only member instead.
That's not quite right - there's no real 'magick' going on here. Actually, lists in scalar context will always return the value of their last element; this is really just a standard use of the comma operator, like in C. It makes no difference whether it looks like a one- or many-element list:

> perl -le 'print( (2).("4","3") );'
23

You'd have to do an assignment in a list context to coerce such an expression to be a real single-element list, then evaluate the list as a scalar. I believe you were thinking of arrays (not to be confused with lists), which do return their length in scalar context:

> perl -le '@a=(2); @b=("3"); print(@a.@b);'
11

or, even (no assignments necessary)

> perl -le 'print(@{[2]}.@{["3"]});'
11

Re:Switch statements are syntactic sugar

[nuzak]

Yes. foo(*args). Or if you like your args named, foo(**kw)

Aren't these two unrelated events?

[Westley]

I can't see why (in purely practical terms) it's worth coordinating a release with an anniversary.

Surely if the code is "ready" (thoroughly tested etc) before the anniversary, it could very easily be useful as a release to developers before the anniversary.

If it isn't ready, it shouldn't be released early just because there's an anniversary.

Re:Aren't these two unrelated events?

[Anonymous Coward]

Perhaps the Anniversary was the date set to have it all ready by. People set deadlines and they probably met the deadline hence it being released. Common sense plz.

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.

Re:Aren't these two unrelated events?

[Anonymous Coward]

Surely if the code is "ready" (thoroughly tested etc) before the anniversary, it could very easily be useful as a release to developers before the anniversary.

Yes it could. So?

I doubt the Perl community feels disenfranchised because of a week or month delay. After all, we've been waiting on Perl 6 since the turn of the century.

Re:Aren't these two unrelated events?

[Anonymous Coward]

Remember, we're talking Perl hackers here. Jesus 2.0 landing in Bologna in time for Christmas couldn't generate as much salivating over spaghetti.

Re:Aren't these two unrelated events?

[ricegf]

I doubt the Perl community feels disenfranchised because of a week or month delay. After all, we've been waiting on Perl 6 since the turn of the millennium.

There, fixed that for ya. ;-)

Re:Aren't these two unrelated events?

[photon317]

Actually, Perl 5.10 has been in release candidate state for a little while now, and someone recently just happened to drop an email reminding p5p of the upcoming anniversary and how cool it would be to release on the anniversary date, so it became a target to get the final out on that date. Without the anniversary to shoot for, it probably would've been a few days later. The fact that the anniversary happened to fall somewhere in the right vicinity was pure luck.

Re:Aren't these two unrelated events?

[spaceyhackerlady]

Just imagine what will happen when Python turns 20...

...laura

Re:Aren't these two unrelated events?

[glwtta]

You are right, it's almost as if they somehow knew about the anniversary and planned the release beforehand.

Spooky.

Re:Aren't these two unrelated events?

[rubycodez]

you're going to compare a magnificiently architected skyscraper with urban sprawl sans zoning? ah well, at least Perl 5 is useful, I've written tons of it. Sadly, haven't yet worked with any project where python was needed, and for my personal use I choose something else where they feel the need to release new things at Christmas!

Re:Aren't these two unrelated events?

[stu42j]

FYI, they started doing release candidates in November.

Re:Aren't these two unrelated events?

[adamkennedy]

Mostly it is accidental.

The 5.10 release process was going to complete very VERY close to the 20th anniversary, so as a result a lot of people put in a lot of extra work to get the polishing out the way in time for the 20th anniversary.

So in a way, the neatness of the idea became self-fulfilling.

Re:Aren't these two unrelated events?

[Dr.Ruud]

> 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.

Patch number 32767 would also have been nice.

The name of the language is Perl.

Perldelta

[Anonymous Coward]

The link should be perlDELTA, not perldata.

perldata link

[mariushm]

PerlData Link is actually this one, not the current link that points to the blog.

Is this the version

[$RANDOMLUSER]

that has the ORELSE operator?

Re:Is this the version

[dintech]

I think as well as things like GIVENWHEN or GOTO it might also include the COMEFROM statement.

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

[$RANDOMLUSER]

How is that different than following a function pointer in C?

Re:Is this the version

[dintech]

Also, this is supposed to be satire so don't take it seriously.

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.

Re:Is this the version

[tripa]

Now why did I have to parse this as "ORALSE"?

Re:Is this the version

[mr_mischief]

Is that some sort of ultimatum to the compiler?

There is an 'elsif' keyword, in case you were being at all serious.

Re:Is this the version

[$RANDOMLUSER]

It's not an ultimatum, it's the "conditional threat" operator.

Re:Is this the version

[Chysn]

> Now why did I have to parse this as "ORALSE"?

        The answer to that question lies deep within your black soul.

Re:Is this the version

[iluvcapra]

How is that different than following a function pointer in C?

You can change a function pointer, but when you call the mystery function, you always know that flow will return back to the line following your call (unless the mystery function blocks forever or exits or whatever). You also know that the called function has no access to the caller's scope.

It's the basic difference between a goto and a function call. A goto always moves execution from one point in a scope to another within that scope (well you can cheat that, but you're asking for trouble), and goto's don't return.

Re:Is this the version

[supersnail]

I mulled on this overnight and realised that that several languages have actually implemented "COME FROM" albeit in disguise.

The first attempt was propably DB2 SQLs "ON ERROR" statement which is actualy a "COME TO" statement
but just as devistating to program logic as "COME FROM", this was faithfully implemented in by most
"pre-compiler" sql implmentations such as Pro*C.

Then in purist java we have perhaps the purest implementation the "catch " statement is definately
a typesafe implementation of "COME FROM".

The somewhat less than pure C++ implementation of "catch" combines the functionality if the "COME FROM"
with the elegence of "COME TO" and half the features of a good "ON INTERUPT" and the reliability of
"DIVIDE BY ZERO".

For the superlative "HOW DID I GET HERE?" experience nothing can beat the combination of J2EE, Spring, and
ASPECTJ. This is truly distributed coding; the "FROM "code is hidden in a the spring xml, the "COME" code is
elegently hidden in some xml file referenced by an AspectJ xml file, and the actual transfer is done by a java class you didnt know was in your project. No wonder they abandoned the obfusticated C contest!

Re:Is this the version

[$RANDOMLUSER]

Interesting. Thanks!

Linus is right

[Anonymous Coward]

I have to agree with Linus on this one.

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.

[sapphire wyvern]

Hey, it lets them shave a few characters out of "Hello, world."

Who says code optimization is dead!

Re:Oh dear.

[leonbloy]

Planned for the next release:
  - shout() : similar to print(), but appends three exclamation signs
  - htmlshout() : similar to shout, but surround the string with <b></b> tags

Actually, I like Perl, but orthogonality has never been one of its strong points.
It seems that it's getting worse.

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.

[Anonymous Coward]

Who needs threading when you have fast forking?

Re:Oh dear.

[Phroggy]

Come on guys, it's not like this is unique to Perl.

Re:Oh dear.

[xiaomai]

I learned ruby before perl, although I use both on a nearly daily basis now, and coming from the ruby world with its "puts" statement (also adds a newline char), I'm pretty excited about not adding ', "\n"' to the end of all my print statements from now on.

Re:Oh dear.

[photon317]

say() is a fairly pragmatic addition to the language. Do you have any idea the percentage of "print" statements in existing perl code which end in "\n". And how often that "\n" is the sole reason to use interpolating quotes and/or an append operator in the print statements (eg:

print $foo . "\n";

)? It's a high percentage and a pain in the ass.

Re:Oh dear.

[naileke]

You're not that far from reality.

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.

[Sancho]

That's a bad example, because you could have easily said print "$foo\n";.

It gets more complex when you're using more complex structures: print "Looking up " , $foo->{bar} ": could not find ", $bar->{baz}, "\n";.

Re:Oh dear.

[Anonymous Coward]

When a language is well designed from the beginnig:

print foo, #prints foo without \n
print foo #prints foo with \n

Easy to remember, to write and to read.

Re:Oh dear.

[Frank Battaglia]

Agreed.

Re:Oh dear.

[karmaflux]

Actually, I like Perl, but orthogonality has never been one of its strong points.

You misspelled "goals" there at the end.

Re:Oh dear.

[funaho]

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

Re:Oh dear.

[mr_mischief]

It's not exactly a new concept. Pascal had write() and writeln(). Java has print() and println(). Perl's keywords, standard variables, and operators are chosen for making common things take fewer characters before orthogonality.

### from
print "Hello, World!\n";
### or from
print 'Hello, World!' . "\n";
### to
say 'Hello, World!';
### and not to
println "Hello, World!\n";

It's not necessary, and you can still print a newline with print or printf if you like.

As for threading, people have been using it in production for some time now. You do know the original threads implementation was trashed and replaced? The new one's not perfect, but it's much better than it was.

Re:Oh dear.

[mr_mischief]

Why cause the cost of interpolation when you don't have to?

Re:Oh dear.

[maddog42]

I'm using perl threads in a production environment to generate 11K+ satellite images daily; I'd say they work pretty well... Check out the website for a look-see.

Re:Oh dear.

[thospel]

Because if speed is that important you shouldn't be using an interpreted language.

Always write the clearest code (of the proper complexity class). Only optimize after
the program turns out to be too slow and after you actually profiled that piece of
code to be an important cause of the slowdown.

Nothing destroys good code like premature optimization does.

Re:Oh dear.

[thospel]

Which also interpolates just fine:

print "Looking up $foo->{bar}: could not find $bar->{baz}\n";

It's things like actual function calls that don't interpolate cleanly (yes, I know the tricks, no in general I don't want to use them)

Re:Oh dear.

[Sancho]

Huh. Sure enough, it does. I would have sworn that it didn't work (interpolating $foo as the variable and ->{bar} as part of the string.) Maybe I was just thinking of the function case.

Re:Oh dear.

[chromatic]

What cost of interpolation? The ppcodes are (basically) the same in both cases. There are variable accesses and concatenations.

Interpolation is a syntactic benefit for coders. The VM doesn't care.

Re:Oh dear.

[acid06]

The new say() built-in is actually pretty nice and is borrowed from other languages. It's specially nice if you consider it can accept an array argument and print each of its elements in a single line. So:

    print "$_\n" for @array;

Turns into just:

    say @array;

Which is *a lot* better. You might argue (with some success) that "say" is a stupid name. But it's a short word e better than, say, "println", in my opinion.

Also, threading has been stable in Perl for some years now. The implementation isn't lightweight, though, so current Perl threads are only suitable when a regular fork() would do it. That's why it's mostly not used. In fact, under Windows, fork() is emulated using threads.

Re:Oh dear.

[Anonymous Coward]

Of course there is prior precedent in other languages: write/writeln in old Pascal, print/println in Java. Their names follow the principle of least surprise, too.

But Perl pretends that it is something new and original, so it could NEVER simply follow precedent and add a println function. Too damn easy, too regular, and it would be an admission of the existence of other successful languages' design.

Perl is so breathtakingly advanced above all other languages that it has to invent its own, inevitably kludgier, way.

I'm sure the justification will be that Perl's "say" is 4 chars shorter to type than "println". Oh, that is *so* worth the added irregularity. Good trade-off!

I swear Perl's design goal seems to maximize its ability to consistently win the Obfuscated Code contest in one line.

While we're on the subject of fixing common use-cases for programs, can anyone tell me if Perl 6 will automatically read both and as end-of-line? (Ideally, you could deviate from the default and *specify* the end-of-line sequence, too.) And what will be the char(s) written by default by "say"? Ideally, you could specify what the end-of-line sequence would be, there, too. It is debatable what the default sequence should be for writing (platform convention -or- ).

This *automatic* behavior would be easier and more robust than having to remember to specify some "flexible" end-of-line convention as a flag on an open statement. Really, it is silly that we must be careful in this day and age to have the "correct" end-of-line encoding in files we read.

Re:Oh dear.

[Anonymous Coward]

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.

Any Perl code causes panic.

Re:Oh dear.

[nuzak]

Bah, that's just a simple phrase translator. Try LOLPYTHON to actually program that way. I'm quite positive the lameness filter will rightly defy my efforts to post a sample here, so CLICKIE PLZ THX LOL.

Still, LOLPYTHON has nothing on Perligata

Re:Oh dear.

[freaker_TuC]

you forgot something:

while ($coldenough) .. ;)

Re:Oh dear.

[Anonymous Coward]

yes, I know the tricks

It doesn't matter, I'm feeling sexually aroused by teaching them to you again and again.

print "time is @{[scalar localtime]}\n";

Re:Oh dear.

[dirtyhippie]

Sorry to be pedantic, but that code makes no sense.

ski@testbed:~$ perl5.10.0 -e 'use strict; use warnings; use feature qw(say); say my $name'
Use of uninitialized value $name in say at -e line 1.

You could tell it to say $name, when name is already defined, but not with that pesky my in there.
ski@ganiodayo:~$ perl5.10.0 -e 'use strict; use warnings; use feature qw(say); my $name = "papi"; say $name'
papi

ski@ganiodayo:~$ perl5.10.0 -e 'use strict; use warnings; use feature qw(say); my $name = "papi"; say my $name'
"my" variable $name masks earlier declaration in same scope at -e line 1.
Use of uninitialized value $name in say at -e line 1.

The only way it would work would be:
ski@testbed:~$ perl5.10.0 -e 'use strict; use warnings; use feature qw(say); say my $name = "papi"'
papi

And it's probably not so kinky to scream out "say my dollar-sign name equals double quote papi double quote" ;-)

Re:Oh dear.

[mr_mischief]

It's not a cost of execution time, as you and the other respondent assumed. It's a maintenance cost. In simple interpolations, it's clear enough what's going on. In longer ones with lots of variables, it's often clearer (to me anyway) to explicitly concatenate the values.

Re:Oh dear.

[tooth]

say is a great idea when working with $_, no more print "$_\n"; inside loops just to get a newline on the end.

lame naming scheme

[Anonymous Coward]

So does Perl know that version 5.10 > 5.8?

Re:lame naming scheme

[krog]

Next you'll be complaining when I say that 4.4 > 5.4.

Anyway, the formal version number is 5.010_000.

Re:Thanks Larry

[tha_mink]

Yeah...Huzzah...Let's all go down and riot at the punctuation factory.

$_ = 20

[Anonymous Coward]

I must say, I never thought I'd live to see Perl make it to. long years! To think, years ago the original Street Fighter had just been released. The PC first got the VGA standard years ago -- the Web? Forget about it -- years ago, the Internet barely existed as such!

Congratulations Perl on making it to glorious years!

I wonder if you'll make it to more?

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).

Re:recursive patterns

[Constantine XVI]

The new recursive patterns should increase perl's readability. The new recursive patterns should increase perl's readability.

Oh right...

[chicoryn]

Readability? You do realize this is Perl we're talking about? Oh come on, you can write readable Perl code. Never mind that it is never practised.

Re:Oh right...

[Anonymous Coward]

One of the keys to writing good fantasy is the suspension of disbelief.

Channeling Jeb Magruder, are they?

[wiredog]

"The new version on the anniversary, thus, was immediate and automatic," Wall wrote later. "No one ever considered that there would not be a new version on the anniversary."

Original source.

Thank you

[Anonymous Coward]

Please provide five examples. Thanks in advance.

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

[Anonymous Coward]

Spoken like a true Java developer. You clearly have no clue what you are talking about.

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

[frith01]

Welcome to real processing. I have several perl libraries and individual scripts that top the 20,000 line mark. These are used for medical transaction processing.

Re:Much Thanks to Mr. Wall

[Doctor Crumb]

The same can be said about any language. If you're worried about writing applications and not scripts, read up on using modules in perl. They're a bit wordier than C++ and Java style classes, but they can also be used as non-oop libraries or used to extend other modules without repeating yourself or building a huge class tree.

You'll also be much happier if you start using DBIx::Class instead of pure DBI; it's the best object-relational mapping I've found in any language thus far.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

Weeell... I work with a company that has several millions of lines of code written in Perl, and runs all the business with it. And guess what, it works. And it is fast, and maintainable. And the company grows much faster than the competition. And... forget it. Misconceptions cannot be beaten by fact, I should know it by now.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

No. If you switched to PostgreSQL your life would be perfect.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

Well, those sound OK, but I'm going to stick with the Bruce Lee of programming languages.

You may now have an argument about which language you think I'm using.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

This may have been a relevant comment 5-10 years ago, but at this point (since Perl 6 has failed to deliver as of yet) people have moved onto other scripting languages, whose codebases have also been dramatically improved since their last releases.

I hate to break the news to you, but "real processing" as you call it can be done in a number of languages other than Perl, while having the advantage of actually being readable for future maintainers' convenience.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

Doesn't matter which one it is, I'm sure it's shit.

Re:Much Thanks to Mr. Wall

[mr_mischief]

Just because you can write unreadable slop in Perl doesn't mean you have to. Just like the idea that you can write an accounting package in COBOL doesn't mean any non-masochist would do so by choice.

Re:Much Thanks to Mr. Wall

[cliveholloway]

Um, ever heard of namespaces, modules and OO programming? I think you might want to go look those up before stating that things can get confusing.

I'm currently maintaining and building on top of a project that currently has about 12,000 lines of code in 24 modules, and I don't get confused.

You a PHP developer by any chance? *shudder*

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

No, it doesn't mean that you have to. It means that it's full of shortcuts that are convenient for the experienced developer only -- that is a Perl design choice, Perl advocates believe it's a good one, you're entitled to believe what you like. Personally I think it's a good reason not to use Perl.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

I had some issues with DBI and Leopard as well. The module couldn't find the correct libraries so I symlinked the following

seth@slacker ~ $ ls -l /usr/local/mysql/lib/mysql
lrwxr-xr-x 1 root wheel 1 Dec 13 15:30 /usr/local/mysql/lib/mysql -> /usr/local/mysql/lib

Not sure if you're having the same issue though.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

I don't care what you may have read on the internet, Chuck Norris is *not* cooler than Bruce Lee.

Re:Much Thanks to Mr. Wall

[Just Some Guy]

I have several perl libraries and individual scripts that top the 20,000 line mark. These are used for medical transaction processing.

Making a mental note not to get sick where you live.

Re:Much Thanks to Mr. Wall

[mr_mischief]

Some languages are more suitable to certain developers. Perl is suitable mostly to those who are willing to learn lots of idiomatic usage and can restrain themselves from certain bad habits without the language enforcing a style. It's great to be able to bend the rules when it provides a real gain, but abusing the language is not a good idea in production code. Abusing Perl is quite easy to do. Those who have a team prone to pushing a language out of shape would be wise to use a language a little more rigid. It's good to see a reasoned decision to use a different language based on that understanding.

Perl6 will change parts of this, but it will still be designed for a great deal of expressiveness and flexibility. For those who value other things over what's in Perl's list of goals, it's still going to be the wrong language. For those who like Perl5 but want lots of the advantages of other languages that Perl5 lacks, Perl6 I think will be a great thing.

I'm glad you've come to a conclusion based on weighing costs and benefits. My conclusion, based on different needs and preferences, leads me to Perl more often than not. Other languages can often be a better choice, though, depending on the project and the developers.

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

Download and use activeperl. www.activestate.com

It works fine, after installing active perl
cd /usr/local/ActivePerl-5.8/bin --Change the activeperl portion of path to your version

sudo ppm

type password

Search and install DBI with graphical installer
Search and install DBD::MySQL with graphical installer.
Install with install button, quit PPM
During install make sure to install into site/lib option.

Modify perl scripts.
At the top of every perl script you want to use DBI with use
#!/usr/local/ActivePerl-5.8/bin/perl

Ok, done!

Re:Much Thanks to Mr. Wall

[Anonymous Coward]

Those are two words that I keep hearing mentioned when Perl advocates are involved, "expressiveness" and "flexibility..."

Expressiveness I'm not sure most Perl advocates could even define clearly. If they could, they might be able to answer what it is that makes Perl more "expressive" than other languages, apart from being more difficult to read the more a given Perl programmer delves into its esoteric shortcuts and default variables? The same programs written in Perl can be written in Python, Ruby, C, C++, any language that you could think of...how are any of them inherently less "expressive" than Perl?

The "flexibility" notion seems largely to center around CPAN, which is a great resource...however, flexibility in the eye of the Perl advocate is much different than most. Flexibility means it's a good "glue" language for passing data between applications, modifying/analyzing said data, etc.; there's a quick and dirty way to do most real-world tasks. In the real world, however, flexibility now includes developing high-level languages with far clearer syntax and rules...languages that can be used not just in the manner that Perl is capable of, but as well as more complex applications (e.g. Qt4/Python combination). Python can be used to run everything from a web-server to a basic shell script, to a cell phone app, etc. Being that Python can do what Perl can, as well as more, I would tend to think that Python would be the more flexible of the two languages if I were to play the devil's advocate.

Any computer scientist would be able to tell you (likely even prove mathematically) that Perl is neither qualifiably more "expressive" or "flexible" than any other of its competitors, and in fact would seem to have more negatives against it than positives (difficult to learn, hard to maintain depending on previous maintainer's coding habits to an extreme degree, almost useless as a platform for GUI development, etc.). Would someone care to demonstrate for me in a meaningful manner, for example, how one Perl script performing a given task is more "flexible" than the same script in a different language?

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:Much Thanks to Mr. Wall

[Anonymous Coward]

Gosh that's funny. Psst, have you seen what a lot of medical apps are written in? A language called MUMPS. MUMPS makes perl look downright elegant.

Re:Much Thanks to Mr. Wall

[asackett]

"Wouldn't use it for anything over a few hundred lines, tho, too easy for variable to get confused, even when using strict."

Unadulterated manure of the male bovine.

I've never before in my life heard of variables getting "confused", and I've certainly never seen Perl do anything that might be called confusing them. I've seen poor programmers get confused, and I've seen code that proved they were confused when they wrote it, but I've never seen Perl get confused.

Re:Much Thanks to Mr. Wall

[BodhiCat]

Well all I can say is that personally I prefer Perl for short programs, which is about all I write for my little web site (no I am not giving the url in slashdot). Knowing my own limitations with keeping track of variable names, etc. I would personally prefer a more orderly language like Java for larger programs. And, btw, I have had some experience with COBOL, after trying to learn it for a quarter I dropped out of college and didn't get back into programming for ten years.

Re:Much Thanks to Mr. Wall

[bratwiz]

Especially when writing OO modular code. Its way to easy to become a $self abuser.

Re:Much Thanks to Mr. Wall

[chromatic]

Knowing my own limitations with keeping track of variable names, etc. I would personally prefer a more orderly language like Java for larger programs.

Hmm. How does Java make it easier to keep track of variable names? My best guess is that Foo foo = new Foo(); is a mnemonic device. "Oh, I guess it must really be a Foo!"

X Year Anniversary

[AveryT]

Sigh. I wish people would stop saying that. It's "20th Anniversary." Anniversary MEANS YEARS.

Re:X Year Anniversary

[Anonymous Coward]

anniversary (n'-vûr's-r)
n., pl. -ries.
The annually recurring date of a past event, especially one of historical, national, or personal importance: a wedding anniversary; the anniversary of the founding of Rome.
A celebration commemorating such a date. ----------------------

Re:X Year Anniversary

[AveryT]

That's what I said.

A language where bless is a basic operation

[patio11]

But the cursing you get for free. And, bonus points, if you write it out in newspaper style it will execute. "Who the $_|&%.$# decided they were too cool to use lettes in the names of their variables in a 6,000 line program?"

(Yep, I really did hit an executing program on the first try. I think it evaluates to null for all input strings but $_|&%.$# if I'm going to try to parse Perl code without getting paid money for it.)

Happy Anniversary!

[ekimminau]

Happy Anniversary, Larry!

Everyone, please don't forget to wish a Happy Anniversary to Randal L. Schwartz and Tom Christiansen. The three of these gentlemen have created the Perl we all know and love.

I have been blessed with the opportunity of going to week long Perl classes with all 3 of these (well, Tom & Randal. Larry just came for lunch :) gentlemen/gods.

Merry Christmas one and all!

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

[glwtta]

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").

Thus proving that you have never, ever, programmed in Perl. But I'm glad that you can pass these dicta on what dynamically typed languages should and shouldn't do.

For the record: when a string being used as a number can't be parsed, it's 0 (yes, it's up to you to decide if you need to check if the string is a valid number - terrifying!). You cannot get an "unexpected data type", Perl scalars are polymorphic, they are strings or numbers (or references) based on context. So, with:

$a = "foo";
$b = $a + 0;
$c = $a . "";

$b is 0, but $c is still "foo".

The original point was that since context decides how scalars are interpreted, addition isn't overloaded as concatenation for strings, but is a separate operator.

Yes, many people do find that to be more intuitive, and that's why this is useful.

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.

Re:Implicit vs. explicit parsing

[ajs318]

Oh, and I forgot: There are no integers or floating-point numbers, just numbers. I don't want to have to call a function to convert "3" into "3", and I definitely don't want to have to call a function to convert 3 into 3.0. That's another matter for the computer to think about. Back in the days of BASIC on 8-bit micros, it might have mattered; integer arithmetic was appreciably faster than software floating-point and saved a byte (if you had 32-bit integers, or three if you had 16-bit integers) in your symbol table.

Re:Implicit vs. explicit parsing

[Anonymous Coward]

That operation is explicitly casting to a number. Maybe learn perl first?

my vote goes to a hello_world() builtin ...

[Lazy Jones]

it would make Perl's the most impressive "Hello, World!" program ...

Re:my vote goes to a hello_world() builtin ...

[snoyberg]

it would make Perl's the most impressive "Hello, World!" program ...

Sorry, but that has to go to HQ9+

New perl additions more than whole of c++

[master_p]

I am not touching Perl for any purpose. I'd rather do it in machine code than Perl... :-)

Re:New perl additions more than whole of c++

[Krishnoid]

When you'd rather do it in Acme::Eyedrops by hand, then I'll be impressed.

Favourite quote

[Artichoke]

The regular expression construct (?p{}), which was deprecated in perl 5.8, has been removed. Use (??{}) instead

" A lot of the other changes have "go here for more info" - but not this one :) I love Perl :)

Features and whatnot.

[fahrbot-bot]

I gave a quick look through the Features list and have the following comment:

Larry, developers; stop smoking crack.

Do we really need the "defined-or" operator? Is the "given" operator really any simpler than the numerous known switch examples? Recursive Patterns? My head almost asploded parsing the example. Stop doing things, just because you can. Do something else -- and I don't mean that franken-project Perl 6.

Ok, no more coffee for me today. :-)

Re:Features and whatnot.

[fbriere]

Do we really need the "defined-or" operator?

I would bet that most Perl programs/modules will exhibit erratic behavior when supplied "0" as an argument, due to the common use of "||" or "||=" to provide default values. Although "//" may not be earth-shattering, it certainly has a purpose.

(Me, I'm still waiting for the "call a method on this object if defined" operator. Oh, how I long for "$foo->bar()->baz()" not to fail if bar() returns undef...)

Re:Features and whatnot.

[TheDauthi]

Defined-or? That's a useful addition. It gives you a cleaner way to say:

sub foo {
my $self = shift;
my $var = defined($_[0]) ? shift : '17';
}

Re:Features and whatnot.

[chromatic]

Me, I'm still waiting for the "call a method on this object if defined" operator.

Are you looking for eval BLOCK around the chained method calls?

Re:Features and whatnot.

[chromatic]

Stop doing things, just because you can. Do something else -- and I don't mean that franken-project Perl 6.

I was going to work on Perl 6 today, but because some random jackass on the Internet thinks I shouldn't....

Re:Features and whatnot.

[fahrbot-bot]

I was going to work on Perl 6 today, but because some random jackass on the Internet thinks I shouldn't....

Dear Chromatic,

Thank you.
Now enjoy the Holiday Season.

Sincerely,
- Some Random Jackass :-)

Re:Features and whatnot.

[chromatic]

You're welcome, but I think I'll work on it anyway. You can use it when we're finished, if you like!

Re:Features and whatnot.

[fbriere]

Are you looking for eval BLOCK around the chained method calls?

No, it's just the undef case that I want to handle differently. What happens is that I'm chaining several method calls that return either an object or undef. So, for example, I want to test $me->boss->wife->is_cute() while accounting for the possibility of unemployment or celibacy. This will either turn into an ugly one-liner with lots of "&&" and redundant calls, or the use of temporary variables.

I guess I'm wishing for some sort of auto-vivification similar to what is done for arrays and hashes.

My own desperate solution was to create a small class that returns undef via AUTOLOAD, as well as a function that creates such an instance if its argument is undefined. This results in something like u(u($me->boss)->wife)->is_cute() which, albeit unappealing, is at least somewhat bearable.

(Although, given the apparent lack of such a feature in any OO language I know, I do sometimes wonder if I'm being silly.)

P.S.: Thanks for making Perl testing fun!

Re:Features and whatnot.

[chromatic]

So, for example, I want to test $me->boss->wife->is_cute() while accounting for the possibility of unemployment or celibacy. This will either turn into an ugly one-liner with lots of "&&" and redundant calls, or the use of temporary variables.

I saw a lightning talk about overloaded undef last year at YAPC::EU, so you might track down Juerd Waalboer (perhaps on PerlMonks) to see if he can share his trick. If you absolutely must call all of those methods, that may work.

If it were me, I'd still write eval { $me->boss->wife->is_cute() } and check for the exception, though.

Re:Features and whatnot.

[thospel]

Yes. defined or is one of the most useful practical changes of perl 5.10.
Maybe it's clearer when you realize it will mostly be used as "or otherwise use this default". Now a lot of existing code uses || for that purpose, and too often people don't realize that doesn't work the value was 0. But handling the 0 case properly makes the code very ugly.

Re:Features and whatnot.

[fahrbot-bot]

Ya, I can see using "defined-or", though I understand there can be some confusion between that and an empty regexp, but I intended my post to be humorously rather than actually critical.

I have noticed, however, that "defined-or" is the only one of the three items I mentioned that anyone's bothered to defend. Not so much chatter on "given" or "recursive patterns". :-)

Sometimes something is "good enough" and more isn't really more or better, or at least not enough to warrant the work and/or potential headaches. Perl 5.8 probably fits this category. I'm OK with .10, but 6? I don't know if it's worth it or that it matters for the many things which Perl is used. But, hey, to each their own.

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:Bold perl hackers, I salute you

[bratwiz]

Geez, you got that right. Why couldn't they just stick with switch / case ???

what the FUD

[rubycodez]

Good grief, ever hear of Pirate (Python to Parrot compiler)? partcl (tcl to parrot)? Git yo azz ovah to parrotcode an edumacate yo-self! most of Perl 6 is runnable by Pugs, which can compile Perl 6 into Haskell, Javascript or Perl 5. Now I'm a Perl 6 detractor in that I mock the way Larry can't resist throwing in every shiny thing he sees in other languages, he should have got focused and finished years ago. But I still follow the news so I must care in same way relative cares about some distant member of the family destroying their life with a drug habit. Parrot has many cool ideas in and of itself, educational to study it

Re:what the FUD

[Ed Avis]

Of course I've heard of those things - what I meant was that (AFAIK) there are absolutely zero plans from the Python community to adopt Pirate as their runtime environment or even one of the supported runtimes along with CPython and Jython. I'd be delighted if it all works out and the different scripting languages can find a way to play well together (after all, the semantics are similar enough for most useful libraries to be used across languages) but I am not optimistic.

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.

Mod Entire Thread +5 Funny

[HotButteredHampster]

Jeez. Three times I burst out loud laughing reading the comments in this thread. The last time almost ended with coffee sprayed on the monitor. I know it's Perl and there is lots of material for comedy, but this has been the best read in a while.

Props y'all.

HBH

Re: Defined OR

[Evets]

From perlop:

Note that it's possible to confuse Perl into thinking // (the empty regex) is really // (the defined-or operator). Perl is usually pretty good about this, but some pathological cases might trigger this, such as $a/// (is that ($a) / (//) or $a // /?) and print $fh // (print $fh(// or print($fh //?). In all of these examples, Perl will assume you meant defined-or. If you meant the empty regex, just use parentheses or spaces to disambiguate, or even prefix the empty regex with an m (so // becomes m//). I can't think of any instances where I ever used code that would be ambiguous, but it helps to spread the word. I can imagine this is going to be a major headache for some people trying figure out why their old code doesn't work.

Double digit version #s aren't alphanumerically OK

[Peter Cooper]

In a list of files, etc, Perl 5.10 will come between 5.1 and 5.2, which makes no sense at all.

The Parrot Weekly Team meeting

[sam_vilain]

The Parrot Weekly Team meeting ... is called the "Parrot Sketch" :)

In an unrelated note...

[Anonymous Coward]

Does the fact that you can now have nested patterns in regexes mean that we can actually, correctly strip out bad HTML with regexes now?

Please note, I did NOT use the word "should" or the phrase "should we" anywhere in that question. I just read the information about the changes and became frightened because there are now even more dark, scary corners of the regex world to try to wrap my mind around when I thought I was mostly safe there, except for a few dusty corners...

Re:In an unrelated note...

[nuzak]

Recursive patterns (which were in perl before 5.10, there's just nicer syntax sugar for them now) effectively turn the NFA of a regular expression engine into a pushdown automaton, meaning they can count. This makes them able to parse balanced expressions, so yes technically you could parse HTML with a regex. In fact, I believe they're turing-complete, even without the benefit of /e.

Whether you'd actually want to is another matter. 5.10's regex engine may not be recursive when backtracking, but when you tell it to go recursive, one way or another it's going to use a pretty big stack to parse anything even moderately deeply nested. There's plenty of better-suited parsing modules on CPAN, and now with the extensible ~~ operator, we might even get to see some of them used more liberally. Me, I can't wait to make it work with xpath.

You've been reading the Perl 6 Spec haven't you?

[sam_vilain]

Well, did you see the syntax for one Perl 6 concurrency design? contend { maybe { this() } maybe { that() } }

Much better than silly words like semaphore and mutex. Good semantics, too, but that's hard to impress on people who don't think that there are any basic programming constructs you can't do with C :-).

Re:Double digit version #s aren't alphanumerically

[sfjoe]

In a list of files, etc, Perl 5.10 will come between 5.1 and 5.2, which makes no sense at all.

You do understand that this is Perl we're talking about, right?

Re:Double digit version #s aren't alphanumerically

[chromatic]

Perl version numbers are dotted triplets, much like IP addresses can be dotted quads. If there were such a thing as an official version number, it would be 5.001000.

Re:Double digit version #s aren't alphanumerically

[irc.goatse.cx troll]

Sort by date. HTH

Oh,don't be modest ...

[freaker_TuC]

You like to touch Perl ... but only at the soft side ;)

If I have to pick inbetween C, Perl, ASM or Pascal I'll be picking Perl for it's difficult and yet simple language :p

Consistancy FTW!

[pedestrian crossing]

I've seen poor programmers get confused, and I've seen code that proved they were confused when they wrote it, but I've never seen Perl get confused.

Bingo! That's what I love about Perl. No unexpected surprises, it Just Works the way it is supposed to (as thoroughly explained in the camel book).

Re:Double digit version #s aren't alphanumerically

[RAMMS EIN]

``Double digit version #s aren't alphanumerically OK''

Right. And this being Perl, I don't understand why they didn't just continued with the next ASCII character, `:'.

``In a list of files, etc, Perl 5.10 will come between 5.1 and 5.2, which makes no sense at all.''

Ah. That's why...