Parrot 0.1.1 'Poicephalus' Released

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

Comments

preview for readability before submit, perhaps?

[lambent]

Holy run-on sentence, Batman!

Re:preview for readability before submit, perhaps?

[Amiga Lover]

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!

Re:preview for readability before submit, perhaps?

[Reducer2001]

It says in the "read more" section that it unites perl and python.

Re:preview for readability before submit, perhaps?

[Short Circuit]

Parrot is a virtual machine intended to be flexible enough to be used as a target for Perl 5/6, Java, Ruby, Python, Forth, Z-code...just about anything.

IIRC, it's expected to be primarily used for Perl 6.

It is bereft of life. It is a dead parrot!

[samberdoo]

Actually, all jokes aside it looks like a valiant try.

python performance

[lordofthemoose]

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

[Pxtl]

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.

Re:python performance

[fredrikj]

If Psyco 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 about Parrot and hope it'll provide some competition for Java. Java is OK, but has little to offer compared to Python (except for better run-time speed, though on the other hand it uses something like ten times more memory), and more generally, dynamic typing is far superior to static typing.

Re:python performance

[Ian Bicking]

To the degree that you can know type information statically, you can do many of the same optimizations that OCaml does. Starkiller is a (very experimental) package that does this in Python. Or, you can guess some and then check your guess at runtime, which is what many JITs do, as well as Psyco (another less experimental package for Python). I think Psyco phrases the process internally as partial evaluation -- where you try to pre-calculate any expressions that can be statically evaluated, like if there's the literal expression (1+1), you know that it will always be 2, no matter what else is happening in the system. If you apply this not just to the visible expressions, but also to the vtable (or equivalent) lookups for method access, you get a sort of implicit type inference.

why?

[spectrokid]

Why a new VM? Jython showed it is possible to "recycle" the java VM. Can anybody explain why this is better?

Re:why?

[BridgeBum]

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?

[ThisNukes4u]

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?

[Enucite]

"the JVM is stack-based ... while Parrot is stack-based ..."

Oh, that explains it. Thanks.

Re:why?

[Swamii]

For the uninformed, you can already run Python on .NET Common Language Runtime and Python on the Java Virtual Machine.

Re:why?

[GooberToo]

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?

[Enucite]

Ahh, that makes a lot more sense.
Thank you for clearing that up for me.

Re:why?

[ajs]

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.

Re:why?

[Anonymous Coward]

Why the Java VM? There were other VMs around at the time.

Re:why?

[miguel]

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
performance of generated code.

So now every compiler author is forced to write
a register allocator, only to find out that
parrot will throw away all that information and
redo its own register allocation.

That is why Medium Level IRs do not use registers,
they are too high level to have any real effect.

As for lower-level IRs, most of them assume
infinite registers anyways as a simple way of
"labeling data".

---

Parrot comes with a system that will let
compiler developers not worry about register
allocation: you emit some kind of infinite
register, and a tool produces the IR registers
(which will later be discarded anyways).

Miguel.

Re:why?

[12357bd]

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?

[chromatic]

Why would people who write compilers have to write their own register allocators? I'd target PIR and use symbolic registers that IMCC will analyze and allocate automatically anyway.

That seems to be what the second half of your comment says, but I really don't understand what you mean here. Doesn't any IR have to emit some sort of unique symbols?

Re:why?

[lupus-slash]

IronPython is a demonstration that dynamic languages can run pretty well on mono: the fact that mono/the CLR implement a VM for a statically typed langauge (IL) would make mono not adequate has the same relevance as saying that C is not adequate to write a virtual machine and runtime for a dynamic language because C itself is not 'dynamic'.

As for parrot running some day on top of the JVM or .net: it's possible, but has a number of issues the first of which is that until the parrot internal design has been finalized no such effort can start:-) The other major issue is that currently any language that runs on top of parrot basically needs to be implemented in C, mostly because parrot doesn't provide a nice and powerful implementation language in the same way that, say, C# could be used in mono. This basically means that all the code needed to make a language run on top of parrot is very specific to the parrot C internals and hence parrot will not be usefully ported to any othger runtime that isn't the current C implementation.

There is hope, though, that eventually the perl6 specification will emerge and that it will be possible to implement it efficiently in mono.

Re:why?

[lupus-slash]

I doubt parrot will be implemented in HW any time soon:-)
A virtual machine that is register-based makes for a faster implementation of an interpreter vs a stack-based VM. Of course, if the issue is performance using an interpreter is not ideal:-)
Once you jit the code it doesn't matter much if the bytecode was register or stack based (except that the register based code requires you to make harder and slower analyses of the code if you need to check for type safety, for example if you care about security). Of course a VM that is register-based should not limit the number of registers: that is a limitation of the HW that doesn't need to be imposed on a sw implementation.

What matters instead is that using a register-based VM actually makes for a slower implementation when speed matters. Register allocation is one of the phases of a compiler that takes more time: perl running on parrot would need to perform it two times, first when the perl code is translated to the parrot internal register-based bytecode and a second time when parrot jits the code to native code.
But that is not all: registers in a VM are a global resource and as such, the optimizations that can be applied to the code are limited if the semantics are respected. On the other hand, stack slots are local to the call frame so the jit can make more assumptions about their use. Also, deciding on a call convention becomes a hard task, because the decisions on it can't be changed once finalized (otherwise all the bytecode breaks) . The parrot internal call convention has been changed at least two or three times already and there are proposals to change it again, because call performance is very slow. A stack-based VM doen't have these issues, because changing the call convention doesn't break the existing bytecode and it can be made to map to the HW registers, which parrot can't do with the current design.

Re:why?

[mewphobia]

Deep support for multiple character sets, not just ASCII and Unicode.

Excuse my ignorance, but what can't you do in unicode?

Re:why?

[GooberToo]

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.

Re:why?

[CTachyon]

I'm no expert on all the political nuances, but there are at least two groups of people that can't use Unicode.

