Pascal H. 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
