//I am not going to write an interpreter on .NET (nor on
//Parrot) but anyone else can.
//
//In the future, people may use Ruby on .NET or Ruby on Parrot
//daily, and my interpreter would be a reference implementation.
//
// matz.
Accepted Matz. It would also be unfair that everyone brings their
problems to you and you are expected to keep solving them. I am looking
forward to the ideas you put into Rite.
Maybe sometime Rite itself can be extended to bridge to .Net, such that
Ruby is its best under Rite and the interop bridge is the only slow
link. Sometime when you have designs for Rite available I would really
like to see the features the runtime offers.
I however request you to put up reasons why Ruby wasn’t targetted for
the CLR sometime - even if that reason was simply ‘I want to enjoy
writing my own VM’. There is a reason why I am asking you for this.
There are people at MS and ouside who are serious about getting the CLR
(or CLI) to provide better support for functional and dynamic languages.
Having a solid set of cases againt Ruby running on the CLR could direct
sufficient research in that direction, which on the whole is a good
thing.
In message “Re: Ruby on .NET (was Re: A Ruby WishList)” on 04/04/22, “James, Roshan (Cognizant)” JRoshan@blr.cognizant.com writes:
I however request you to put up reasons why Ruby wasn’t targetted for
the CLR sometime - even if that reason was simply ‘I want to enjoy
writing my own VM’.
I want to enjoy writing my own VM.
I don’t want to restrict the language design by VM feature.
The latter is more important. When I design new feature for Rite,
I don’t want to wait other projects (say .NET) to add VM function.
//I am not going to write an interpreter on .NET (nor on
//Parrot) but anyone else can.
//
//In the future, people may use Ruby on .NET or Ruby on Parrot
//daily, and my interpreter would be a reference implementation.
//
// matz.
Accepted Matz. It would also be unfair that everyone brings their
problems to you and you are expected to keep solving them. I am looking
forward to the ideas you put into Rite.
Maybe sometime Rite itself can be extended to bridge to .Net, such that
Ruby is its best under Rite and the interop bridge is the only slow
link. Sometime when you have designs for Rite available I would really
like to see the features the runtime offers.
I however request you to put up reasons why Ruby wasn’t targetted for
the CLR sometime - even if that reason was simply ‘I want to enjoy
writing my own VM’. There is a reason why I am asking you for this.
There are people at MS and ouside who are serious about getting the CLR
(or CLI) to provide better support for functional and dynamic languages.
Having a solid set of cases againt Ruby running on the CLR could direct
sufficient research in that direction, which on the whole is a good
thing.
I have a student doing a proof-of-concept Ruby-to-CIL compiler. We
expect to have something to show in late May. It is unclear if it will
be of any use more than showing what is missing in CLR to support
dynamic languages in a good way. OTOH, so far it looks rather promising;
we even found a way to dynamically redefine methods without bending over
backwards…
Matz, I do respect your conviction toward the well being of Ruby. Let other
worry about Ruby on .NET instead, therefore you can concentrate how to make
this language the most natural language for beginners and experts developers
to develop application and add its basic functionality without being
restricted by other(especially MS) that might have other agenda.
Love your spirit.
Vive Matz.
“Yukihiro Matsumoto” matz@ruby-lang.org wrote in message
news:1082629076.417186.11065.nullmailer@picachu.netlab.jp…
···
Hi,
In message “Re: Ruby on .NET (was Re: A Ruby WishList)” > on 04/04/22, “James, Roshan (Cognizant)” JRoshan@blr.cognizant.com writes:
I however request you to put up reasons why Ruby wasn’t targetted for
the CLR sometime - even if that reason was simply ‘I want to enjoy
writing my own VM’.
I want to enjoy writing my own VM.
I don’t want to restrict the language design by VM feature.
The latter is more important. When I design new feature for Rite,
I don’t want to wait other projects (say .NET) to add VM function.
I have a student doing a proof-of-concept Ruby-to-CIL compiler. We
expect to have something to show in late May. It is unclear if it will
be of any use more than showing what is missing in CLR to support
dynamic languages in a good way. OTOH, so far it looks rather promising;
we even found a way to dynamically redefine methods without bending over
backwards…
David Simmons, the creator of Smallscript/S# [0] (Smalltalk for .Net),
used to frequent this list. I believe he has discussed many of the
issues with porting a dynamically-typed language to the CLR (some on
ruby-talk, but also at [1]).
Let me add some information about Smalltalk and .NET.
There has been an announcement for a new Smalltalk for .NET (Vmx
Smalltalk) in comp.lang.smalltalk yesterday. With S# and #Smalltalk
that makes at least three Smalltalk dialects with main focus on .NET.
I am not sure about ongoing activities in other dialects but Squeak
got it’s .NET bridge from Ruby and VisualWorks ships a first .NET
connection with Version 7.2.
David Simmons, the creator of Smallscript/S# [0] (Smalltalk for .Net),
used to frequent this list. I believe he has discussed many of the
issues with porting a dynamically-typed language to the CLR (some on
ruby-talk, but also at [1]).
