Dan Sugalski, the Parrot Pumpking, is ready, willing or able to answer your questions about Parrot, the Perl 6 virtual machine in development. Ask your questions here, as comments to this article; Dan (and perhaps others!) will select questions, and the answers will be posted in about a week.
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?
Re:Other languages
djberg96 on 2002-04-29T19:55:37
I think you'll see Ruby and Python jump on for the performance increase if nothing else.Re:Other languages
cjf on 2002-05-01T07:19:58
From what I've heard there are a lot of other Ruby people who see benefits to using Parrot. The ones who don't already will quickly be won over by the improved speed and flexibility. I'm sure a lot of these people will also contribute to the project. I see it as a start of a beautiful friendship
:). Rephrased: If you build it, they will come.
Re:Other languages
erikharrison on 2002-05-02T03:33:16
I think Python will be on in no time. Python has a thing for multiple implementations. I think that as the tension between the two settles down then Parrot is coming at just the right time. My guess is that there'll be a Parrot based implementation in no time, and then some clever fellow will get Python and Perl to talk . . . and I will hug them tightly.
:) Python & Perl talking
jand on 2002-05-03T15:04:48
Python and Perl already talk: zope-perl. Even though it looks like this is Zope specific, you can use the underlying pyperl module from any Python program. The only restriction is that your main program must be in Python.
Re:mod_perl
rafael on 2002-04-30T06:59:37
You meant mod_parrot, right ?
Re:Release date
VSarkiss on 2002-04-30T14:19:17
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?
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?
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.
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?
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.
Also, can Parrot be run in a multi-CPU environment (SMP), and is there provision for instruction interlocks or spinlocks across the configuration?
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
I'd like to expand greatly upon these questions, but I'm rushed for time; the questions are being collected now.
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 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.
Re:Sandbox, Browser, In & As Kernel, Hardware.
Matts on 2002-05-03T16:57:50
Sandbox...
I really would like to hear a good answer to this - it was the question I was going to ask. More specifically, the JVM has proved to be a particularly secure piece of software (yes there have been security bugs, but not nearly as many as other products with such a large market reach). We really need to study carefully how they've implemented sandboxing in the JVM.
Does someone have a task to do that, and will we be following their implementation, or at least copying what's good about it?
Re:Where are the answers
Elian on 2002-05-03T17:22:28
They're coming next week, in a single big glob. This was just a call for questions.
-Miko
Re:Animal on the O'Reilly book
Elian on 2002-05-07T14:53:37
We'll just use a different parrot. We were there first, so we win!
