From: bjsp123@... (Benjamin Peterson) Date: 2003-07-22T23:34:27+09:00 Subject: Re: Advocacy: Ruby on/with .net Mauricio Fern�ndez wrote in message news:<20030721102840.GA1557@student.ei.uni-stuttgart.de>... > On Mon, Jul 21, 2003 at 07:20:29PM +0900, Benjamin Peterson wrote: > > Lothar Scholz wrote in message news:<1173309890.20030719135052@scriptolutions.com>... > > > Can you tell me if .NET supports fibers ? > > > > No, it supports real threads. > > How do you mix the lack of thread safety of Ruby's interpreter with .NET > real threads? I'm facing that problem with rjni (Java binding). It is just barely possible (but very unusual and perverse) to use fibers with .NET, as mentioned here: http://blogs.gotdotnet.com/cbrumme/PermaLink.aspx/9fd9222c-ee65-424d-867e-8e4e52ea394b --- However, I wasn't envisioning using the current Ruby interpreter, which is problematic in many ways. To enjoy the features we have been fantasizing about in this thread, I think we would need one of three major levels of functionality, listed easiest first: Level 1 Feature: Use .NET libraries Minimum Requirement: A module in Ruby to load and call .NET assemblies. It doesn't seem to be hard to write a C program to load ..NET assembly (and the runtime) and run a method (this is what assemblies in the form of .exes do all the time). Presumably this C code could be made into a ruby module. Level 2 Feature: Take advantage of .NET infrastructure (threads, unicode, etc) Minimum Requirement: A ruby interpreter (or bytecode compiler/interpreter) written in .NET, that reads ruby instructions and executes .NET code in response. There is one lying around 3/4 built already. Level 3 Feature: Fully integrate ruby modules with those in other .NET languages Minimum Requiremehnt: Compiler that compiles ruby code to .NET assemblies. This would be quite difficult, as CLI and the .NET type system are not at all designed for dynamically typed languages such as ruby. You would have to decide whether to implement types yourself, or to rely on dynamically adjusting .NET types, which is possible but might be slow and/or complicated. --- Level 1 should be just a matter of using the common language runtime hosting interface and calling CorBindToRuntimeEx to get an ICorRuntimeHost, then picking a module and loading it into an app domain etc etc. Very easy, if all you want to do is call methods one after another -- if you want to switch back and forth between ruby code and C# code I don't know what problems would arise. Level 3 would be a very large project and would probably involve an industrial amount of work. Although the .NET runtime can support modifying a type on the fly, I don't think this would actually allow ruby types to be represented 1-to-1 by .NET types. Perhaps the .NET lisp projects have some insight into this. Level 2, my favorite, would involve: 1--creating and maintaining a ruby grammar with c# or c++ bindings (antlr?) 2--implementing ruby libraries in .net 3--implementing a ruby interpreter that joins (1) to (2) :) ....plus a few other things. Number 1 sounds like the hard part to me. --- Given that what I mostly want are the features in level 2, and that level 3 is probably very hard, I would most like to see a project to implement level 2, and if there were a live project then I'd try to join in with it (hint hint). The abandoned one (NETRuby) really looked good, although keeping the grammar in step with that of ruby itself is a task I can't handle. > I hope your grandchildren won't use Windows anymore. > Of course not, I was just joking. In fact they'll use Open BeTRON, the BTRON-based open source version of BeOS which is currently still secret -- oops.