On 02/06/02 Larry Wall wrote: > Black pots and kettles aside, they bring up a lot of interesting issues > that we have to think about if we're going to be more language-neutral > than the CLR.
The main issue is that there is a point where too much generality will make the VM too hard to target code for. One could develop a VM that uses the nice sparc instruction set, but writing compilers for it would be too hard, that's why many languages are interpreted, because generating machine instructions is hard (even when you target a single instruction set). Yes, portability is an issue, too, but if that was the case, we'd have jitters for perl/python/ruby/whatever for the main cpus for a long time. A VM will always favour a particular language (hey, cpus favour C over perl, for example:-). The CLR favours IL _and_ C# (there are many features in the CLR not used by C#), but it has enough features that make it easier for a lot of languages to target it (function pointers, tail recursion, alloca to name a few). Some languages will need more work to port to the CLR than C# and for sure a Perl on CLR method invocation will be slower than a C# method invocation, but that is true on todays systems as well:-) There is a difference from a VM that makes supporting any langauge hard and a VM that makes it hard only for a few. A VM that supports all the languages on the same foot means that it supports all of them badly:-) How will method invocation work on the parrot VM? You'll need a invoke() vtable slot that does all the magic and guess what, you'll need to do the same if you target the CLR. Currently it's not clear how much advantage a parrot VM could give over a VM like the CLR, but I guess we'll see that only when perl 6 will use it. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
