I'm familiar with both, and I have no problem with them as features, but I don't consider them "exceptionally simple", syntax-wise. Don't get me started on double-underscores and slots....
Knowing my own limitations with keeping track of variable names, etc. I would personally prefer a more orderly language like Java for larger programs.
Hmm. How does Java make it easier to keep track of variable names? My best guess is that Foo foo = new Foo(); is a mnemonic device. "Oh, I guess it must really be a Foo!"
Choosing the right spells is difficult. It helps if you've captured enough enemies to research a few different types. I've found that losing a combat then rearranging the available spells can make a difficult combat much easier.
I'm a Perl 6 and Parrot developer, and I was speaking hypothetically, as if I weren't a Parrot developer and were instead helping to implement Perl 6 on the DLR.
How does a generational GC solve fragmentation? (I can imagine that a copying generational GC helps, but unless you sbrk and never malloc, I don't see how you can avoid fragmentation.)
It would take a really bad OS to make memory fragmentation a problem, since memory address pointers are virtualized....
Actual memory addresses aren't. If you allocate 1,000 pages, free a few in the middle, and try to allocate another thousand contiguous pages, you won't get them a few from here and a few from there.
I'm sure it's possible to stitch together a byte here, a byte there, and so on in your VMM, but that would be a lot of overhead and you'd need to be pretty good at packing algorithms to make that work. I'm also not sure that malloc() has to return contiguous memory.
As long as parrot requires some baseline functionally before you can join the club, life will be okay.
If someone writes a bad PMC by hand, there's not much Parrot can do to fix that. What we can do is make it sufficiently easy to write a good PMC that people do that instead.
Likewise we hope that the standard features that Parrot provides, such as method resolution and control flow and compiler building, are sufficiently powerful and flexible that you can reuse them to build a new language, or customize them in a way that's still compatible with the rest of Parrot.
It is the "If $LANGUAGE_X supports a keyed lookup operation, then..." that makes me nervous. How can I test that if there is no defined behavior?
Perhaps we're talking past each other. I mean the language's syntax. For example, there are no associative arrays in C as a fundamental data type, while there are indexed arrays. It doesn't hurt C on Parrot to use a PMC that has keyed access, but you can't access that PMC by key with C's normal syntax; you need some sort of function to do it for you.
All PMCs have a vtable entry that allows you to access a PMC by key, but not all PMCs are aggregate containers or have some other semantically meaningful behavior for accessing a PMC by a key. Those that don't throw exceptions, but they don't crash Parrot.
Having access to the CPAN from other languages would be useful (Ruby programmers take note). I want Pygame and Pyglet available to Perl 6 as well.
If I'm PHP, why should I compile to PIR?
Library support, primarily. mod_php is well-understood and widely deployed. However, it's possible that the Parrot security model may make mod_parrot more appealing to deploy than mod_php.
What is the fundamental "unit" of a library/application compiled in PIR. In.NET you deal in assemblies. In PIR, what do you deal in?
There's no real formal name, but a PBC file is as close as you get. It's just a bunch of bytecode. As yet we haven't decided on any formal interface that it needs to support.
Where is the boundary between something written in PHP and something in Perl? Is it a function? A class? A module?
It can be any of those. For example, my little Scheme-like language has self-hosted tests. They use a testing library I wrote in PIR. The testing library provides a series of multimethods that my language can call as if they were native functions -- and my language doesn't support multi-dispatch!
How does PIR handle the clash between objects and classes? Can I pass a blessed object created in perl to my PHP app?
Yes. The semantics of how that object will behave depends on its class, but as long as PHP on Parrot and Perl on Parrot use Parrot's calling conventions and its PMC interfaces for things like calling methods and creating objects, each language can have its own special semantics and can use objects defined in other languages.
What about namespace issues and how does PIR reconcile against language that have piss poor namespace support like PHP?
Each high-level language has its own top-level namespace. I imagine that the PHP implementation just lobs some three-thousand functions into that namespace, where Perl 6 stores things differently.
What about all the cool hashtable/hashref stuff that perl has? How will that work on something like PHP?
Data structures created in Perl and passed into PHP will have Perl semantics for all equivalent operations performed in PHP. If PHP supports a keyed lookup operation, Parrot will perform that operation on the data structure. How that structure's underlying object handles keyed lookup is up to the object, and it'll have Perl semantics.
What about inheritance? Can I derive a class in perl from a class written in Ruby?
Yes. (I don't know how well that works right now; I don't know if anyone has specifically tried it.)
What about debugging? If something chokes in my PHP library, will parrot let me see the PHP symbol table AND my python symbol table?
As long as the debugger knows about Parrot, it should.
How will any of this be useful without a very smart IDE? It is hard enough to keep track of large applications written in Perl because of the lacking tool support. If I'm calling a function/assembly written in PHP, am I now going to have to hop between to languages to figure it all out?
Reconstructing a language from PBC is non-trivial, but one of the goals of Parrot (and Perl 6) is to encourage better tool support by making it easier to plug an editor into the VM somehow. The answer is "it depends".
What is the baseline "your language needs to support XYZ before it works in PIR"? Or is this thing so low, the only thing I can bank on is a string? Does it define, for example, how and when a string might get cast as an integer
If you do download the tarball, feel free to join #parrot on irc.perl.org. There's a fair bit of code, and having someone onhand to answer your questions can make it much easier to start!
Perl version numbers are dotted triplets, much like IP addresses can be dotted quads. If there were such a thing as an official version number, it would be 5.001000.
Actually the CLR handles dynamic languages quite well.
It's improving, yes. By the time we added sufficient features to the DLR to handle Perl 6 well, though, we'd have reinvented Parrot on the CLR -- and the DLR didn't exist when we started.
So, for example, I want to test $me->boss->wife->is_cute() while accounting for the possibility of unemployment or celibacy. This will either turn into an ugly one-liner with lots of "&&" and redundant calls, or the use of temporary variables.
I saw a lightning talk about overloaded undef last year at YAPC::EU, so you might track down Juerd Waalboer (perhaps on PerlMonks) to see if he can share his trick. If you absolutely must call all of those methods, that may work.
If it were me, I'd still write eval { $me->boss->wife->is_cute() } and check for the exception, though.
Slashdot Mirror
Was this 1999? Perl's had first-class support on Windows since at least 5.6.0.
I thought lobsters were first.
I'm familiar with both, and I have no problem with them as features, but I don't consider them "exceptionally simple", syntax-wise. Don't get me started on double-underscores and slots....
Have you ever used decorators or nested list comprehensions?
Hmm. How does Java make it easier to keep track of variable names? My best guess is that Foo foo = new Foo(); is a mnemonic device. "Oh, I guess it must really be a Foo!"
Choosing the right spells is difficult. It helps if you've captured enough enemies to research a few different types. I've found that losing a combat then rearranging the available spells can make a difficult combat much easier.
I've spent more hours playing Puzzle Quest for my DS than I care to mention, and I haven't even finished yet.
I'm a Perl 6 and Parrot developer, and I was speaking hypothetically, as if I weren't a Parrot developer and were instead helping to implement Perl 6 on the DLR.
Heh. You actually have to ask?
How does a generational GC solve fragmentation? (I can imagine that a copying generational GC helps, but unless you sbrk and never malloc, I don't see how you can avoid fragmentation.)
Actual memory addresses aren't. If you allocate 1,000 pages, free a few in the middle, and try to allocate another thousand contiguous pages, you won't get them a few from here and a few from there.
I'm sure it's possible to stitch together a byte here, a byte there, and so on in your VMM, but that would be a lot of overhead and you'd need to be pretty good at packing algorithms to make that work. I'm also not sure that malloc() has to return contiguous memory.
If someone writes a bad PMC by hand, there's not much Parrot can do to fix that. What we can do is make it sufficiently easy to write a good PMC that people do that instead.
Likewise we hope that the standard features that Parrot provides, such as method resolution and control flow and compiler building, are sufficiently powerful and flexible that you can reuse them to build a new language, or customize them in a way that's still compatible with the rest of Parrot.
Perhaps we're talking past each other. I mean the language's syntax. For example, there are no associative arrays in C as a fundamental data type, while there are indexed arrays. It doesn't hurt C on Parrot to use a PMC that has keyed access, but you can't access that PMC by key with C's normal syntax; you need some sort of function to do it for you.
All PMCs have a vtable entry that allows you to access a PMC by key, but not all PMCs are aggregate containers or have some other semantically meaningful behavior for accessing a PMC by a key. Those that don't throw exceptions, but they don't crash Parrot.
Having access to the CPAN from other languages would be useful (Ruby programmers take note). I want Pygame and Pyglet available to Perl 6 as well.
Library support, primarily. mod_php is well-understood and widely deployed. However, it's possible that the Parrot security model may make mod_parrot more appealing to deploy than mod_php.
There's no real formal name, but a PBC file is as close as you get. It's just a bunch of bytecode. As yet we haven't decided on any formal interface that it needs to support.
It can be any of those. For example, my little Scheme-like language has self-hosted tests. They use a testing library I wrote in PIR. The testing library provides a series of multimethods that my language can call as if they were native functions -- and my language doesn't support multi-dispatch!
Yes. The semantics of how that object will behave depends on its class, but as long as PHP on Parrot and Perl on Parrot use Parrot's calling conventions and its PMC interfaces for things like calling methods and creating objects, each language can have its own special semantics and can use objects defined in other languages.
Each high-level language has its own top-level namespace. I imagine that the PHP implementation just lobs some three-thousand functions into that namespace, where Perl 6 stores things differently.
Data structures created in Perl and passed into PHP will have Perl semantics for all equivalent operations performed in PHP. If PHP supports a keyed lookup operation, Parrot will perform that operation on the data structure. How that structure's underlying object handles keyed lookup is up to the object, and it'll have Perl semantics.
Yes. (I don't know how well that works right now; I don't know if anyone has specifically tried it.)
As long as the debugger knows about Parrot, it should.
Reconstructing a language from PBC is non-trivial, but one of the goals of Parrot (and Perl 6) is to encourage better tool support by making it easier to plug an editor into the VM somehow. The answer is "it depends".
If you do download the tarball, feel free to join #parrot on irc.perl.org. There's a fair bit of code, and having someone onhand to answer your questions can make it much easier to start!
Perl version numbers are dotted triplets, much like IP addresses can be dotted quads. If there were such a thing as an official version number, it would be 5.001000.
It's improving, yes. By the time we added sufficient features to the DLR to handle Perl 6 well, though, we'd have reinvented Parrot on the CLR -- and the DLR didn't exist when we started.
What cost of interpolation? The ppcodes are (basically) the same in both cases. There are variable accesses and concatenations.
Interpolation is a syntactic benefit for coders. The VM doesn't care.
We've released twelve stable versions of Parrot this year alone, including one just yesterday.
Backwards compatibility.
It's on by default in Perl 6 for all programs executed from files, not as one-liners on the command line.
Eventually? Today.
I saw a lightning talk about overloaded undef last year at YAPC::EU, so you might track down Juerd Waalboer (perhaps on PerlMonks) to see if he can share his trick. If you absolutely must call all of those methods, that may work.
If it were me, I'd still write eval { $me->boss->wife->is_cute() } and check for the exception, though.
You're welcome, but I think I'll work on it anyway. You can use it when we're finished, if you like!
I was going to work on Perl 6 today, but because some random jackass on the Internet thinks I shouldn't....
Are you looking for eval BLOCK around the chained method calls?
Look at the smart match operator in Perl 5.10. I think you'll like it.