At 19:05 on 05/23/2007 PDT, chromatic <[EMAIL PROTECTED]> wrote: > > It sounds like you are saying that languages are free to implement > > their own semantics using their own code, and that they can choose not > > to interoperate with predefined Parrot types or types from other > > languages when that would negatively impact their goals, such as > > performance. While that rings true, it seems that Parrot is not > > providing that ability -- languages can already implement whatever > > they want without Parrot. And if languages are free to ignore > > predefined and foreign types, when what benefit will they actually get > > from Parrot? > > - better compiler tools than lex and yacc.
Is it necessary (or even fair) to tie compiler components to parrot? > > Snarkily, it's better than the JVM because it actually supports features of > dynamic languages natively without forcing all dynamic languages built on it > to invent everything besides "look up named method at runtime". Apparently this is an improvement over "invent the whole VM"? ;-) I've been following parrot to some degree since day one, and at this point I am very much unconvinced that it has any real value. I have always been more interested in perl 6 than parrot, and i don't really believe that parrot is essential, or even the best solution to get perl 6 going. I will follow this thread with some interest though.. perhaps my mind will be changed. (Not that my opinion matters a whole lot.. At this point I really have written perl 6 off too- it doesn't seem likely to reach maturity in time to regain much relevance for perl in the corporate world.. But that's really a separate rant and it's not really parrot's fault, unless you believe that parrot coders could be working on projects more directly related to perl 6 instead.) --Josh
