See the parrot FAQ, specifically the question "Why your own virtual machine? Why not compile to JVM/.NET?"

The restrictions on both the CLR (patent worries) and the JVM (Sun has a weird definition of portable that doesn't cover many platforms) make both rather inappropriate from the start.

I know Active State has made some progress with running Perl 5 in the .NET vm though the $$ price is rather... well, I'm not able to justify the price to the fiancee (soon to be wife in a month from now).

jdtoronto

Any pointers? The ActiveState Perl Dev Kit, containing the PerlNET compiler seems to be well and kicking. I guess you mean the Visual Studio plugin that they used to have, but that's not really related. It was just an extension for the Visual Studio IDE.

BTW, ActiveState PerlNET does NOT compile Perl5 to the .Net bytecode. It just packs the Perl sources to an EXE or DLL and provides the linking between .Net bytecode and Perl , but the Perl code is still compiled and executed by the good old perl engine.

Jenda


Support Denmark! Defend the free world!

I've worked with CLR and YARV people to explore techniques in targetting them, and indeed both will probably become reasonable targets in their next release. I also plan to find some JVM people and see how much of JRE6 stuff we can use, but I'm not sure it's ready for Perl 6 yet.

As for Haskell: Pugs and Darcs have pushed GHC to improve its efficiency as a imperative VM, so it is becoming a really viable target for Perl 6.

However, with all that said, I think for the next few years, Perl 5 remains the most practical and robust VM to target, which is why Pugs now embeds Perl 5 by default. :-)

NOTE: Emphasized text indicates an edit.

I notice that none of the people excited about using Parrot (including the FAQ-writer) seem to have addressed issues like maintaining a run-from-source availability of code like we currently have. Once you start requiring compilation to persistent bytecode packages, you lose the ability to just read the program any time you like. I've gotten to like that quite a lot over the years, and I'll miss it.

I understand why Parrot, rather than JVM or .NET/CLR — what I would like to hear more about is why JIT/interpreter implementation has suddenly become a second-class citizen at best, and more likely a non-citizen entirely.

Once you start requiring compilation to bytecode, you lose the ability to just read the program any time you like. I've gotten to like that quite a lot over the years, and I'll miss it.

I expect that you'll rapidly see the evolution of reverse compilers - just like you did in the Java world - much easier to implement with high level VMs like Parrot.

That's a comforting thought, and I suspect you're right, but there's still no substitute for running directly from source code.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

Once you start requiring compilation to persistent bytecode packages, you lose the ability to just read the program any time you like.

I don't understand what you mean. You can run bytecode or source code with Parrot right now. I've done both today.

I'm sure a lot of people paying for Perl will require bytecode compilation, especially if they're planning to distribute it as product, so the statement stands as written to some extent. I was not, however, aware that Parrot would run directly from source. I was under the impression it was a bytecode-only VM. Thanks for the info.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

My understanding of Perl 6 is that the perl code will be compiled to a byte code and run in the VM runtime. The idea is that the vm will be able to run just about any language that can be thrown at it given that there is a parser available.

That looks like a pretty accurate description of Parrot's goals, but Perl 6 has a separate set of goals (which are, naturally, not entirely nailed down, and subject to change). One of those is that it should be a language that can, and hopefully does, have multiple implementations. This means the implementation is no longer the spec, as it essentially is for Perl 5.

The idea has led to many interesting developments. One of the directions that I've recently been excited about is the 6-on-5 stack. That is, an increasing number of bits and pieces of Perl 6 running on Perl 5. There are a lot of benefits I can see to this, and the approach seems very logical and sane. There are already fruits borne of the effort, too, which is a very good sign (for example, see Moose).

All in all, while the Perl 6 road has been rocky, I think in the end it will produce some good stuff.

There are a lot of benefits I can see to this, and the approach seems very logical and sane.

... except for the reasons why not to build Perl 6 on the Perl 5 VM which are even more valid in 2006 than they were in 2000, namely that Very Few people know how or want to work on the Perl 5 VM and that the Perl 5 VM is complex and obtuse and sprawling and nearly impenetrable to people who don't already know how to work on it.

(Then again, Simon Cozens and I figured out a way to make continuations work with it and Nicholas and Rafael seemed to agree that it's possible.)

except for the reasons why not to build Perl 6 on the Perl 5 VM which are even more valid in 2006 than they were in 2000

Indeed. I didn't mean to imply that 6-on-5 was a good Long Term Solution, just that it was something I thought was a nice consequence of the goal not to be tied to any particular implementation.

Don't you realize how some people like programming a virtual machine like parrot? If they do, why take away their joy?

I don't think the OP is asking why people are allowed to make a VM. He's asking why Perl 6 is going to promote it's own VM as the primary platform.

As you can see in the FAQ linked above, Perl 6 can potentially run on any VM (even one I might decide to write in my spare time). But the primary target is Parrot.

I think, Parrot is good for evolutionary reason. The world has never seen a vm specifically designed for dynamic language. And with all those new sparkling features in Perl 6, Parrot people will have to design the ultimate vm for dynamic language. Therefore, if Parrot fails, it will become a very good learning process. But if it succeeds, I'm sure it will become a reference implementation for future vm's, and we will surely learn a lot from it.

I wish the best of luck for the Parrot people. I'd like to help but I haven't got time yet.

The world has never seen a vm specifically designed for dynamic language.

Oh, the young'uns, forgetting all about Smalltalk in 1980. {sigh}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Oh, the young'uns, forgetting all about Smalltalk in 1980. {sigh}

Not to mention Lisp :-)

Hell - if you've got a Linux box you can still play with Poplog. Lisp, Pop-11, ML & Prolog all compiling down to the same stack based VM, which was in turned compiled down to a RISCish register based VM, which was in turned compiled down to machine code.

Kid's eh? :-)

Looking at what Dan Sugalski has been up to recently with tornado, could it be there's another potential Perl 6 VM in the making there? From it's intro.pod;

Tornado's a virtual machine geared towards multithreading and vector operations.

Actually have yet to figure out what the point of tornado is, and whether there's any real potential there. Insight appreciated.

Actually have yet to figure out what the point of tornado is, and whether there's any real potential there. Insight appreciated.

What's the point? Well... does it really need a point? It could, after all, be art.

Whimsey aside, Tornado's a niche VM, by design and intent. Most people don't have the need to run arbitrary small programs against large quantities of data, or to run massively threaded programs in a restricted environment, potentially across a large number of machines (distributing the programs with the data).

If that's the case, it's a cute little indulgence by a guy with some free time and a few things he feels like fiddling with.

On the other hand, there certainly are some areas where what it does (when it's finished, potentially before) can be quite handy.

• It should be good for doing multiple interacting agent work for simulations, where the massive (portable) threading is a win.
• It should be good for doing real physics simulations where the threading, vector, and distribution should be a win.
• It should be good for doing configurable crypto, where the decryption program is shipped with the thing to be decrypted. (And really, would you allow arbitrary binary code to run on your machine? In a sandboxed, restricted VM you probably would)
• It should be good for writing game engine bits. NPC/creature AIs, user-written agents or actions, or suchlike things. (Every object could, potentially, be its own little program interacting with the universe)
Definitely niche, no question. But it's an interesting niche...

Most people don't have the need to run arbitrary small programs against large quantities of data, or to run massively threaded programs in a restricted environment, potentially across a large number of machines (distributing the programs with the data).

Not today, no, but more than yesterday and still more tomorrow.