Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Perl Programming Java Technology

Parrot 0.1.1 'Poicephalus' Released 224

Posted by timothy from the link-fever dept.
Pan T. Hose writes "The long awaited release of Parrot 0.1.1 "Poicephalus" has been finally announced on perl.perl6.internals newsgroup and perl6-internals mailing list simultaneously by Leopold Toetsch followed by an announcement on use Perl by Will Coleda and now also on Slashdot." (Read on for a list of changes since the last release, as well as a number of useful links.)
Pan T. Hose continues "The most important changes since the previous version 0.1.0 (code-named 'Leaping Kakapo' and released in February) are:
  • Python support: Parrot runs 4/7 of the pie-thon test suite
  • Better OS support: more platforms, compilers, OS functions
  • Improved PIR syntax for method calls and <op>= assignment
  • Dynamic loading reworked including a "make install" target
  • MMD - multi method dispatch for binary vtable methods
  • Library improvement and cleanup
  • BigInt, Complex, *Array, Slice, Enumerate, None PMC classes
  • IA64 and hppa JIT support
  • Tons of fixes, improvements, new tests, and documentation updates
The amazing project which no one had any idea would go so far from the original April Fool's Joke by Simon Cozens (also posted on Slashdot on April 1, 2001) to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few) is now available for download from CPAN and via CVS. Those who are not up-to-date with Perl 6 mailing lists can read This Week in Perl 6 weekly summaries by Piers Cawley to have some idea on how's the project been going in the last two years. It's important to read Apocalypses, Exegeses and Synopses together with RFCs and Parrot Design Documents for better understanding of the underlying rationale, especially the superiority of register-based Virtual Machines (like Parrot VM) over stack-based one (like JVM) for modern (dynamically-typed) OO languages with multiple inheritance, operator overloading, traits, roles and much, much more. Parrot Docs, FAQ and examples are also very helpful. This is a very important step in the direction of Perl 6 which we are all looking forward to."
This discussion has been archived. No new comments can be posted.

Parrot 0.1.1 'Poicephalus' Released More

Parrot 0.1.1 'Poicephalus' Released