The first is a subset of CJK (Chinese, Japanese, and Korean) speakers. CJK support has been a political minefield for years, and Unicode just made it worse. If you're not aware, each of those languages uses Chinese ideograms in its written language (Korean less so today), even though the actual pronunciations are completely different. The first mine is the PRC's creation of "Simplified Chinese" in the 1950's, and whether a character set favors Simplified or Traditional characters determines a broad swath of political implications. A second mine is how many literary characters a character set supports; to properly record classic Chinese literature, you need somewhere near 50,000 code points, but if you're just recording modern communication, you can get by with around 10,000 (Traditional) or 2,000 (Simplified). The latest mine is the Unicode Consortium's attempt at Han unification, which merged all 4 languages (counting Simplified and Traditional separately) into a single list of code points, without regard for the fact that the actual glyphs sometimes varied dramatically between languages; the expectation was that users would have the appropriate font for their local language installed, but it makes using multiple CJK languages (e.g. a list containing both Chinese and Japanese names) difficult at best and sometimes outright impossible.

The second group of people who can't use Unicode are people using languages that aren't in Unicode. Most of these are historical languages being studied by linguists, but there are even a handful of modern languages.

There are also some situations where, although Unicode works, using a different encoding is much more space-efficient. Ignoring the obvious example of the ISO-8859-N family, CJK text is very, very bulky when encoded in UTF-8 (3 to 4 bytes), but is easily represented by fixed-width 2 byte encodings, and sometimes Japanese can even be shoehorned into 1 byte per character (if it's all kana).

Re:why?

[ajs]

Another poster has covered the technical ground far better than I could have, so I'll skip answering your question directly. However, it is useful to note that while Parrot does not place Unicode in the role of sole character set (as, for example, the JVM does), it does use Unicode as the primary interchange format. If two character sets do not have any defined conversions between then, Unicode is used as a fallback (possibly resulting in an exception).

Re:why?

[miguel]

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 (Medium-Level IR) that must be
processed into something else.

The tree is reconstructed from the stack
operations (every JIT does that) and then you run
your standard optimizations, with register
allocation to the target architecture being the
last step of a long chain of operations.

Re:why?

[lupus-slash]

Parrot uses typed registers, yes, but they are not mapped to HW registers (and with the current design that would be very hard to do in an efficient way while preserving the current semantics).
The main issue is whether using a register-based bytecode is any better at helping with executing the code fast once you use a jit. And the answer there is that it doesn't help at all. Except Itanium, all the other arch have fewer registers than parrot, so you can't map them all. If you map a few fixed registers you may miss performance opportunities, because the bytecode could use other registers for the time critical code (note also that the actual number of mappable registers depends on the plaform so you could have ok performance on ppc and terrible performance on x86, exposing HW details to people producing the bytecode).
The only sane option left is to do whole-method analysis and map only the hot registers, surprisingly the same thing jits for stack-based bytecode do. The end result is that having a register-based vm doesn't help at all for this issue.

Re:why?

[lupus-slash]

Why would people who write compilers have to write their own register allocators? I'd target PIR and use symbolic registers that IMCC will analyze and allocate automatically anyway.

That seems to be what the second half of your comment says, but I really don't understand what you mean here. Doesn't any IR have to emit some sort of unique symbols?

The issue is that register allocation is one of the more complex but also more time consuming phases of a compiler (examples of degenerate cases of both can be found in parrot right now, check the threads on degenerate cases for the reg allocator). With the current parrot design a language like perl would create PIR code at runtime and imcc would spend time in the register allocator to map to parrot registers. Later the jit will need to spend again time to map to HW registers (I think the current parrot jit does this only in a very limited way, ie it doesn't actually map parrot regs to hw regs, but only temp values). So again you spend lots of run time doing again register allocation.
Of course you can avoid the last step and just don't do much optimization, but the code will run slowly. The end result is that using a register-based VM didn't help improve performance but it actually hurts it (a register-based design can make for a faster interpreter, but if you want speed you use a jit, not an interpreter).
It would be more sensible if parrot didn't contraint the number of registers, that way at least you don't need to pay for the register allocator in imcc: the register numbers would be simply what most compiler guys call virtual registers, leaving to the jit the duty of allocating them to hw registers as it sees fit.
The register-based design has also an impact on bytecode size: unless they are optimized they are going to take a significant amount of memory and disk space.

Re:why?

[dkf]

You should look at the latest Unicode specs which now allow the encoding of just about every kind of character ever conceived of by humanity (though some are not yet allocated code-points) instead of speculating wildly.

Re:why?

[12357bd]

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

Of course, to take both levels at the same time, and optimze the code acording the 'high level sintax running on that given platform', is the best approach. Unfortunately to use information from both levels conplicates enormously the designs, and sometimes its benefits are not that evident.

We need a higher level of knowledge of hardware, ie curently, there's no difference between creating a low computational cost opcode (say shift), and a high cost one (say mult) both are just numbers, the program creating the opcodes has only euristics to choose between alternate representations, that's why optimization is so hard, because it depends on the idiosincrasies of the goven platfform doing a given piece of code.

I think we need programs that examine/change running programs to learn the best ways to execute the code. VMs are great for that, because we (those examining programs) can change at runtime the code creation procedures, and profile the results to extract useful information to be applied in succesive generations/versions.

Re:why?

[CTachyon]

I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane is getting in the newest specs -- hell, the undeciphered Indus valley script made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).

Re:why?

[GooberToo]

Interesting. Thanks for the clarification. I had assumed, register assignment, at hardware level, would be implemented via a per architecture optimizer via the parrot-jit-like technology. Therefore, allowing for optimial performance on each of the platforms that parrot ran on. Likewise, I assumed that architectures that had more registers would be yet more performance friendly to parrot.

Re:why?

[Kent Recal]

¼ß`æ ¼ w ££ j®½tsg >!!!

Re:why?

[lupus-slash]

Using SSA in the bytecode is an interesting research field. The MS CLR apparently implements (or implemented) it: see references here and there on OptIL. Basically they augmented IL code with SSA annotations, phi functions etc.

I think there are two issues with it. First it requires the compiler writers to understand SSA and emit a correct SSA representation. The less burden is put on the frontends, the better, IMHO, I don't think the perl and python guys really want to deal with those kinds of low-level details.

There are also many security implications, beside the obvious correctness issues if the intermediate code is not in correct SSA form: proving that it is correct SSA may be a significant time sink if the VM has to provide type safety guarantees, for example.

The other issue is that there are several forms of SSA and deciding which one to use and finalizing it in the bytecode may prevent future optimizations opportunities (without re-creating the SSA form which sort of defeats starting with SSA in the first place). There is also the issue of having the SSA form apply to complex opcodes that the jit translates to several internal reprsentation instructions and it may be better to apply the SSA form to the latter instead of to the former coarse opcodes.

Using stack-based or virtual register-based (not the parrot limited register set) is both simple enough for the high level compilers to produce and simple enough for the jit to put in the preferred SSA form, that it's a better choice.
Mono takes the stack-based bytecode and turns it into SSA form to perform some of the optimizations: this allows us to adapt the SSA form to new needs as the research community comes up with better tricks in that area.
For example, if Java 8-10 years ago would have choosed and finalized a SSA form in the jvm bytecode, that form would be most likely outdated given the research on different and better SSA forms going on the last few years.

Re:why?

[ajs]

In general, Dan Suglaski got it right in a talk on Parrot, where he said (paraphrase), "I don't think that, as a language designer, I should have an ego so large as to suggest that I can choose which character set best encodes your language. Parrot will use Unicode as a Lingua Franca, but will support fully the use of your native character sets where needed."

It's not that Unicode can't "try" to support your needs, it's that Unicode should not be assumed to have succeded (lest it act as an instrument of stagnation rather than unification). Local character sets like ASCII, Big5, etc. have their own value in terms of efficiency and applicability to local domain problems. They should have core support for that reason, period.

Awesome april fools joke

[Anonymous Coward]

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?

[egott]

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?

[Kristoffer Lunden]

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! :)

Re:what is parrot?

[Ziviyr]

There are 10 kinds of people: Those that understand trinary; those that don't; and those that don't care.

What about the ones that count from zero?

Re:what is parrot?

[photon317]

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?

Re:what is parrot?

[egott]

Sadly, I am an embarrassingly incompetent speller. I had hopped no one would notice on /.

Re:what is parrot?

[Vanieter]

Your sig is too much like mine : I'm suing you to oblivion and back.

Re:what is parrot?

[R.Caley]

Wouldn't that be "ternary",

Maybe he's a dolphin.

Explanations Please

[SomeGuyTyping]

When posting software projects (especially those whose version number 0) please add a quicky bit about the package for the lazy amongs us

Major progress towards open scripting standards

[Anonymous Coward]

"[Parrot's aim,] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)"

Thank goodness someone is rounding up all of these languages onto a signle virtual machine. This should make it a lot easier to obsolete the whole bunch of them in favor of VBScript.

Re:Major progress towards open scripting standards

[Ingolfke]

Although VBScript isn't a likely port... BASIC has been ported to Parrot. There's even a working Parrot-BASIC CGI script.

Re:Can I run .NET/CLR and JVM bytecode on it?

[belg4mit]

And do you expect to run a mac binary natively
on a P4? CLR, JVM and Parrot are all different virtual *machines*.

Mark Sparshatt is working on a Ruby project...

[tcopeland]

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

Re:Reconciliation

[Larthallor]

No. No we cannot.

Most of the things that make people prefer Python to Perl have to do with the language itself, not the runtime.

To paraphrase a famous Simpsons quote: "My eyes...the runtime does nothing!"

I was wondering...

[Hank Reardon]

I just started going through the joke links on the O'Reilly Parrot pages and started to wonder...

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

Re:I was wondering...

[chromatic]

Apparently, they stay in place: Perl 6 and Parrot Essentials, 2E. (Disclaimer: I did tech review on the book.)

Python support?

[WillWare]

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.

Re:Python support?

[aurelien]

aurelien@backup2:~$ clisp -q

[1]> (/ 4 7)
4/7
[2]>

ahhhhh ... :)

Re:Python support?

[pragma_x]

Ditto. The geek in me wondered if this was even proper grammar (sans the 'Bar' and all).

mitzvah Audio pronunciation of "mitzvah" ( P ) Pronunciation Key (mtsv)
n. pl. mitzvoth (-vt, -vs) or mitzvahs

1.
1. A commandment of the Jewish law.
2. The fulfillment of such a commandment.
2. A worthy deed.

My vote is that he meant #2. Thanks to grandparent.

pasm rules

[Anonymous Coward]

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.

Right...

[Moth7]

For anyone who didn't RTF-non-april-fools-A: Parrot is a virtual machine which just happens to be able to run both of them. Get a bloody clue.

Re:Right...

[Meostro]

Which only supports my point further. I RTFA and I still got it wrong. How hard would it be to include this one simple line?

Parrot is a virtual machine which just happens to be able to run both of them.

Re:Right...

[Bob of Dole]

I'd rather they left that out, since that's not what Parrot is, really.
Yes, it runs Perl (and will soon run Python)
But it's designed so that any scripting language can use it, so a better description would be something like:
Parrot is a generic virtual machine for interpreted languages, currently planned to be used by future versions of Perl and Python.

Re:Can I run .NET/CLR and JVM bytecode on it?

[Ollierose]

well, seeing as the .Net CLR and JVMs are currently built on top of a register based architecture (namely a CPU), theres no reason why someone (preferably not likely to miss their sanity) could port mono or an OSS JVM to run on top of parrot.

mmm... JVM on Parrot on CPU goodness

Re:WTF is this?

[lewp]

Everyone knew except for you. Haha.

Re:WTF is this?

[Bob of Dole]

That's not what it is. Perl and Python (and most "major" interpreted languages, I would suspect), first compile the script to byte-code, then execute the byte-code in a VM.

At some point along the line, someone said "Hey! Why are we writting VMs for every single language? They all do pretty much the same thing!".

So Parrot is that, a common VM. Perl6 compiles to Parrot bytecode, instead of the perl-only-bytecode it was using for Perl5.
Since that bytecode format is open, and the VM free, any other interpreted (or compiled, I guess) language (Python, Ruby, TCL, LUA, whatever) can make their compilers output Parrot bytecode.
That way they don't have to build and maintain their own VM, and they get the benefits of future optimizations to Parrot.

For example, I could write a just-in-time compiler for Parrot for my favorite platform, and every Parrot-enabled language could take advantage of that.
Doing that now, I'd have to pick a language to optimize. Do I want to make Python faster? Or Perl?

Python is going to use it in the future,last I heard. (probably as another backend like Jython or IronPython, not as a replacement for CPython)
I think they were waiting on the byte-code format stabilizing.

All in all, it's a very cool idea. Makes it a hell of a lot easier for people to make new interpreted languages, since they only have to target Parrot, and they've got a mature, debugged, VM that runs on multiple platforms. (in theory, at least. I don't think it's there yet)

It's not that similar to the JavaVM (which is only designed to run Java, not a pile of different languages), but it is kinda like the .Net VM.
The developers of Parrot created Parrot instead of targeting .Net for two reasons:
1. .Net didn't exist when they began :)
2. .Net is designed for compiled languages (C++, C#, VB, etc), and supposedly that would cause a performance hit over a VM designed for interpreted languages. (Plus, it's not designed to be portable, like Parrot is)

Another funny virtual machine

[descubes]

The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.

A truly interesting project

[Coryoth]

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.

Re:A truly interesting project

[GooberToo]

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!

Re:A truly interesting project

[Coryoth]

"creeping" indeed. C# is here now, and you can write real apps in it now. Parrot still hasn't gotten out of the gate. It just happened to move a little.

And 4 years ago the Java people could happily say exactly the same thing about C#. If Parrot offers real advantages (and it does) then when it does arrive it is going to shake things up. Laugh now, but honestly, wait a few years and see if you're still laughing. I'll put rather good odds that if you are it will be very very nervous laughter.

Jedidiah.

Re:A truly interesting project

[Kristoffer Lunden]

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'll have access to all those different libs.

One of the big wins is that there is no need to maintain lots of different language bindings either, if you support parrot, you get those other languages automatically. At least in an ideal world. ;-) SWIG is great when it works, but can be such a royal pain when it doesn't... and this would be one step up indeed.

Re:A truly interesting project

[Hard_Code]

It's a project based on a Monty Python skit. Aren't we supposed to laugh?

Re: A truly interesting project

[gidds]

...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, security, portability, and especially maintainability.

Take typing, for example. Dynamic typing is easier to write for: you don't have to restrict yourself to particular types, you don't have to decide things like that in advance, and you don't have to repeat information. But that freedom comes at a price: you don't know what types you'll have to deal with, so you can't guarantee you'll be able to handle them. It's much easier to make subtle bugs. And, what's worse: you can't spot any of this until runtime. You've traded ease of writing for difficulty of testing and fixing.

Similarly, the 'there's more than one way to do it' philosophy is often seen as a plus. How could choice be bad? The trouble is that that choice is the writer's choice -- but the writer isn't the only person to work with the code. Something like 80% of the time spent on code is in maintenance. And if there are 10 subtly different ways to do everything, then the maintainer is 10 times more likely to misunderstand what the code is doing, or to have trouble following the idiom. That's where the argument that 'the programmer doesn't need to understand the whole language' falls right down. And a language that allows the writer the freedom to write an incomprehensible mess isn't one that allows the maintainer much peace of mind!

I could go on about many other aspects too. The roll-your-own object model and we-trust-you data hiding are hardly suited to million-line systems. And so on, and so on.

Of course, I'm not saying that dynamic typing or supernumerary language features or whatever will necessarily lead to bad code. I'm sure some Perl code is a model of elegance, clarity, discipline, and correctness. But is all of it? Hardly... I'd far rather rely on a compiler than a developer to find bugs, any day. And I'd far rather rely on a language to encourage clarity than on the self-discipline of some developers I've worked with...

In short, while the facilities of what used to be known as scripting languages have improved tremendously, their philosophy is now what limits them -- that's what makes them unsuitable for huge, complex or critical systems.

Re: A truly interesting project

[chromatic]

But is all of it?

Nor is all code written in static languages elegant, clear, disciplined, or correct. You can't give a bad programmer enough tools to prevent him from making mistakes if you want to allow him the possibility to do anything interesting.

I'd far rather rely on a compiler than a developer to find bugs, any day.

In my experience, the bugs that compilers can't find are much more important. I'd rather use a more expressive, higher-level language that gives me the flexibility to do my work more productively and quickly and rely on disciplined coding to prove that I've accomplished what I intended to accomplish.

Re:A truly interesting project

[Shillo]

> "creeping" indeed. C# is here now, and you can write real apps in it now. Parrot still hasn't gotten out of the gate. It just happened to move a little.

But the languages covered by Parrot have been around long before .NET was even conceived of, and there is a huge pile of software already written in each of them. Parrot simply ups the ante to the whole new level.

--

Re:A truly interesting project

[archeopterix]

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 also written in Perl) Perl will become a nonscripting language. By this definition C/C++ is a nonscripting (by lack of any other name) language, Java is a scripting language (as far as I know all Java VMs are written in C).

Now don't get me wrong, I don't think the lack of this feature is a reason to frown upon a language. (This feature could only affect your choice of the first "bootstrapping" language for a totally new platform, which would be C anyway :-) ) I am only saying that this maps well on what languages I consider the scripting ones.

Re: A truly interesting project

[juhaz]

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 much different from each other than from the rest.. Java one because it's bytecode interpreted? If so, it's just as static as C, and strongly typed to boot. What comes to security... if you somehow screw up, due to dynamic typing or anything else, you'll usually get an exception, not potentially exploitable flaw you would in C. Does Perl engourage clarity? Perhaps not, but Python most certainly does, again much more so than C.

Re: A truly interesting project

[gidds]

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 Java seem designed to encourage it as much as possible. JavaDoc, for example, makes it as easy as possible to document the big picture and the API issues, to keep them up to date, and to use them. The packaging (namespacing) and source code file layout makes it easy to locate the source code for almost anything the code references. There's no preprocessor to obfuscate things, so you know that what you see is what's actually being run. The enforced exception handling makes it less likely that shortcuts and oversights will come back to bite you. The strong encapsulation makes it straightforward to rework and refactor. Parts of the standard library are a masterclass in the design and documentation of a reusable library. And so on.

Of course, it has its drawbacks, and things it's not suited to. But I'd far rather maintain a large system written in Java than one in C++, C, Perl, or just about any other language I know.

Oh, and I should have included a disclaimer with my last post: I know quite a bit of Perl, but very little Python and Ruby. (And the little I do know makes me want to know more, but there are only so many hours in a day...) So apologies if I'm characterising them wrongly.

To ellaborate on the FAQ

[pavon]

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:To ellaborate on the FAQ

[lupus-slash]

Note that writing a big chunk of the perl interpreter in java or C# is not necessarily a bad thing:-)
One of the reasons parrot was born was to make for a cleaner runtime vs the current perl5 internals.
Whether parrot will succeed in this is still waiting on the jury (or better on parrot reaching at least some sort of beta quality release).
People may want to read the slides at http://www.research.ibm.com/vee04/Hylton.pdf by a Python developer. He writes:

It's not much fun to implement Python in C

In relation to the time and lines of code it took to implement CPython and IronPython.

Implementing perl in C# or Java would also have the advantage of defining some sort of specification for Perl the language which is currently defined more or less as what the current perl C implementation does (even if the perl test suite work is also helping define a more formal specification).

Poicephalus

[EdmundSS]

Did anyone else read this as PolicePhalus?

Python VM?

[erikharrison]

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

Re:Python VM?

[JohnFluxx]

The faq mentions that the python vm is stack-based, and parrot is register-based.

Re:Python VM?

[julesh]

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 application run faster).

While this may be solved by other reimplementations (like Jython and IronPython, which targets the .NET CLR), there remains a chance that Parrot will be officially adopted by the Python team, at which point my last remaining problem with the language will disappear.

Re:Python VM?

[cakoose]

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

[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

[Hortensia Patel]

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.

Re:A question

[magefile]

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

[beppu]

That's the plan.

Re:A question

[Kristoffer Lunden]

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

Re:A question

[multi io]

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.

Re:A question

[zorander]

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

[Kristoffer Lunden]

Examples please? I couldn't think of any off-hand.

Although, all those Inline::* modules on CPAN is allowing you to do just that, so apparently people find it at the very least amusing. ;-)

Re:A question

[mewphobia]

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, .net by things like windows forms that are tightly coupled with win32 - but how long till there is a viable opensource alternative? So i'm guessing microsoft's drawcard is palladium. Digital media is their leverage.

I guess we'll see how it pans out.

Re:A question

[GooberToo]

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.

Re:A question

[chromatic]

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

Point taken, but all three of those have (or will have) representations in Parrot.

Re:A question

[cakoose]

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 interoperability barrier. Here's the situation:

1. You created a programming language and you wrote a compiler that targets Parrot.
2. You want your language to have enums.
3. The Parrot VM doesn't have a native concept of enums (this may or may not be true).
4. You see that there are many techniques to simulate enums using existing Parrot constructs.
5. You choose one of those techniques.

Now you have enums and you're running on Parrot. But you might not be able to pass your enum values to code written in another Parrot language. Why not? Because the compiler-writer for the other language may have used a different (though equally valid) technique to encode enums.

That's no problem, we'll just define a standard for all enum types so that all compiler-writers can use the same encoding technique. Let's do that for all the language constructs we can think of! The only problem is that new languages introduce new/better concepts and we can't define all those in advance. The JVM and CLR are good examples of this problem. They're both lacking functionality that would be required to support better type systems (my biggest gripe is the lack of discriminated unions). All interoperability happens at the level of the crappiest type system.

Re:A question

[GooberToo]

So much anger...so clueless...

I'm so glad you're willing to admit this about your self. Admitting you have a problem is the first step.

The rest of your garbage can be ignored because it shows your ignorance. If you have a language, which can not "natively" run in the parrot VM, then you're not running the parrot VM. That's the whole point of my comment, which went WAY over your ignorant head.

Re:A question

[cakoose]

I may have misunderstood your post, but this is what you said to the parent poster:

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.

The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.

If you have a language, which can not "natively" run in the parrot VM, then you're not running the parrot VM.

What does that even mean? Even if you have come up with a new way of representing enums, you'll still only be using the standard Parrot VM instructions. If you have a program that compiles exclusively to Parrot bytecode and runs entirely within the Parrot VM with no JNI-type extensions, wouldn't you say that it runs on Parrot?

BTW, your "I'm rubber, you're glue" comeback brings back memories...

Re:A question

[GooberToo]

The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.

No, he said some will run parrot and others will run other scripting languages which do have have native features of parrot. Well, duh, if you're running a scripting language which does not have native support in parrot, you're running a different vm. Either the "feature" will run "natively" in parrot, or it's not running in parrot. Or, at a minimum, some language hybrid-parrot-vm. Either way, you're not running, "parrot". Which means, what was his point.

Re:A question

[GooberToo]

err...supposed to say, "does not have native"

Re:A question

[cakoose]

Parrot is a instruction set and a runtime environment. I think that running entirely on that instruction set qualifies as "running on Parrot".

For example, most people would agree that Java runs on the JVM. However, the JVM instruction set doesn't have an if-then-else bytecode instruction. It only has asm-style branch/goto instructions. The Java compiler has to translate 'if-then-else' into bytecode. Because of that, would you consider Java to not run on the JVM?

Why do you use the term "[language] runs Parrot" instead of "[language] runs on Parrot"?

Re:A question

[GooberToo]

No. And that is exactly my point. A language which runs on top of parrot is generating parrot byte-code. If it's not generating parrot byte-code, it's not "native", and therefore, not running on parrot.

So, you're stuck with either running parrot vm, not running the parrot vm, or some hybrid. And frankly, if you have some hybrid environment, that's not parrot's fault.

You seem to be looking for someone to argue with for absoluetely no reason. Frankly, YOU seem to be the angry one here.

Re:A question

[cakoose]

Ok, now it seems like you might just be screwing around and I probably shouldn't reply, but I can't help myself...

A language which runs on top of parrot is generating parrot byte-code. If it's not generating parrot byte-code, it's not "native", and therefore, not running on parrot.

Ok, back to the original example. Let's say you're writing a LanguageX to Parrot compiler. Assume that Parrot doesn't have specific bytecodes for enum support but that the compiler can encode enum types using existing Parrot bytecodes. This compiler will produce only standard Parrot bytecode. Parrot will not need to be modified at all to run the compiled programs.

That was the situation the original poster was talking about. And since there are probably many ways to encode enum types using pure Parrot bytecode, the compiler for LanguageZ might use a different technique. Both compilers have enum support, both compilers produce only pure Parrot bytecode, but programs written in the two languages may not be able to pass enum types back and forth.

Nobody is saying that this is Parrot's fault. They're just saying that you need more than interoperability issues don't end with the creation of a VM. They'll need to define an "official" encoding for every the various categories of data types (classes, enums, function pointers, etc.).

premature

[Bill, Shooter of Bul]

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.

Re:premature

[Chandon Seldon]

I don't know about .NET being 5 years old. By that math Parrot is like 3 now.

What is a "Poicephalus"

[El]

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

Re:What is a "Poicephalus"

[Dorothy 86]

proportionately substantial bills

it makes sense to me!

Re:WTF is this?

[ArchAngelQ]

Actually, it's not compiled vs. interperated languages that are the problem: it's staticly typed vs dynamicly typed. The difference?

In C you say

int i;

and you have an int

in python, you say

i = 5

and you have an int

In C you say

char[] c;

and you have a string.

in python, you say

c = "somestring"

and you have a string.

In C, you have to declair what a variable is before you use it. In Perl or Python, you say something is something, and it's that type. They both have types, casts and so on, it's all a matter of when they get those types associated with them. Other than that, you are quite correct about Parrot.

Sorry if the C is wrong, my C is really rusty these days. It's a rare thing where my apps really require the fine tuned memory management that c provides and requires, rather than the speed and flexability of development time that languages like perl, python and (to some extent, imho) java provide.

What do you mean

[AnEmbodiedMind]

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

Re:WTF is this?

[smcdow]

Actually perl goes farther:

my $a = "5"; # $a is a string

$a++; # now $a is both a string and a number. "6" and 6, respectively

my $b = $a + 1; # $b is a number

$b = "$b"; # now $b is both a string and a number

# these two statements produce the same output
printf( "\$b is %s\n", $b );
printf( "\$b is %d\n", $b );

Strong typing sucks.

Still an april fool's joke

[jasoegaard]

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

Saying that it in it's current state supports Scheme is, well, at best a joke (and I am in a good mood today). Havin a subdirectory named Scheme, doesn't actually mean they work.

Re:Reconciliation

[OmniVector]

na. they both suck. use ruby instead :)

Re:WTF is this?

[Deadbolt]

Obvious rejoinder time:

my $a = 5; # $a is an int
my $b = 3; # so is $b

$c = $a / $b; # $c is 1.66, yay

my $d = 5; # same deal
my $e = "three"; # whoops

$f = $d / $e; # um, what's in $f?

Not saying strong typing is inherently better, but that sometimes you REALLY, REALLY want to know if you're doing something stupid at compile time instead of run time.

a brilliant project

[dgym]

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 would be the icing on the cake. I can't tell if it should be possible, but if I could make use of someone else's library written in their favourite languge, from my favourite languge (by virtue of them both running on Parrot), software would be a whole lot more fun.

Re:a brilliant project

[chromatic]

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

Re:a brilliant project

[javaman235]

I'm a python freak, so I think this is good news. But damn we have a lot of platforms growing out under us and I'm confused.
1) will existing python code using the current API run on parrot? There a load of C modules wrapped in python. Will it matter?
2) Will code that runs on Parrot run in the .NET/mono CLR?
There is a new Python called Ironpython targeting that, I and I know it can't include the current library...Or doesn't right now. There is also Jython, which runs on the java platform with a different API. Python is a great language, but if none of the API my code is based on exists on these different platforms they're not very useful, because I have to write from scratch anyway...might as well be doing it in some other language.

Re:Can I run .NET/CLR and JVM bytecode on it?

[smittyoneeach]

Uhh, while the parser/runtime might be the tip of the iceberg, wouldn't there be a lot of library below the waterline you'd have to magically port?

Uhm...

[wedg]

I read the topic, and only thought to myself: What the hell is a Poice Phallus? Those perl developers sure are kinky!

Re:Uhm...

[Anonymous Coward]

A Poicephalus parrot is a small african parrot. They tend to be very friendly. The most popular poicephalus species as a pet is the Senegal: http://www.petbirdpage.com/senegal.htm . Other poicephalus parrots are the Jardines, Meyers, and a bunch of others I can't think of right now.

Re:Uhm...

[Anonymous Coward]

A Poicephalus parrot is a small african parrot. They tend to be very friendly.

Oh yes, they are very friendly indeed. They look more or less like this:

|:<o)
|:(V\
|8=EE=D

You can find much more info and photos on Google.

Like Mathematica...

[Ayanami Rei]

Really.

Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.

Re:WTF is this?

[Raffaello]

This is really a performance issue, not a type safety issue. If type safety is particularly important, then type checks can be done at run time. However, doing these type checks at run time has a run time performance cost. Doing these same checks at compile time means that compiled code will run that much faster since no type checks are being performed at run time.

Certain types of programs really benefit from compile time type checking - specifically, those where inputs are known at compile time, or are known to be of certain types, or are known to be safe (i.e., inputs are not coming at your program across the wire from a potentiall hostile source - think any web app that takes free form input from users).

It could be argued that in the modern GUI/networked era, many apps are going to be doing lots of run time checking anyway because they are exposed to data inputs from potentially hostile users on a WAN - i.e., the internet, and they are at the mercy of user GUI inputs (bizarre mouse clicks and drags, bogus text or numeric field entries, etc.). That being the case, being able to do type inference and compile time type checks doesn't buy one much in terms of saftey or performance for any such app, since you'll be doing lots of run time type checks on user input data anyway.

IMHO, the idea of compile time type inference and type checking is born of a model of computing that is becoming obsolete. It was how most computation was done just a few decades ago - the programmer controlled the input closely, and so could guarantee inputs of certain types in certain ranges, etc. We have now moved into an era where the most interesting inputs are essentially unknowable at compile time - these are user inputs, whether GUI, keyboard, or network in origin. Just as importantly, user choice destroys the notion of a fixed algorithm executing in a predicable fasion. We simply can't know what direction our programs will take once we allow the user sufficient choice in shaping the programs execution. This being the case, and increasingly so as we go forward, I think that compile time type checking is a backward looking paradigm for programming languages.

See Peter Wegner's home page for some related ideas on new ways of thinking about what it is that a program really does in the modern interactive GUI/network era.

Readability?

[Pan T. Hose]

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.

Re:Readability?

[Kell_pt]

Actually, I should say that I found that the article provided LOTS of links to foreign resources (that would answer whatever doubts someone could face when reading it). It is also well-presented in terms of visuals and well worded.

I've seen MANY an article on slashdot without such a degree of atention to form, contents and references, and I definitly haven't seen many this good, so I REALLY don't understand the comments on the above posts.

Maybe it's one of those personal-vendettas that I'll always be ignorant as to why people make a point in pursuing.

The fact that I did enjoy the article and that I think it's well written would probably not be enough for me to post something like $this post, but the fact that someone actually chose to pick on an article that I find of high-quality is worth putting up with the likely flames that will follow for actually supporting "someone in power" (read - an editor) - not that he needs it.

Cheers.

Re:Readability?

[ggvaidya]

He did it again!

(Applauds)

Re:Readability?

[Gabe the Programmer]

Who? Timothy? He posted another dupe?

Nothing inappropriate

[Pan T. Hose]

Who's Poice? And isn't this name a bit inappropriate?

There is nothing inappropriate in poicephalus as e.g. poicephalus gulielmi is just a Latin name of Red-fronted Parrot, well known for every bird lover, just like agapornis pullarius is a Latin name of Red-headed Lovebird, another proposed code-name for this release. You are probably thinking about phallus for some reason but instead of looking for Freudian connotations you might want to read more about parrots.

PHP support coming too

[1110110001]

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

Re:Wow

[808140]

This is actually a reference to a picture hosted on rotten.com. It may seem surprising to you that I was able to detect the ACs meaning; but after you go see the picture, my friend, you will understand that it has a profound effect on your memory.

It isn't hard to find (it should be linked from the main page, called 'The Incident with the Bird' or some such). I'm too lazy to link.

Re:WTF is this?

[eidechse]

Strong typing sucks.

This is NOT a strong vs weak typing thing. This is a static vs dynamic typing thing. The strength of a type system has no relation to when it's enforced.

You can have all combinations:

• strong/static (e.g. Java)
• strong/dynamic (e.g. Python)
• weak/static (e.g. C)
• weak/dynamic (e.g. Perl)

Actually, you can

[egarland]

The funny thing is that, as far as I remember, it will run java and .net bytecode. It's a little swiss army VM.

Re:Actually, you can

[lupus-slash]

Well, "it will run" is more whishful thinking than anything. Having actually implemented a .net runtime (mono) and knowing a bit about the parrot internals, I can say you that parrot won't run any significant .net program anytime soon and even if it will it will be very slow. Significant changes would be needed in the design to make it work and I don't expect that to happen any time soon.

Re:Actually, you can

[egarland]

Well, "it will run" is more whishful thinking than anything

Right. It's my understanding that it's not a complete Java or .Net implementation, just that it can interpret and run *some* bytecode from those VM's. I didn't mean to imply that you could run Java or .Net programs under Parrot, just that there was some translation capabilities in there.

I'd like to see someone put complete support for Java and .Net bytecode into parrot but it's not worth thinking about until Perl 6, Python, Ruby and PHP are all stable and working well on Parrot and Parrot developers have nothing better to do.

Re:Actually, you can

[javaman235]

My question is why? Why on earth should we make a separate platform for running .NET and Java, OR python and perl when we have mono? Through the CLI in mono Python could call perl or perl could call python, or c#, or visual basic, or ANYTHING, including java. Why make a platform to run the two together when we have a platform to run all of them together, including VISUAL BASIC and other code written on windows???

Parrot-Python Performance Test

[randallman]

A simple performance test.

i = 0

limit = 1 * 10**7
print limit

while i < limit:
i += 1

Parrot ran in approx 3 seconds and used approx. 12 MB RAM.

CPython ran in approx. 8 seconds and used approx. 4 MB RAM.

Re:Parrot-Python Performance Test

[chromatic]

How did you compile Parrot? Right now, the default is to disable the JIT to help find bugs in the non-JIT codepaths. An optimized build might be even better.

Re:Parrot-Python Performance Test

[randallman]

I just followed the instructions in the README.

Re:Parrot-Python Performance Test

[randallman]

How would I compile it to use the JIT?

Re:Parrot-Python Performance Test

[chromatic]

Issue:

make clean

to clear out all old objects, then:

perl Configure.pl --optimize --jitcapable

to build an optimized build with JIT enabled. The latter works best on x86 platforms. Then make and test as normal.

Re:WTF is this?

[miguel]

A few comments: .NET did exist when Parrot was announced, and more
importantly the work to turn .NET into an ECMA
standard had started way before this. .NET is designed for compiled languages as much
as the x86 is designed for compiled languages
(in fact the x86 is strongly typed and knows about
two types: ints and floats, nothing else).

So anyways, for those who can see further than
the end of their noses, .NET provides a lot of
sugar for strongly typed OO languages, but it
requires a strong effort to be as naive to think
that dynamic languages are not supported.

In any case, IronPython has demostrated that .NET can execute dynamic Python code as fast or
faster than the Python interpreter itself.

So those two stated reasons for Parrot are rubbish.

On the other hand, its perfectly fine to say
`We wanted to do something different' or `we
wanted to do our own thing'. Nothing wrong with
that.

Miguel.

Re:WTF is this?

[Raffaello]

I would be very interested to see an example of a real-world application where unpredictable user inputs can demonstrably render static type-checking useless, or where static type-checking makes a real-world application significantly harder to write. Because I sure can't think of one.

Static type checking is still useful for those portions of the program that are, well, static. Any part of the program that deals only with data that is known at compile time, can benefit from static type checking. For example, if your menus are not dynamic (their content does not change) then that portion of your code can benefit from static type checking, etc.

But by far the more difficult bit is dealing with data that isn't known at compile time. Let's take the same example. What if I have a menu item that lists the names of recently opened files with their full path - say in a File menu. However, the menu drawing code I use assumes that all menu items are less than a certain number of characters. There is absolutely no way that I as a programmer can know at compile time whether the type of that file path will be stringLessThan64Characters, or whatever the limit is. I must do a run time check of the data, and respond accordingly. The benefits of compile time type checking are lost for this portion of the code, because it is interactive. The nature of the data that my algorithms will be dealing with cannot be known at compile time because it is determined by user input.

This issue is multiplied in the sequences of user mouse and keyboard actions in, for example, a graphics program. The user can cut/paste/drag/drop/copy-drag etc. At each juncture, my code must check the nature of the data to assure that it can be handled by my algorithms. Static type checking here becomes of little utility. I end up with much of my data being of type "Untyped" and so, it must be type checked repeatedly at run time.

Note that this need to do run time type checking is unavoidable not only in practice but in principle. There is simply no way to know what the type of the data generated by a complex series of user actions will be. Remember that type in this sense is strict, and includes such things as data size and dimensions, not just the underlying primitive type of which it is made. It is not enough to know that I'm getting a slew of bytes, I must know that they are well formed wrt my application's algorithms, and that they are of the right range of size.

Now add to this multiple user interactions across the network, and realize that by far your most important task with regard to type checking is not the ivory tower theoretical exercise of type inference, but the very real world task of checking each and every piece of data that the users throw at your code, and the results of combinations of such user inputs that you may not have originally predicted ("Oh, it never occurred to me that the user would select that menu item, click this radio button, type in such -and-such and then click this other unrelated button").

The more interactive a piece of software is, the more choices the user has, the greater the use of network connectivity, the more the need for run time type checking. Since I'm doing all of these run time type checks, not because I want to, but because I have to I might as well use a language that is designed on the basis of run time type checking. I simply define the necessary constrained types I need, and throw an execption/condition when one of my functions/methods is called with the wrong type, as determined at run time.

The future belongs to interactive software, and interactive software demands run time type checking. It follows that the future belongs to languages that are dynamically typed.

Ah, but...

[TheLink]

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

But does Parrot run Perl as of now? ;).

