Pascal Hurni wrote: > I discovered ruby some month ago and I liked it in a bunch of > minutes. Then I was involved in a project using ASP.NET. At this > point I had a dream ;-) Ruby that works on .NET (knowing ruby, > neither VB nor C# fits!) . I found some material, but nothing useable > or 100% .NET, so I took some time and decided to create a ruby > compiler. [...] Get it, try it, read it, and tell me what you think. > Is this project worth continuing? This looks very promising and I hope it will continue to be developed. I'd really like to see something like this working very well. Perhaps even in a boot-strapped, self-hosting way which would be possible with .NET. And I think your approach is going to be self-hosted. This is the way I have dreamed of doing it in the past. Regarding implementation of the standard library. I've done part of it in JavaScript [1] already and another very small part in Ruby [2]. I've tried to make the implementation as self-based and simple as possible. I hope it is of some use to you. I'm not sure in what state your parser is currently in, but you might be able to heavily cheat with this by either only accepting YARV byte code as input or by letting Ripper or ruby -y do the hard work for you. This would mean needing to call an external binary for things like eval() at first, but for an initial version that would be good enough, I think. Continuations are very hard to do, but it might be possible to do them for the Ruby side with a heavy transformation of method calling code. I've thought about this in the past [3], but I think continuations could still be added very, very late when other things already work. Regarding .NET interoperability: Using Ruby objects from .NET is the hardest to do. Think about things like method_missing() and you will realize that rubyObj.method() will not be good enough. You probably would need to do rubyObj.send("method") in all .NET code. The other way around is more important at first because it would allow you to implement the standard library in Ruby while using .NET infrastructure. (Very handy for things like Regular Expressions, Date stuff, IO and probably yet more.) It would be very wonderful if the run time could automatically translate Ruby's blocks to .NET's delegates and so on. But this is a convenience feature as well. Not strictly necessary at first. > A method definition can also use "pass remaining param as an array". > What should we do with this? Is there vararg in CLS ? From what I understand C# and so on implement varargs by accepting an array as the last argument. You can forward arguments that way as well. So it's pretty much syntax. The same could be done for Ruby. You could annotate the methods as having varargs to make the distinction clearer. Regarding blocks: Mono's JScript.NET solves that kind of thing (how to pass information for closures and so on) by passing in a single engine argument. It can be used to find out information for context and so on. I imagine this would also work well for Ruby. A delegate would mostly work, but you can't handle this case: a = "foo" foo() do eval("a") end Because you don't see the access of the variable a in the block at compile time. So you need some kind of mechanism to access parent scopes at run time. This is what the engine would do. I'd ignore the whole String thing for now. Ruby's strings are going to change quite a bit very soon. For now I think it would be enough to do the simplest thing: Unicode strings. Hope all of this is of some help to you. Good luck! [1] http://flgr.dyndns.org/ruby.js/ [2] http://flgr.dyndns.org/code/method-dict.rb [3] http://flgr.dyndns.org/callcc-cil.rb -- http://flgr.0x42.net/