On Wed, May 23, 2007 at 10:37:06PM -0400, Josh Wilmes wrote: > At 19:05 on 05/23/2007 PDT, chromatic <[EMAIL PROTECTED]> wrote:
> > - better compiler tools than lex and yacc. > Is it necessary (or even fair) to tie compiler components to parrot? I really don't know how to answer this question. The compiler tools target Parrot, so that it will be easier for people (including us) to write languages that run on Parrot. Parrot is awfully pointless without languages that run on it, so making it easier to write a language that runs on Parrot is well in line with the goals of Parrot. I suppose it would be possible to write compiler tools that target multiple backends, but some of those backends I have no interest in running (for legal or technical reasons, such as that I don't own any platform on which they run or have little desire to be the target of a patent suit). Besides that, my goal with Parrot is to produce the best possible platform for running dynamic languages. Supporting other platforms (if such a thing is even possible in any sensible way) would take a lot of work for little benefit. How would you, for example, write C compiler tools that didn't target a specific processor architecture? > > 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 suppose that depends on whether you're implementing the single VM or the many each inventing the same types of things on said single VM. There's a reason we're not writing Parrot in assembly language: sometimes a little more abstraction helps. You can certainly implement any kind of control flow you can imagine with goto and a lot of discipline, but although I know it's theoretically possible and could certainly do it if I really had to, I don't have to and I certainly don't want to. -- c