WE DON'T HAVE EDITORS

[EnglishTim]

We don't have Editors. We have Site Maintainers.

Re:WTF is this?

[chromatic]

That's not entirely fair. I suspect that with the CLR guys concentrating on providing a better platform for dynamic languages, .NET is a much more attractive target now than it was three years ago. How well would IronPython have worked on the CLR from 2001?

What's The State Of INTERCAL Support

[R.Caley]

I can't wait to include some INTERCAL modules in our applications. Sometimes perl is far to maintainable.

Re:Can I run .NET/CLR and JVM bytecode on it?

[julesh]

Well, given that many of the languages it targets support dynamic compilation, not just dynamic loading, it would have to support something similar.

Re:WTF is this?

[julesh]

Maybe the .NET CLR did exist and was publically documented at the time they started work on this; I'm sure you know more about that than me. However, their FAQ clearly states that they weren't aware of it at the time.

Also, I suspect they are right that a VM targeted at dynamic languages will be more efficient for running those languages than one that was primarily designed for static languages, if only because the dynamic method dispatch code that a dynamic language on a static VM would have to emit for each method call could be subsumed into a single VM instruction (I know nothing of the internals of .NET; I assume it doesn't support such an instruction). This would allow for smaller bytecode files, and therefore more efficient compilation when it reaches the JIT compiler, or more efficient interpretation when not using JIT compilation.

Parrot has a dotgnu OPS section

[Gopal.V]

dotgnu .ops in Parrot CVS .

Volunteers needed :)

