Dan Sugalski, the Parrot Pumpking, has answered your questions about Parrot. Without further ado, read on for everything you wanted to know about Parrot and asked.
1) Supported Platforms
by chbarr
Which platforms will Parrot support? Specifically, will there be a port of Parrot (and, in turn, hopefully Perl 6) to PalmOS?
Base platforms are x86 Linux, x86 Windows (At least NT 4.0, possibly 95/98/ME), Solaris 2.something (base to be determined), Mac OS X 10.1, OpenVMS Alpha 7.x (probably 7.2), some version of x68 *BSD. Others may be added at some point. We're happy to compile on anything, but those are the showstopper platforms for releases--if we don't build there, we can't release it.
There will be a port of Parrot to PalmOS and WinCE, but I'm not sure if they'll be considered base platforms. Whether you get a full compiler or not is up in the air--you may only be able to run precompiled bytecode on those platforms. (Some of the handhelds are pretty memory-limited, and we can't snag it all for ourselves)
2) Other languages
by Ovid
I'm excited as heck about Perl6. I can't wait to start taking advantage of coroutines, continuations, and hyper-operators. Since Parrot is being built largely with Perl6 in mind, this suggests that Parrot will have a flexibility that few other languages can touch. While much of the Perl community seems excited about this, I can't help but wonder about non-Perl communities? We'd like to see other languages such as Python or Java use the Parrot VM, but do their communities see any benefit to using Parrot? Rephrased: we're inviting other people to the party. Do they want to come?
There is strong interest in parts of the Ruby community. The Python folks, as far as I know, are taking more of a wait-and-see attitude. I fully expect that when Parrot lives up to its promise that we'll see both Ruby and Python front ends for Parrot. Whether Parrot becomes the official back end for either is a separate question, though I don't think it will. (Neither do I really think it should)
With Python, at least, the Python folks have the advantage of both two implementations and a bytecode format. The former helps since the language's syntax has been formalized a bit, and the latter because doing bytecode transform's a lot easier than writing a language parser. (Someone's already done a partial Python bytecode to Perl 5 optree converter)
3) mod_perl
by ChrisDolan
How well suited will Parrot be as a mod_perl replacement? Will there be any features that will make Parrot better than mod_perl (other than Perl 6 support)?
Parrot will be well suited to be a mod_perl replacement, for a number of reasons. The biggest is that it provides a cleaner way for the programs embedding Parrot to gain control over its environment and IO. Right now, mod_perl needs to jump through a number of mildly hackish hoops to capture the standard files, and it doesn't really have any mechanism to intercept any other sort of file I/O. Parrot's embedding interface gives the embedder control over this if it so chooses. The same goes for the environment hash. Once again, while you may not need to override it, Parrot provides a way to do so.
Basically a Parrot interpreter instance can be completely isolated from the outside, or forced to go entirely through mechanisms the embedder sets up, which should give mod_Parrot better control over what goes on and where it goes.
Parrot also supports loading in multiple versions of the same module (barring conflicts in C libraries over which we have no control) which should take care of some of the versioning issues that sometimes crop up.
4) Is it a BEEFY Parrot?
by erikharrison
I realize that some of this is dependent on Perl 6 design, but what kind of performance increase is there, potentially. Is there in fact, a performance boost, or is Parrot really a maintainabilty/feature choice?
Well, straight one-for-one translations from Perl to C can get you speedups of 100x-200x, so there's definitely speed to be had. (This doesn't mean using perlcc or something like it--it means rewriting the perl code to be C code, using C's variables and suchlike things) Currently we're seeing a factor of 3-5 speedup for non-regex things, though how long that lasts is still up in the air, as we don't have any large programs to do good comparison testing on.
There's a Parrot->C translator that exists right now that can give a rather significant speed boost over plain interpreted or JITted Parrot code. I've hope for that as another way to speed things up, though it's not appropriate for code that does runtime compilation. (Things like string eval, or do/require at runtime)
5) Timeline/Support/etc.?
by johnseq
What functionality do you expect to deliver in a Parrot 1.0 release? Is it just Perl 6.0 support (with other languages supported or unsupported as the case may be) or are things like JVM/CLR support considered must-have?
I know with predominantly volunteer efforts timeframes are notoriously difficult, but is there a date by which you _hope_ to have Parrot-based systems (with 1.0 features above) in production?
JVM and CLR support aren't requirements for the 1.0 release. For that we need working aggregates, subroutines, dynaloading, module support, and a compiler. There's a more comprehensive release date answer in a few questions.
6) Parrot Inspirations
by johnseq
Was there particular virtual machine prior art that played a major role inspiring Parrot's design? If I was interested in learning more about the philosophy behind the Parrot VM are there any specific projects/languages/papers you could point me to (that weren't necessarily about Parrot)?
Real hardware played much more of a role in inspiring Parrot's design than
software did. Motorola's 68000 and 88000 processor, The Company Once
Known as Digital's Alpha processor and venerable VAX are four that spring
to mind. Starting from software and working down has always struck me as the
wrong way to get an efficient interpreter, or any other program for that matter.
If you start from the top and work down, by the time you get to the hardware,
and you always will as something has to execute your program, there tends
to be rather big gulf between how your program works and how the hardware
works. The impedance mismatch there's a big cause of performance issues.
As for the design philosophy behind Parrot.... Well, at one point we had a recommended reading list, but it's apparently gone missing. I'll find and/or recreate the thing and gt it up on dev.perl.org. Personally I'd recommend:
7) smart strings and lazy arrays
by LunaticLeo
Is Parrot the place and will it...
COW strings: We're working on this now. If there's a performance win, yes, they'll go in.
Smart strings: Probably, and if Larry mandates this in Perl 6, then definitely.
Lazy arrays: They'll be doable easily enough. Whether they're shipped as base classes is a question I can't answer at the moment.
8) Release date
by bdumm
When is this bird going to fly?
When it's done. It works now, though not everything we want done is done yet.
And, having given that exact but useless answer...
There are a number of things we need for a final release. I'd love to tell you when they're going to be done, but I can't. Instead, I'll tell you what needs doing instead. Note that every time something on this list is done we'll put out a point release. (As we will when something significant we missed is done, significant library changes are made, or really egregious bugs are fixed)
9) Re:Release date
by VSarkiss
A corollary to this question: What are the plans to coordinate the Parrot release with the Perl 6 release? Will Parrot 1.0 coincide with Perl 6.0, or are there sub-milestones that you'll be trying to synchronize to? Or will the timelines be essentially independent of each other?
Parrot releases will be done like any other piece of software that's not 100% market-driven--when there's a reason for it. Perl releases likewise--when there's a reason. It may be they get released together, if a new feature of Perl requires a new version of Parrot. Other than that, I don't see a reason to tie the two together.
10) Documentation
by 2shortplanks
How do you feel about the level of documentation and commenting in the current project? Do you feel that someone wanting to use Parrot for their own ends could just pick up and work, or do you think that they'd have a big learning curve first?
I never think there's enough documentation, except in those cases where I think there's too much. At the moment the primary thrust of the documentation is to establish correct behaviour--standards docs, if you will. We're trying to make sure the things are readable, but...
As for picking up and joining in, you may find the going a bit tough, unfortunately. While what we're doing isn't rocket science, neither is this a freshman CS project. Still, there's lots of stuff for people of all skill sets and skill levels to do.
11) persistence
by mtk
josh pritikin integrated ObjectStore into perl. and while ObjectStore is problematic (pointer swizzling on the back of SEGV's), the goal is golden: simple, transparent persistence for perl runtime data. i'm not talking about DBFile and friends. i'm talking about storing arbitrary graphs of data (e.g. a hash whose values are hash references), perhaps under a transaction. i'm not asking if Parrot will implement something like this. i just want to know that the developers have thought about the issue. i'd hate to see perl6 make it difficult for others to implement this style of persistence, e.g. by making it impossible to work with or work around the garbage collector. thoughts/comments?
Being able to serialize and de-serialize complex data is something I've given thought to, and to do it properly's more complex than you might think. If you truly freeze an object you need to store not only the data, but also the code (or at least code requirements) as well. Parrot's going to have rather a lot of introspective capabilities, so if anything this'll be easer to do in Parrot.
12) p52p6
by rafael
Have you an idea about the implementation of the "official" p52p6 translator ? OK, that's not really Parrot-related. Just to know how you feel about this.
Yep, I've thought about it. There are three ways to go about it, and we're likely to use all three.
That's likely the order we'll take them in, too.
13) Timely, well-ordered destructors
by tye
Will Parrot support timely, well-ordered destructors? Perl's reference counting provides this but such appears to be impossible with "modern garbage collection".
"Well-ordered" means that if $x references (depends on) $y (and there is no circular dependence), then $x's destructor will fire before $y's.
"Timely" means that destructors fire quite quickly so that they can free related resources for reuse.
For example, an easy and powerful technique is to construct a "lock" object that automatically releases the lock when it is destroyed. How timely things are depends on your definition of timely, I suppose. Also epends on how much you're willing to pay.
Parrot makes exactly two guarantees in this regard:
We don't make any other fundamental guarantees as to what and when. This doesn't mean that a language using Parrot can't guarantee more--for example, it's easy enough to force a cleanup of dead objects on exiting every block, or on block exit if an object with an active destructor potentially goes out of scope.
14) Efficiency versus computer science
by toma
I have heard that perl has fast regular expressions in part because the code has good locality for both data and instructions, which keeps them inside of the processor cache. I have heard that the previous perl regex engine beautification attempts were abandoned due to speed problems. Is Parrot going to preserve the speed-is-more-important-than-beautiful-code philosophy?
Parrot is 100%, unadulterated speed-is-more-important. Which isn't to say we want to write messy code, just that we're willing to if it means the code runs faster. The interpreter is at the absolute bottom of the cycle food chain, here. Every single inefficient thing we do in the interpreter is paid by *everyone* every single time they run something on Parrot. We essentially put a limit on the speed of your program--while you can run slower than we do, you can't run faster, so it behooves us to be as fast as we can.
Having said that, a good algorithm beats clever code nine times out of ten. The tenth time you've already got the good algorithm, and are writing the clever code on top of it, or the algorithm demands clever code.
15) Parrot
by hemabe
Hello. I'm really looking forward for the final Parrot. Of course, like everyone else, I would like to know, when it will be finished. But my 2 "real" questions: One of the major benefits of Parrot (for me) will be the possibility, to give my software to customers without the source. Will it be possible, to run software developed in perl on a foreign computer, without first installing perl? Will there be a port to Windows Computers (i assume)? I have no knowledge about internals like "register based machine" or "stack based machine". I read on http://www.Parrotcode.org/faq/ , that Parrot will use a "register-based vm". Simply, because i'm curious: Why register-based? What are the pros and cons of the both systems (speed, simplicity)? Would be nice, if your could explain this a little bit more.
We will run on windows--it's a core platform.
As for distributing a program with no source, you'll be able to do that, since Parrot's perfectly capable of running with just bytecode. Whether you'll be able to produce an executable or not's up in the air. It's not a primary target, but if you don't need the parser it shouldn't be tough to turn the bytecode to C code, run it through the bytecode->c translator, and compile and link the result.
Register vs. stack is a matter of efficiency on multiple platforms. Using a stack is pretty simple on machines that are, for all intents and purposes, stack machines themselves. (Such as the x86 architecture, which is reasonably register-starved) On the other hand, a stack architecture essentially wastes the resources you have on a register-rich machine such as the Sparc, PPC, or Alpha.
Contrariwise, a register system doesn't really hurt a stack system (since, like the stack, the interpreter registers are living in memory anyway) while you can get a win on a register rich system as you have more registers handy.
Also, stack systems tend to waste a lot of time twidding the stack. Take this for example:
$c = $a + $b;
$d = $a - $b;
The stack code looks like:
push $a
push $b
add
push $c
store
push $a
push $b
subtract
push $d
store
while the register code would look like:
getvar R1, $a
getvar R2, $b
getvar R3, $c
getvar R4, $d
add R3, R1, R2
subtract R4, R1, R2
That's 6 interpreter operations for the register machine and 10 for the stack machine. Each operation has a fixed overhead, so fewer ops means less overhead. (And generally most stack systems aren't that concise, though we would be if we were writing one.)
16) Perl in Perl (for Parrot on Parrot)
by Petruchio
So Perl6 is going to be a compiler for Parrot. And being a regular compiler, rather than the just-in-time dynamic sort Perl5 has, one would tend to think that compiler performance will be a bit less important; compile once, run repeatedly. And rumor even has it that Perl6 will be designed in such a fashion that non-Damians will be able to parse it.
So what are our prospects for a Perl compiler written in Perl?
At a glance, from a distance, by a layman, it seems like you could do a pretty reasonable job of writing a Parrot compiler for language n in a high-level language (say, Perl5). Then write another Parrot compiler for language n in language n, compile the second compiler with the first, and find yourself up and running pretty darned quickly.
Is there a future for this sort of thing on Parrot, at least for rapid prototyping? Might we see a Perl6 compiler written in Perl6? And if it's not plausible or useful, why so?
Those of us who are not (yet) skillful enough to participate in the design
and implementation of important languages really like a good story, with things
to think about.
Perl 6 won't be a compiled language in the same sense that C is--you'll still be able to stuff source in it and have it go, just as you have for perl 1-5. The only difference with Parrot is that it'll freeze compiled code to disk, in a form that's quick to load. The nice thing about freezing is that, since the compilation and running of a program is separate, we likely have plenty of time to optimize the bytecode before we save it. (Presuming a good optimizer, of course--but even without one to start we can add it in later.)
And you're pretty close with your bootstrapping there. While it's not appropriate
to write the actual interpreter engine in perl, it does make sense in some
ways to write the parser in perl 5, generate Parrot bytecode, and bootstrap
ourselves that way. Which we'll do unless there turns out to be some speed
problem. (In which case we'll fix the problem and try again, I suppose
While I can't say for sure what sort of compiler capabilities (really parsing capabilities, as the compilation step is almost separate) Parrot will have until A5 comes out, odds are they'll be pretty impressive.
17) Too Perlish
by erikharrison
I understand that Parrot is to run Perl 6 primarily and that those hacking on it are all Perl Hackers (tm). But do you feel that the level to which Parrot, at least the assembler, is too much in the Perlish idiom? Are you afraid that you might scare off other languages? (And if you are, then why did you do it? What made it worth the sacrifice?)
At the moment Parrot's not got any perl idioms to speak of built into it. (No, really, it doesn't!) It does have a bunch of features that map generally well to what dynamic languages (a class of languages that perl belongs to, as does Python and Ruby) need, there's really nothing perl specific in there.
It is true that the non-C bits of Parrot are generally written in perl, which may be a bit off-putting for non-perl people, but there's not much I can do about that at the moment. It's got to be written in something, and perl's much better than, say, C for processing textual bits.
I wouldn't be averse to core components being in any of the languages that Parrot will ultimately support, at least once we have support for the language in Parrot. Build requirements are being kept to a minimum--right now we require a C compiler, make, and perl. I don't want to add anything else to that list if I can at all help it.
18) Support for threads and parallelism
by ponder
I know that Perl 5 has had a chequered history with embracing the subject of threads. What of the Parrot? In particular, this could be important to the future take-up, as Parrot aims to be a common bytecode for several languages including Java.
Also, can Parrot be run in a multi-CPU environment (SMP), and is there provision for instruction interlocks or spinlocks across the configuration?
Parrot's got threads taken into consideration from the very beginning. We're using something that resembles the ithreads model of perl 5. Only one thread can be in an interpreter at once, and only variables that are explicitly shared can be accessed by multiple threads potentially simultaneously.
Multiple interpreters that aren't sharing anything can run simultaneously in separate threads, as can multiple interpreters that are sharing things as long as they're not accessing shared data.
If your underlying OS thread library takes advantage of an SMP system then so will Parrot. If not, then we won't either.
19) Creating Platform-Specific Code
by Petruchio
It has been possible, for some time now, to create stand-alone executables from Perl programs. Not the most pleasant process, but possible. Dumping from memory, perl2exe on Win32 (I'm told), and so on. What are the prospects for this sort of thing using the Parrot?
Will the situation improve? What are likely to be the limitations? Will
it ever be possible to create, for instance, a
You should be able to create full, standalone executables for Parrot programs. They'll have to embed the Parrot interpreter and link in all the shareable libraries that your program uses, but it'll be doable. Whether or not there's any speed win is a separate issue. Likely yes, at least for all the code available at compile time.
I don't know that you'll ever be able to create a shareable library built from Parrot code. It's potentially possible, but not something I've given any thought to until now.
20) Sandbox, Browser, In & As Kernel, Hardware.
by Petruchio
What are the plans for safe, sandboxed code in Parrot? It would be nice to be able to run untrusted code. It would be nicer still if the Parrot could cooperate with browsers in this capacity... we might have language-independant browser scripting, rather than being locked into JavaScript or the like.
It would be most interesting if the Parrot found its way into, say, the Linux kernel. One could envision replacing many, or even all, the programs in a *nix system with Parrot versions. Sort of like taking the PPT [perl.com] project to another level. Does this seem reasonable, or likely?
But then... if you were going to replace all the software with Parrot versions, one might wonder why a Unix API was needed at all. Could Parrot in some way, serve as OS? In a minimal sense, perhaps; some stuff like process scheduling could be done by Parrot code, but Parrot itself would seem to need to provide access to hardware... this is certainly not part of what's being talked about, but I find the idea intriguing.
And finally, Sun has implemented the JVM without the V... as hardware. Has anybody thought much about this? It seems even wilder than the possibility just raised, but perhaps someone has an interesting perspective on the idea.
Okay, in order:
Sandboxing: A safe interpreter will be done, though potentially not for 1.0. Some of the characteristics are:
Linux: Yeah, it'd be nifty to have Parrot versions of the standard Unix tools. As PPT has demonstrated, it's both perfectly possible and awfully unlikely. (Though it would be interesting to be at a talk with RMS with an Alpha Linux system with PPT for command-line tools)
Parrot as OS: While this is possible, it's a lot of work. Handling the hardware
and process control, which is most of what an OS does, is at the moment completely
outside of what Parrot addresses. Adding it in would be significantly non-trivial.
Parrot as Hardware: While the fate of other "language in hardware" projects (lisp, forth, prolong...) is enough to give one pause, it's certainly possible. I know an ASIC designer who occasionally thinks about this. It definitely could be done, though there's always the big "Why, and who'd pay" question hanging over that sort of project.
So, which was the "the answer is X, but you're really asking about Y question?"
Re:Thanks!
Elian on 2002-05-07T06:31:22
No problem, though next time I think I'll go for a smaller number.:)
And the "X, but Y" question was #6. French impressionist painters are rarely considered as inspiration for software...Parrot inspiration
rafael on 2002-05-07T09:35:18
Having artistic guidelines is fine. Just let me hope that James Joyce's Finnegans Wake will never inspire a Parrot or Perl6 core developer!Re:Parrot inspiration
chicks on 2002-05-07T16:09:06
It makes one wonder: Did Tolstoy inspire COBOL? Did Salvador Dalí inspire PostScript? Did Picasso inspire LISP? Did Melville's Moby Dick inspire BASIC? Oh, the possibilities are endless.Re:Parrot inspiration
rafael on 2002-05-07T16:18:37
LISP for sure was inspired by Raymond Roussel's experimental (and unreadable) poem Nouvelles Impressions d'Afrique . Up to 12 levels of nested parentheses.Re:Parrot inspiration
Damian on 2002-05-07T20:30:17
Just let me hope that James Joyce's Finnegans Wake will never inspire a Parrot or Perl6 core developer!Too late, I fear. Though 'twas Ulysses that inspired this particular madness.
Re:Parrot inspiration
gnat on 2002-05-07T20:41:00
It occurs to me that with the spacing of the Apocalypses, Perl 6 could be said to be inspired by "Waiting for Godot"... :-) --Nat
Re:Thanks!
MythosTraecer on 2002-05-08T21:28:15
I wondered if anyone else was inspired by the Cowboy Bebop soundtracks. I think Blue is required listening for any serious Cowboy Bebop fan, and for me has been the inspiration for many a code hacking session.
Ah, well. I'm still waiting on socket support.
Re:What?
Elian on 2002-05-07T14:42:05
D'oh! I knew I forgot something. We'll get it on the list... right after we add in TOPS-20 and RSTS/E.;-P
2. All dead objects with active destructors will eventually have their destructors called
Quick question related to this: Will memory reclaimed from garbage-collected variables be retained by Parrot the way Perl 5 retains memory, or could memory eventually be released back to the OS? I could see the latter helping a lot compared to certain mod_perl applications I'm familiar with.
Re:Garbage-collected memory
Elian on 2002-05-07T18:23:50
When a memory pool is empty (which happens with some frequency because we've got a copying garbage collector) the empty pool is freed back to the system. Whether this actually releases memory back to the system depends on your OS and the method Parrot uses on your platform to allocate and deallocate its large chunks of memory.
Now, having been appropriately dodgy...
Odds are you'll see memory get released on pretty much any platform you can name. The allocation and deallocation code for large chunks is in a single, small place, and having a build-time option on the memory allocator's a simple enough thing if its even needed. (Some systems are clever when we allocate large chunks, and do it in a way that lets them be released back into the free memory pool)Re:Garbage-collected memory
Theory on 2002-05-07T18:40:06
Excellent! Another big win for Perl 6/Parrot, IMHO. Thanks for replying so promptly, Dan!
