[Mono-devel-list] Re: Re: Dynamically changing classes?
lupus at ximian.com
Fri Sep 26 11:37:19 EDT 2003
On 09/25/03 Thomas Sondergaard wrote:
> But I believe it is wrong to treat implementation and interoperability as
> separate issues in this particular case. The main argument for implementing
> a dynamic language on the CLR is the interoperability. If you don't get any
> interoperability benefits why suffer the performance degradation you are
> likely to see with a CLR implementation rather than a native implementation?
Sure, that's why two thirds of my mail were about interoperability:-)
If you have any comments on the proposed solutions to the issues you
were seeing, please let's discuss them.
I'll also add another data point: full interoperability between very
different languages is impossible. You can't make C# access directly some
features of dynamic languages like ruby or perl, simply because it
doesn't make sense from the C# side of things. So you have two ways:
*) dumb down the dynamic language, removing most of its features and
making it just a different syntax to programming in C# (this is what was
largely done with VB and it's the way where implementation and
interoperability are considered the same thing: if something is not
interoperable, it's not implemented). Obviously this is a bad idea:-)
In the same way, if the prospect is to implement just what is
interoperable, you may end up saying (as some do) that the CLR can't
cope with some languages, when in fact it's not the CLR that matters,
but the syntax/features of the different languages.
*) implement most/all of a dynamic language features and make the
language interoperate as best as possible *whithin* a language
syntactic and execution model. This way what is implementable is
distinct from what is interoperable. For example: Perl's handling of the
parent list for a package makes sense only within perl (and few other
dynamic languages): it doesn't make sense to expose the feature to C#.
You can easily add an additional method to the IObject interface or
define another interface and have all the dynamic languages that support
the feature implement the interface for interoperability.
Some CLR critics will say that the CLR should support such features
(mostly because they are lazy and don't want to implement it
themselves:-), but this would be a huge mistake. For example, making the
CLR support multiple inheritance and changing parent types of a type
would slow down by orders of magnitude many common operations in
langauges like C# that can otherwise produce fast code. If that was the
case, you'd have a slow VM in exchange for lazyness on the part of
dynamic languages implementors: I prefer the speed, plus I don't have to
implement the feature in mono:-)
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list