Hardly an improvement

[Pan T. Hose]

My version:

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 [break] the second then single-sentence paragraph into three separate sentences exactly because I was somewhat concerned readability-wise [...]

Your version:

Funny you mention the run-on sentence. I did preview the article. As I previewed the article I decided to turn a list of comma separated values into a bullet list and broke the second single-sentence paragraph into three separate sentences. I did these two actions because I was somewhat concerned about the readability of the article. [...]

Please take no offence but your version is hardly an improvement, not only because the dissonance between sentences (or impedance mismatch, if you will) makes it sound like a homework written by a six years old child, but most importantly becuase in addition to changing style you have also removed content by dropping quite a few important subtleties and overtones in the form of relations of different parts of the original sentence, as well as my emotional relation thereto. Why not "correct" more texts while you are at it! They might really need their "run-on sentences" broke into infantile series of three-word statements!

Now, on a much serious matter:

[...] I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace.

Some people do not contain enough whitespace. [Not sure why Pan would mention whitespace in conjunction with people.]

You have probably parsed it as: "I can understand that some people interested in the subject of my story might indeed contain not nearly enough whitespace" or "I can understand that for some reason people interested in the subject of my story might indeed contain not nearly enough whitespace" instead of the literal and correct "I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace" which is parsable only one way, using dashes instead of whitespace for indentation:

