From: Benoit Cerrina <benoit.cerrina@...>
Date: 2002-02-16T06:00:45+09:00
Subject: Re: Ruby and .NET

> Ya, that's why a Ruby interpreter could never be developed in a language
> like C, right?  ^,^

The point is not to have a Ruby interpreter in .NET but to have a ruby
compiler
targetting .NET.

>
> A types value in the .NET interpreter could be an object that holds a
> Ruby type-less value.  In fact, the types values in .NET would be
> nothing but object references (like VALUE in the C code for Ruby).
ruby value are typed, the thing is the types can be modified and created at
runtime.
I work in the jruby project and I've looked in other dynamic language
which are targeted to the jvm and can tell you that it is fairly hard to do
because the jvm is not made for this.

I haven't tried with .NET yet but it seems a lot more flexible to me.  It
has facilities to dynamically generate IL (that is bytecode) and to modify
the
implementation of a method at runtime.
From my understanding I think a ruby compiler and runtime could be done, and
most
of the restriction would only be when interoperating with components written
in
other languages.

>
> > b.) .NET depends on things like attributes. Those would have to be added
> > to Ruby and things have to be done .NET style
>
> Not necessarily.  So long as Ruby compiles and runs in .NET, it serves
> the major purpose.  Attributes would only be needed to deal with .NET
> extension libraries.
Attributes would probably be used by ruby to add its own annotations to the
code.


>
> > c.) Prototyping (Cloning objects and adding methods etc.) would be hard
> > to do (Code blocks also).
>
> Hmm, how is that?  If C can do it, so can the CLR.  That is one of the
> biggest points of the CLR.
here the point is that C doesn't do it... the ruby runtime doesn't compile
the
blocks to C, the interpreter is written in C.  I'm sure that it would not be
easy but it would be a lot easier than in jvm bytecode.
Once more we do it allright in jruby because jruby is a java implementation
of the
ruby interpreter and even though we plan on adding it we are not generating
any
bytecode as of now.

>
> > d.) Most of the Ruby specific stuff that can be done (1-3) would be much
> > slower than C# because it has to be wrapped (iterators, code
> > blocks,...), so it boils down to use "def end" instead of "public method
> > { }", so why not use C# in the first place.
>
> Well, Ruby in .NET Framework would still be faster than normal Ruby,
> because it will be run thru a JIT... granted, the methods necessary to
> make Ruby work with .NET would make it still slower than straight C, I'd
> imagine it'd be a lot faster than just the Ruby interpreter as it stands
> now.
>
> >
> > I think integrating Ruby into Parrot might be a much better idea, or at
> > least jRuby and jPython should throw some resources together and make it
> > easier for other languages to compile to java bytecode. At least Java is
> > more open then .NET.
>
> Ya, a Parrot backend would be great for Ruby.  But that's no reason to
> not even bother with .NET.
I agree there.

I think that some of your arguments seems to mean you are thinking of a ruby
interpreter running on .NET (relatively easy, specially if we start from
jruby)
while others seems to mean you are thinking of what is more interesting, a
ruby
compiler and runtime which targets IL.  This is very different and more
difficult
but I think a lot easier than targetting the jvm.  The biggest difference is
that
java classes cannot be modified once they are loaded while I understand that
in
some circumstance it can be done in .NET (see the definition for
System.Reflection.Emit
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemreflectionemithierarchy.asp)
what is not clear to me is if you are able to modify some types which are
loaded from
a saved dynamic assembly (like you'd need to do to modify the ruby base
types like
what can be done in ruby).


I think that when reading about .NET one has to be really carefull about who
wrote the
articles and one should look at the real documentation also not only the
editorial peaces,
a lot of things are said either by fudding java proponents, or by anti
Microsoft fanatics
which are just untrue and a lot of things are said by Microsoft marketing
which may be
just a little overenthousiastic.  One thing also, I really don't give a ....
about web
services and the Microsoft side cannot help emphasizing this above all the
rest while to
me the .NET framework is what is important.
Benoit