Comments Filter:

  • preview for readability before submit, perhaps? (Score:3, Funny)

    by lambent ( 234167 ) on Wednesday October 13, 2004 @03:07PM (#10516797)

    Holy run-on sentence, Batman!

    • Re:preview for readability before submit, perhaps? (Score:5, Insightful)

      by Amiga Lover ( 708890 ) on Wednesday October 13, 2004 @03:26PM (#10517026)
      I'd like a preview that contains a tiny piece of information on just what Parrot is. I can google it, yeah, but I could also google and get just as much info as any story on slashdot if I just read

      "New version of Parrot released".

      It's reminiscent of badly written man pages, where a command has info like:

      -n, --nfrtrt
      enables use of nfrtrt.

      And says no more. It's just a tiny addition, it would really help, and that's what we have editors for!

    • Readability? (Score:4, Funny)

      by Pan T. Hose ( 707794 ) on Wednesday October 13, 2004 @06:51PM (#10518998) Homepage Journal

      Holy run-on sentence, Batman!

      That's funny you mention it because quite frankly I did preview it and in fact it was not until then when I decided to turn a list of comma separated values into a bullet list as well as brake the second then single-sentence paragraph into three separate sentences exactly because I was somewhat concerned readability-wise--though to be fair braking it into two parts and adding "Read on for a list of changes since the last release, as well as a number of useful links" we owe to Timothy, who has also removed quite a few important links for some reason--but nevertheless I am quite surprised if not outright disappointed that anyone who is even remotely interested in Perl 6 might lack basic linguistic skills to parse a paragraph of simple English, however on the other hand I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace.

  • Actually, all jokes aside it looks like a valiant try.
  • I am especially interested in python support. I love python but it is some times a tad bit slow. I've seen lots of interesting initiatives to really improve performance (the starkiller python to C++ "compiler" for example), and am now very curious to see how good this one will perform. Besides, it would be quite funny to have perl and python united :-)

    • Re:python performance (Score:5, Interesting)

      by Pxtl ( 151020 ) on Wednesday October 13, 2004 @03:18PM (#10516948) Homepage
      The problem is that Python's slowness isn't just from the interpreter, but the nature of the language. Notice how two similar objects don't require an interface to be used in the same way with the same methods? Because of that it will be hard to store members as anything but dictionaries, which are necessarily slow.

      Either way Parrot will be an improvement, allowing shared Python/Perl/Ruby libraries, importing pure-python modules nicely, and most importantly: maybe we can finally sandbox Python. Rexec has been dead a long time, and Python is currently unusable as an embedding language without a lot of hacking because of that.
      • What do you mean by unusable as an "embedding language" because of a lack of sandboxing?

        I realise there could be some applications where you want to sandbox embedded python - e.g. in webbrowsers, but surely not for most applications...
    • If Psyco [sf.net] isn't on the list of the initiatives you've checked out, I suggest you have a look at it. It speeds up most Python code by 50%-100%, and can improve performance more than tenfold in some cases (for example, tight loops that only do integer math or involve many function calls). And it's really easy to use, you just start it from inside your code (import psyco; psyco.profile()) and it automagically replaces the Python interpreter core in runtime!

      As for the article topic, I'm really enthusiastic abou

  • why? (Score:3, Interesting)

    by spectrokid ( 660550 ) on Wednesday October 13, 2004 @03:09PM (#10516825) Homepage
    Why a new VM? Jython showed it is possible to "recycle" the java VM. Can anybody explain why this is better?

    • Re:why? (Score:5, Informative)

      by BridgeBum ( 11413 ) on Wednesday October 13, 2004 @03:13PM (#10516870)
      Performance.

      From the FAQ:

      Why your own virtual machine? Why not compile to JVM/.NET?
      Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

      The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

      So you won't run on JVM/.NET?
      Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.

    • Re:why? (Score:3, Informative)

      by ThisNukes4u ( 752508 )
      For one, the JVM is stack-based, which makes it hard to implement in hardware, while Parrot is stack-based like CPUs. This also has performance advantages for various reasons.

      • Re:why? (Score:2, Funny)

        by Enucite ( 10192 )
        "the JVM is stack-based ... while Parrot is stack-based ..."

        Oh, that explains it. Thanks.

        • Re:why? (Score:5, Informative)

          by GooberToo ( 74388 ) on Wednesday October 13, 2004 @04:18PM (#10517617)
          I think he means register based.

          From one of the examples, we get:

          set I1, 1
          set N1, 4.2
          set S1, "Resting"
          print I1
          print ", "
          print N1
          print ", "
          print S1
          print "\n"
          end

          Which seems to indicate a heavy use of register type functionality. This will map to hardware (thusly faster) better, much more so than a stack based (java) VM implementation. Especially for dynamically typed languages (perl, python, ruby, etc).

          • Re:why? (Score:3, Informative)

            by miguel ( 7116 )
            The meme of `register byte code will map nicely
            to hardware' is also rubbish.

            For one, the type of the registers in parrot do
            not map to the underlying hardware types (ints
            and floats is all cpus can do), and second of all
            not every CPU has all the registers parrot has.

            So if you generate code that uses 32 registers,
            you would still need to map to 6 registers on
            Intel.

            To make things worse, register allocation is
            one of the hardest problems in a compiler, and
            the one that probably has the most impact on the
            performa

            • The meme of `register byte code will map nicely to harware' is also rubbish.

              True, but the meme of 'stack machines are easier to tune because are conceptually simpler' is also a false.
              The fact is that optimizing an VM is difficult, hell, after 50+ years of computer science we are stil trapped on a stack/register dicothomy!?.

              • Re:why? (Score:3, Informative)

                by miguel ( 7116 )
                Notice that stack-based operations are nothing
                but a linear representation of a tree.

                It is in effect the output that you would get from
                serializing a tree, so you turn internal compiler
                representation, like for example the following
                tree:

                (assign var (add 1 2))

                into a series of stack operations:

                push 1
                push 2
                add
                var_address
                store

                You can certainly "interpret" those bytecodes,
                and for an interpreter it is debatable if there
                is a performance improvement or not.

                But for any self respecting JIT, the above is
                only an MIR

                • Optimization is a complex issue, for instance, you can say, 'ok, in the end the program has to run on a given platform, so we can almost forget about intermediate representations, and focus our effort to create assemby code and then apply know platform optimizations'.

                  On the other side, you can say 'because we don't know apriori what the running platform is going to be, we better try to reformulate the program on his most optimistic expression, and only then proceeed to create assembly and re-optimize the c

            • The meme of `register byte code will map nicely
              to hardware' is also rubbish.

              I don't believe this to be a true statement at all. It appears that they are using "typed registers", if you will. The optimizer is free to load ints and longs into registers while it can move pointers to strings into registers equally well. In other words, it maps VERY well to the underlying hardware.

    • To ellaborate on the FAQ (Score:5, Informative)

      by pavon ( 30274 ) on Wednesday October 13, 2004 @03:54PM (#10517361)
      As it said, Python, Perl, Ruby, Smalltalk, Lisp, and most of the languages targeted by Parrot are dynamically typed and have dynamic message passing (method calls). This means that typechecking is done by the run-time environment, not by the compiler. Likewise, it is not known untill runtime which if an object has a method. Therefore, the runtime has to do a fair amount of checking (mostly symbol table lookups). If you were to do this with a VM designed for static languages (JVM, .NET) that do not do this checking for you, then you would have to implement all of it as byte-code in the VM - in effect you would be writing a big chunk of a Perl interpretor in Java.

      This approach would inevitably be slower than the existing Perl 5 interpretor, while the Parrot approach has managed to be significatly faster than the current Perl 5 interpretor. The reasons are that 1) all of the runtime checking is highly optimized native code 2) after the complex perl code is translated into a simpler form, the traditional compiler optimizations can be applied to the code.

    • Re:why? (Score:5, Insightful)

      by ajs ( 35943 ) <{moc.sja} {ta} {sja}> on Wednesday October 13, 2004 @04:59PM (#10518070) Homepage Journal
      The primary reasons for Parrot are:
      • Language neutrality
      • Support for very high level language inter-operation (e.g. you can sub-class a Python object in Perl and call a method on the Perl class that gets invoked fromt he Python class).
      • Deep support for multiple character sets, not just ASCII and Unicode.
      • Perl 6
      The last item might seem odd, but Perl 6 is definitely a language which needed some serious support. It's very ambitious, and a VM that didn't support its needs as completely as Parrot does would have exponentially complicated writing a compiler for it.

      That said, the combination of the two promises to be one of the most powerful development platforms released to date.

  • Awesome april fools joke (Score:4, Funny)

    by Anonymous Coward on Wednesday October 13, 2004 @03:11PM (#10516853)
    For those too lazy to click on the april fools links, the programming examples were some of the funnies things I've seen.

    =====
    Show us some Parrot code.

    GvR: [...]

    # copy stdin to stdout, except for lines starting with #
    while left_angle_right_angle:
    if dollar_underscore[0] =eq= "#":
    continue_next;
    }
    print dollar_underscore;
    }

    [...]There's more than one way to do it, right, [...]

    LW: [...]

    while(@line = Sys::Stdin->readline()):
    continue_next if $line[0] =eq= "#":
    print @line;
    }
    ============
    From the minute I saw that I thought I'd love the language. Truely shows the power of open source.

  • what is parrot? (Score:5, Informative)

    by egott ( 81357 ) on Wednesday October 13, 2004 @03:12PM (#10516859) Homepage
    from the faq:

    Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.

    • Re:what is parrot? (Score:4, Informative)

      by Kristoffer Lunden ( 800757 ) on Wednesday October 13, 2004 @04:38PM (#10517837) Homepage
      Not only is it supposed to support those languages and more (from Forth to Java via Lua and Lisp ;-), it is also meant to be easy to target with your own custom languages - in fact, several such beasts have been spotted on the mailing list, some of them very impressive already.

      Moreover, libraries will (hopefully?) be possible to share code, especially libraries, across languages(!) so you could write your programs in ruby or python and still have access to all of CPAN, and vice versa. Talk about code reuse! :)

      One of the big things I see a use for this, maybe to some extent already now, is scripting for game libs and engines. Those often have support for one or several languages, homebrewn or regular, in various stages of completion, with or without SWIG and it is all too often a huge big semi-maintained mess. With parrot bindings, you could use any supported language and possibly even mix - different languages are better at different things. Moreover, you could implement your own, custom languages to fit special tasks. Want a language that can handle 3d calcs, physics and AI interactions in a natural way? Just do it and reuse it for the whole series. :)

      Ok, so maybe I am dreaming a bit, but having a powerful interpreter *made* for writing languages for, easily embedded, cross-platform and open source is something to really look forward to in so many ways! I just wish it'd hurry up getting there... and yes, I guess sometime I'll have to stop talking and start contributing myself. ;-)

      And oh, there are already some simple games written using parrot and SDL, check em out. And do what I also should, join the effort! :)
    • There are 10 kinds of people: Those that understand trinary; those that don't; and those that don't care


      Wouldn't that be "ternary", or am I mistaken?

  • Explanations Please (Score:3, Insightful)

    by SomeGuyTyping ( 751195 ) on Wednesday October 13, 2004 @03:17PM (#10516935) Homepage
    When posting software projects (especially those whose version number 0) please add a quicky bit about the package for the lazy amongs us
  • ...that would compile Ruby programs into intermediate compiler code so they could be run on Parrot.

    He's done a few releases and appears to be making good progress here [rubyforge.org].

  • I just started going through the joke links on the O'Reilly Parrot [oreilly.com] pages and started to wonder...

    What happens to the joke pages when (if?) Parrot becomes mature enough to actually warrant a book?

  • Python support? (Score:5, Funny)

    by WillWare ( 11935 ) on Wednesday October 13, 2004 @03:44PM (#10517207) Homepage Journal
    Python support: Parrot runs 4/7 of the pie-thon test suite

    Python 2.3.3 (#1, May 7 2004, 10:31:40)
    [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 4 / 7
    0
    >>>

    Ouch!

    Now I'll get my thumb out of my ass and pass along my gratitude to everybody who's worked on Parrot. An open-source VM, particularly one targeted at existing open-source languages, is a mitzvah. It even has the nice side benefit of creating a little commonality between the communities. Thank you.

  • pasm rules (Score:3, Funny)

    by Anonymous Coward on Wednesday October 13, 2004 @03:44PM (#10517212)
    Parrot assembler is the nicest asm dialect I've ever had the pleasure to work with. I'm looking forward to a new mod_parrot so I can do enterprise web apps, the way they should be done; in asm.

    I spent far too long yesterday playing with parakeet, definately some interesting things happening in parrot land.

  • Another funny virtual machine (Score:4, Interesting)

    by descubes ( 35093 ) on Wednesday October 13, 2004 @03:53PM (#10517343) Homepage
    The Virtual Virtual Machine [inria.fr] is, if I understand correctly, a virtual machine to build virtual machines.

  • A truly interesting project (Score:5, Interesting)

    by Coryoth ( 254751 ) on Wednesday October 13, 2004 @03:54PM (#10517358) Homepage Journal
    Parrot is a very interesting project indeed, and it looks as if it is now starting to seriously pick up steam. What we're looking at here is VM that works, and is optimised for Perl, Python, Ruby, Forth and all those other lovely scripting languages.

    Given all the current debate raging over JVM vs. .NET and Java vs. C# people seemed to have missed Parrot creeping up from behind. Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.

    In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language") has been drastically narrowed to the point where it is increasingly less relevant. The only serious remaining issue is speed - and that's something Parrot can help fix, putting Perl, Python and Ruby code on a similar footing as Java and C# code running on their VMs. You'll take a small hit for using a higher level language, but it won't be as drastic as it is now.

    Maybe all that GNOME discussion about .NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.

    Jedidiah.
    • Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.

      You know, I never thought of that aspect of it. That is certainly exciting.

      +1 Insightful!

    • Maybe all that GNOME discussion about .NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.

      That could be a very nice descision indeed, and something for other libs (whether GUI, game, or whatever) to ponder also: when you are powered by parrot, you suddenly have a lot of potential languages to choose between for development, even your own(!) so you can use the ones most fit for any special task, and you
    • Java's been in release for almost 10 years, .NET for 5 and the Parrot VM has made it to beta yet. So no, its not time to consider Perl/Python/Ruby via Parrot as a very serious choice for doing any high level application programming.

    • ...the gap between scripting languages... has been drastically narrowed

      Not sure what you mean here -- I suspect you mean the gap between scripting languages and traditional ones.

      If so, then I'd like to disagree :-) (And if not, please ignore the rest!)

      While scripting languages have certainly closed the gap in terms of speed, and language features, there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology

      • there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology, security, portability, and especially maintainability.

        You are indeed correct. They are very far apart, since "scripting" languages, whatever they may be, have already long surpassed "traditional" ones in (most of those) areas <g>.

        Of course all the ranting on either side is of no use unless you define a "scripting language" is, since they're as muc
        • I was counting Java on the traditional, large-scale side of things -- in fact, it's one of my favourite languages!

          I know lots of folks round here don't like it much, for various reasons (most of which I'd rather not get into yet more arguments about!). But it does seem to have been designed by people who 'get it', who understand what it's like not just to write little bits of code, but to write large systems, and to maintain them.

          As we've said, you can't enforce good coding, but so many features of Jav

    • In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language").

      I think that not being dependent on another language (including VM written in another language) is what discerns the scripting languages from the umm.. other ones.

      So when the Parrot VM will be written in Perl (and compiled to Parrot bytecode by a Perl-to-Parrot compiler written in Perl and then presumably compiled by a Parrot-to-native compiler

  • Does anyone know why Perl 6 didn't start with the Python VM? It's certainly designed for dynamically typed languages, and is (as I understand it) pretty divorced from the bytecode generator
    • The faq mentions that the python vm is stack-based, and parrot is register-based.
    • In addition to the other responses, there is a fairly serious architectural flaw with the python VM, that is apparently difficult, if not impossible, to fix without either seriously degrading performance or completely rewriting it from scratch (as this project is doing). It is not threadsafe.

      I, for one, consider this a serious flaw that needs to be fixed before the language can be used for serious projects, as it presents a fundamental limit on scalability (adding additional processors will not make your

    • The Python VM is a directy bytecode interpreter. It doesn't do JIT. Trying to retrofit JIT on a interpreter doesn't save you much work.

  • Holy Cow (Score:2, Funny)

    by Anonymous Coward
    I told my perl buddies how perl could affect the readability of their day to day life language usage. Now we have this post as example :)

  • A question (Score:3, Insightful)

    by Hortensia Patel ( 101296 ) on Wednesday October 13, 2004 @04:37PM (#10517819)
    And no, it's apparently not a FA one.

    Will Parrot, at some hypothetical point in the distant future, be able to decouple languages from libraries in the same way that .NET does? This is IMO the most exciting thing about .NET - once new languages are no longer guillotined in their infancy by the "but there aren't any libraries for it!" hurdle, a veritable renaissance in language design becomes possible, and maybe we can finally crawl out of the backward-compatibility tarpit.
    • Yes. That's the whole point of using the same runtime for all three (IIR(eadTFA)C, Ruby will also be supported).

      • Re:A question (Score:4, Informative)

        by multi io ( 640409 ) <olaf.klischat@googlemail.com> on Wednesday October 13, 2004 @07:45PM (#10519430)
        That's the whole point of using the same runtime for all three [languages]

        The point of that is also that you have only one debugged runtime and don't have to write your own for each language.

        A very important fact hasn't been mentioned here: When you compile multiple languages to the same VM, you don't automatically get interoperatibility between those languages. Interoperatibility is a different concept that must be separately achieved, mostly by defining additional rules and standards on-top-of the VM specification.

        For example, look at different C or C++ compilers on Linux/x86. They all compile to the same machine code, but Intel machine code has no concept of "symbol names", "class names", "type names" etc., so, for the compiled codes to be interoperable, they must comply to additional specifications like ELF or some C++ ABI ("name mangling").

        Parrot bytecode may define some or all of those concepts, but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot, so additional conventions to represent those things in Parrot must be agreed upon. The .NET CLS ("common language specification") is another example of such a set of addional rules to provide for language interoperatibility.

        • but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot

          So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.

          • but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot

            So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.

            So much anger...so clueless...

            The parent post was talking about a situation where other languages do run on Parrot but there's still an inte

    • Yes. You should be able to use libraries freely no matter what language they were written in, so python users get to use CPAN, perl users get access to RAA, and so on... it's all bytecode in the end. :)

      Potentially, you might even be able to switch and mix languages mid-file too, though that probably is not useful all that often. ;-) (Evals might be able to give a language as a parameter if I understood it right).
    • Except when you find a bug in some library written in some dead/weird/etc language and all you have is the bytecode...I mean, in theory it sounds great, but when there's a potential for different objects to be implemented in a wide variety of languages, can you imagine the barrier for entry? I mean, python/perl/ruby is one thing, but what about these new 'renaissance' languages?

    • Re:A question (Score:2, Interesting)

      by mewphobia ( 630153 )
      You rock. If i hadn't already commented I would have modded you straight to the top! :)

      The answer, as far as i understand it, is YES! It's going to be bloody brilliant to be able to use the CPAN libraries from any language.

      But it makes me wonder if .net will be microsoft's destruction? If open source oses can run .net then why pay for windows? Microsoft has controlled the market because they have controlled the implementation of the most popular API - win32. Sure, they will try and control their new API,

  • What is a "Poicephalus" (Score:3, Informative)

    by El ( 94934 ) on Wednesday October 13, 2004 @05:00PM (#10518081)
    "The Genus Poicephalus are small to medium sized, stocky birds with short, squarish tails and proportionately substantial bills." I guess it's just your basic African parrot, then. Funny, with the word "phalus" in it, I thought it would be something else...

  • a brilliant project (Score:2, Interesting)

    by dgym ( 584252 )
    With so many open source language implementations around these days, developing a VM that any of them can take advantage of is a fantastic idea.

    One focussed effort on providing efficient JIT compilation will improve performance, and similarly this one layer to address portability could do more to break down OS barriers than java managed.

    I'm excited about Parrot just for that, but if there is any possibility that different languages will be able to make use of libraries written in others, then that wou

    • Re:a brilliant project (Score:2, Informative)

      by chromatic ( 9471 )

      It's not just possible, it's a goal.

      Any existing language running on Parrot right now can use the SDL bindings, if the language has syntactic support for loading the appropriate library and calling class and instance methods.

      As well, Tim Bunce's plans for DBI 2, Perl's almost ubiquitous database module family, includes porting it to Parrot to make it available to any language running on Parrot.

      Everything compiles down to Parrot bytecode, so if your language has the syntax for interoperability, you'll

  • Uhm... (Score:2)

    by wedg ( 145806 )
    I read the topic, and only thought to myself: What the hell is a Poice Phallus? Those perl developers sure are kinky!
  • Sterling Hughes and Thies Arntzen are working on getting PHP to parrot with their project Pint. They want some stuff in PHP and parrot would fit perfectly, but havin access to modules from perl or pythong is a nice extra bonus.

    b4n
  • "Python support: Parrot runs 4/7 of the pie-thon test suite "

    But does Parrot run Perl as of now? ;).
  • I can't wait to include some INTERCAL modules in our applications. Sometimes perl is far to maintainable.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (3) Ha, ha, I can't believe they're actually going to adopt this sucker.

Close