- I can understand that
- - [that] my story might indeed contain not nearly enough whitespace
- - - [enough] for some people
- - - - [people] interested in the subject

It might be disambiguated using punctuation: "I can understand that, for some people interested in the subject, my story might indeed contain not nearly enough whitespace" or "I can understand that--for some people interested in the subject--my story might indeed contain not nearly enough whitespace" but even without such punctuation marks this part of the sentence is unambiguous nonetheless, fot there is no other way whatsoever for it to make any sense assuming it was written correctly in the first place, while you have presumably assumed otherwise (which itself is an insult).

Still, I am most disappointed (if not outright outraged) by the fact that you have completely missed the humour therein! I can only hope that some people who use some language named after a certain BBC show from 1969 are a somewhat better parsers because otherwise I would have to consider the time spent on writing that comment--and indeed submitting the whole story--completely wasted.

Re:Hardly an improvement

[Kent Recal]

Gah. Has anyone read this comment to the end and can provide a short summary?

Re:Can I run .NET/CLR and JVM bytecode on it?

[Ollierose]

I guess that depends on whether your libraries are written in the language that you're porting the parser for. If (for example) the class libraries were all pure c# and you ported mono to this new architecture, you'd automatically get the class libraries with a recompile. I think it would become self-hosting pretty quickly that way as well.

Mind you, I was just being flippant when I posted the original ;)

Positive Response?

[doodaddy]

Holy Crap! I must say that I looked toward the comments in this thread with a cringe. I've been a big fan of Perl 6 and Parrot, if for no other reason than that I'm interested in great (and proven) people trying to solve hard, polemical problems.

However, usually there is so much negativity about these projects on Slashdot, that I tend to lose faith in people's curiosity and gumption. (I believe the usual reply is, ".Net/Java are better.")

Will miracles never end? Congratultions to the Parrot team for picking up steam and converting the unwashed, gnashers of teeth! (-:

No reference counting

[Pan T. Hose]

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure