Thanks for the response. I kind of expected an answer like this, but I'd like to explore this for just a minute more and maybe in doing so, show my naivety of parrot.
To begin with, I was perhaps being a little too wordy in my writing without being clear on what I meant. I have certainly entertained the idea of using JVM and CLI. Unfortunately, both of them have a common issue I have a hard time with. First of all, JVM is very java oriented. I am aware of other languages that do exist on the JVM, most notably Jython and JRuby, but I've always had the understanding that if the language doesn't implement a subset of java, that implementing it would be difficult at best. The CLI is certainly friendlier to non C# languages, but still enforces an object and type model. However, as I look at the wikipedia article on JVM and CLI, I'm wondering if my research was incorrect or if the languages that have been implemented have dealt with the single object model idea. At any rate, when I talked about design philosophy, I was really talking about the approach taken, not the focus. Two key points that stick out me are being register based and not enforcing an object model. The latter is what, to me, makes parrot stand out as a VM over any other VM. JVM, CLI, and all other VMs I can remember are built from the ground up with a globally enforced object model. I much prefer parrot's approach that allows languages the choice to use the global object model or not. It's seems very perl-ish. As for implementation, and I may be naive about this, but I was thinking that one wouldn't be embedded in the other, but instead, the would be, for a lack of a better term, next to each other and share a common subsystem. Parrot would know about this static VM, and the other way around. That way, method calls between each other become a gate from one VM to the other and both can understand and use closures, callbacks and continuation, although I'd imagine the static language would be more restricted on what it could create. Perhaps not since closures are starting to make appearances in static languages. Hopefully, this brings a little more light to my reasoning and thoughts on the idea. Maybe the best way to describe my thought process right now is an alternate virtual instruction and register set that shares a common runtime with parrot. I did a little research into implementing FORTRAN on parrot over the weekend, but decided that I don't know FORTRAN enough to do anything quickly with it. However, it sure sounds like a interesting and entertaining hack. -Jon Gentle On Thu, Feb 18, 2010 at 8:59 PM, Andrew Whitworth <[email protected]>wrote: > This is a good question, but I don't think there is going to be a good > answer. Parrot's design philosophy really is it's focus on > facilitating dynamic language. If you're looking for a VM that has a > similar focus on static languages, you may be more interested in JVM > or (for slightly more language-agnostic) .NET CLI. > > The problem with Parrot for these uses is that the "dynamic" part of > the philosophy is taken to the extremes. Even basic control flow > between functions is highly dynamic, which adds a certain amount of > runtime overhead that is unacceptable for most statically-typed > languages. For this and other reasons, it's really not going to be > worthwhile to implement most static languages on Parrot. It could be > an interesting novelty, and maybe it could be a tool to push the > boundaries of Parrot's compile-time optimizations, but it would never > reach the performance of a dedicated static-language VM like .NET or > JVM. > > The idea that two VMs could interact together is a nice one but in > practice I'm not sure how well it would work. You could try to embed > one into the other, but conversions to/from would be costly. Even > control flow would get extremely messy when you start to think about > things like closures and callbacks. Not to mention some of the more > advanced ideas. Consider the case where we pass a Parrot continuation > into a function from a static VM, and try to unwind both a call stack > and Parrot's dynamic call chain simultaneously. > > In short, I really like the idea, but conceptually I think there are > just too many problems to get passed for such a thing to work in a > useful way. > > --Andrew Whitworth > > > > On Thu, Feb 18, 2010 at 4:33 PM, Jon Gentle <[email protected]> wrote: > > Hello, > > > > I have been wondering for a few months now, how useful/appropriate is > parrot > > for static languages? If it's not, has there ever been any discussion > about > > a companion vm project? One that would not only be similar in design and > > philosophy, but would integrate with parrot and enable static and dynamic > > languages to coexist. > > > > The reason that I ask, is because some years ago, I worked on my own > little > > project called draak. It was aimed at being a compiler that didn't > > understand a particular language, but at runtime would load and parse a > > language's lex and parser from a text file and then compile it. I was > able > > to get all of that to work fairly well, but I never had a good > intermediate > > representation, instead I just used x86 asm as the output. In recent > years, > > I have gone back and forth on how to do a good IR, between using parrot, > > something like llvm, and rolling my own, but I could never get enough > worked > > through to make a decision. My question above is spawned from liking the > > concept and implementation that has been done so far with parrot, but > never > > sure if parrot would be good for static languages. While I was thinking > > through that, I had some musing that if parrot didn't fit the bill, could > > parrot have a companion project that would focus on static languages. > That > > would allow an entire dynamic/static language ecosystem to exist. > > > > I apologize if the question has been asked, discussed and answered > before. > > My google-fu is not as strong as it once was. > > > > -Jon Gentle > > > > _______________________________________________ > > http://lists.parrot.org/mailman/listinfo/parrot-dev > > > > >
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
