[Mono-list] Making a ruby.net compiler

[Paolo Molaro]

On 05/08/03 Alan Knowles wrote:
> AFAIK), I think looking closer at parrot as a target CIL may be more 
> relevant. although you 'can' map a dynamicly typed language into .NET, 
> it's a bit closer to a square peg in  a round hole..

Currently, probably the only feature parrot has that would not
map to the CLR directly is continuations (though I don't know if
continuations are already implemented or only planned).
Perl, python, php and a lot of other dynamic langauges don't use 
continuations, so there is no reason why parrot should be a better fit
for those dynamic languages than the CLR (or, more specifically) mono.
Of course, there are tradeoffs: python or perl ported to run on the CLR
_will_ almost certainly run slower than with their native interpreters.
How important is this? Of course it depends how much slower, but you
will also have to consider the benefits of interoperability and the fact
that, if you have code that really needs to be fast, you can write that
part of the code in C#, for example, so things may well even out in the
end speed-wise.

The issues when porting a dynamic language to the CLR are of a different
nature (and they apply as well to _any_ attempt to port one of our
favourites dynamic languages to any VM, I just consider the CLR here,
because it's the one that provides more features than any other to
implement a wide range of languages):

1) it's not a week-end project: think of perl or python: it required
several years for both to reach their current level of features and
performance. While I don't expect it to take that much time to port such
langauges to the CLR, it's sure a few months work to implement 80-90 % of
the functionality by some dedicated people.

2) The remaining 10-20% are undocumented features or implementation
details of the original interpreter that is hard or costly to implement
or that simply we don't know they exist and many developers may have written 
code that relies on the 'feature', so a port to the CLR would always get
the mantra: "it's not a complete port" or "it's not bug-compatible".
Basically, the port will get flamed because of issues in the original
interpreter or because of a lack of a specification:-)

3) Basically all of the dynamic languages have a different way to lookup
the method to call or to handle the semantics of some operations: a VM
that wishes to support more than one can do two things:
	*) provide a very fast execution engine (jit) so that the
	semantics for each langauge can be expressed in the low-level
	bytecode, but they are still fast to execute
	*) allow the VM to be extended with functions in C which do the
	hard work. I would love to help people design, for example,
	InternalCalls in mono that implement the semantics of a specific
	dynamic language so that it can run adequately on the mono
	runtime. If the design is good, we may well propose it for
	inclusion in the ECMA standard.
The issue, here, is that no common mechanism has been designed for a VM
to implement support for the major dynamic languages, I guess basically
because the semantics are so varied. We should get the designers of such
languages in a room without food until they come up with a workable
design;-) I can offer the room and to implement the required changes in
mono myself:-)

4) A design for interoperability between the dynamic languages and the
static typed ones is needed. How do you call a dynamic method from a
static typed language and how do you call a method in a strongly typed
assembly from a dynamic language? Both could be done with the existing
Invoke() interface in Reflection, but there may be better ways.
Worse is the issue with handling multiple inheritance vs single
inheritance: how do you map between both systems?

So far what happened with the virtual machines for the common dynamic languages
is that they only considered the point 1, with the additional help that
they didn't have to port a language, but they had the much more fun job
of actually defining it;-)

Once you actually write down the issues involved, you'll see that
Parrot has basically no technical advantage over the CLR or mono for
supporting dynamic languages like Perl, python or PHP. Worse, they
basically are going to ignore issue number 4 (after all, if they built
yet another strongly-typed VM it would be pretty boring:-) and issues
2 and 3 are pretty much yet up in the air (but it's not their fault,
using mono or the CLR as the VM for the languages would pose the same
issues). Since I'm following the development of parrot almost since the
beginning (and I tryed to contribute myself to some discussions) I must
also say that the Parrot project is very important for trying to bring
out the issues of supporting multiple dynamic languages in a VM and,
being a perl programmer at heart, I really hope they succeed. It will be
very important how much support they get from the python, php and ruby
communities, though, not only from the perl folks: this would certainly
help at least with issue number 1 in my list.

The bottom line is: if there is a design for running dynamic lanagues on
a VM and have them interoperate, we would very much like to know it so
that we can help implementing it in mono. Alas, nobody came up, yet,
with such a design, not even the parrot hackers.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better