Slashdot Mirror

Is Parrot the same as Perl 6?

No. Parrot is an implementation that is expected to be used to execute Perl6 programs.

--Tom

Well, go right ahead. From the Parrot VM, the Perl6 engine, page:

Can I use Parrot today?

Well, almost. :^) Parrot is in the early phases of its implementation. The primary way to use Parrot is to write Parrot assembly code, described in PDD6.

For more information on Parrot, which will be the Perl 6 virtual machine, and which is register-based, you may want to check out http://www.parrotcode.org/.

I also wonder what the speed of the interpreter is going to be like compared to perl5. Hopefully faster

And I have to lie to do much of anything online.

Within the OS community, I'm completely open with my age. Nobody cares about age--just skills. It's absolutely wonderful. The only other place I get that is in college classes.

But on the rest of the Internet I have to lie. I have to lie to get an instant messaging account, a webmail address, access to a news site, some web space, or a chat room. I have to lie to get API data from Palm, Microsoft and many other companies. Some of these places make it exceedingly easy to lie--for example, one videochat site just has you hit the submit button again, implicitly promising that a parent is submitting th eform this time. In others, you have to jump through hoops to do it. But in most cases it's pretty easy to lie.

It gets on my conscience, though. Every time I lie I feel like a cheat. Every time I pretend I didn't see the "by clicking this button, you agree that you are over eighteen" line, I feel like a bad person. But I do it anyway, because I can't do what I want and need to do otherwise.

I understand that this is necessary because of contract law. However, I think that points to a deficiency in contract law, not in kids.

I haven't thought very long on this issue, but at least one solution comes to mind. It follows the model of child labor laws. Before fifteen (which, incidentally, I think is older than is really necessary) you simply can't work. Between fifteen and eighteen you can work, but with restrictions on what you can do and how long you can do it for. At eighteen, you're free to sell your labor in any way you please.

Perhaps similar provisions should be written into contract law. For example, between age X and eighteen, you can enter contracts unless they obligate you to pay money or do work.

In any case, I believe that the current system is Evil and Wrong. We should fix it instead fo forcing kids to be liars.

Perl 6 should be rather more interesting; it'll be a completely new architecture, with the Perl itself parsed by, um, Perl (5), which will then generate bytecode for the semi-language-independent bytecode engine Parrot, which will execute it (and let the Perl5 'compiler' migrate and become self hosting).

This will allow Perl to concentrate on developing the language rather than the engine that drives it, and even better, let other languages in on the act; want to write your own little language and want it to run anywhere *and* use Perl modules? Code to Parrot bytecode.

This extends to other languages; Python and Ruby bods seem to take it quite seriously, so even if your admins refuse to install $flavour_of_the_month language, you can still grab the backend in Parrot bytecode and target your scripts to Parrot.

And, being Perl, it's sure to end up everywhere. That is, assuming they every actually come up with something that works before the Universe ends :)

* waits for someone to compare it to .NET, only with Perl as the base language rather than C#

> scripting languages (e.g. Perl, Python)

Scripting languages != interpreted languages, and you're right, they're not going away anytime soon.

Languages like Python and Ruby (and even Perl) are moving more towards Java than /bin/sh; they have good, well developed object models, significant standard libraries, excellent stability, powerful syntax etc.

With Parrot they're even moving towards a common runtime, with code developed in one language available to any other targeted at it.

With these languages moving to virtual machines, and with them being either extended or built from the start to support more advanced features like OO/exceptions/{insert favourite buzzword}, they're definately on their way to making dynamic languages (hey, look, ma, another buzzword) a pretty nice alternative/complement.

Oh, and with Parrot being what Perl6 is aiming for, it's virtually guaranteed to end up on pretty much every Unix box on earth. Can you say that about .NET or Java? :)

• Unify theme, i.e. Look & Feel, e.g. base on OS X
  
• Unify component models and/or protocols: KCOP and Bonobo
  
• Unify APIs, e.g. layer Qt on GTK
  

• Allow cross-(hardware)-platform app distribution, so Linux apps can be installed by normal people without compilers on their PDAs etc.
  
• Provide a platform that can compete with .NET and Java in ease of use (GC etc.), reliability (no pointers), security etc.
  
• Can help unify the scripting languages Python, PERL, not forgetting the various LISPs and Schemes such as Sawfish's LISP engine and RMS's Guile.
  

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.

Yes. parrot.

I'm curious to hear what others have to say about Parrot? This VM seems to be optimized for Perl, but will probably be able to handle Python/Ruby rather well. I would be interesting to know why Miguel's Mono chose to back Microsoft's C# instead of our core open-source langauge's Python, Perl, Ruby, etc.

Dan is in charge of the Parrot internals for Perl 6.

Ack. This was an April fool's joke, remember? Perl6 development is partly based around a VM called "parrot" because it should be reusable for other languages, e.g. Python. I don't see any indication on the python home page that they're planning on using it, though. It's a neat idea, but it's a long way from being a "shared backend" for python as well as perl, and the Parrot home page makes it quite clear that its principle use is for Perl6.