Hi Michal > > My first choice is whether to go for a VM, or a C-Python style > > implementation. Right now I'm leaning towards VM. > > I'm not sure what you mean by the difference here. CPython > does have a VM, it's just a stack-based one.
OK so I'm learning already :) I thought CPython was more of a conventional interpreter, and the .pyc files were pretty much 'pre-parsed' equivalents of the original source file. So CPython has more of a traditional VM structure, with a byte-code intruction set and all? What do you know about other scripting languages, e.g. Rhino JavaScript. Is everyone choosing a VM approach these days? My background has been in compiled, statically typed languages so I'm a bit behind the curve in the scripting world. I'm coming to the conclusion that building on top of an existing VM is the only smart way to go in order to leverage a ton of great work done already by others. > Do you have a website for the language? Not at this point. > But: I would say, in general, if you target parrot, and you > make your language compatible with other languages, you're > more likely to get people to try your language for a small > chunk of code here and there, as people will be able to > use libraries they're familiar with your syntax. This is a strong reason for my interest in Parrot. I think Microsoft are definately going the right direction with the CLR - a common managed environment but many languages, with great facilities to share libraries and for cross-language iterop. The trouble is that languages differ in deep ways that make the reality fall short of the utopia. That's why Parrot makes sense to me - a kind of CLR for highly dynamic languages. And if one day it can play ball nicely with both the CLR and the JVM, so much the better (and one less thing for language creators to wrestle with :) Thanks for your input, I'm going to post separately about some requirements I have. Tom.
