I also wanted to blunt some criticism I received during the first Duby prototype. It represented types as symbols, but symbols nearly identical to their eventual Java types. In order for Duby to be generally useful (in, for example, Rubinius) platform-agnostic symbolic typing is a must.
So here's the code for my little C backend in its current state. It's pretty crude at the moment, but you can get the general idea. There's obviously work to do: it doesn't correctly insert "return" keywords, doesn't insert end-of-line semicolons everywhere appropriate (and often inserts them in totally inappropriate place), and in general doesn't produce entirely valid C code, but those are mostly minor details; the important takeaway here is that the typing and general Duby AST representation can easily be compiled this way.
Ok then! Given a simple script:
def fib(n)We can run the C "compiler" thus:
{n => :fixnum}
if n < 2
n
else
fib(n - 1) + fib(n - 2)
end
end
def go
fib(35)
end
jruby -rduby/plugin/math lib/ruby/site_ruby/1.8/duby/c_compiler.rb fib.rbAnd we get a fib.rb.c file as a result:
int fib(int n) {;As I said, it's not the prettiest thing in the world, but I think it demonstrates that Duby should easily be able to target pretty much any backend platform you like. Fun stuff!
if (n < 2) {n} else {fib(n - 1) + fib(n - 2)};
}
;
int go() {fib(35)}
;
G'day mate,
ReplyDeleteJust breezing through your Duby writings while waiting at the airport.
Feels like some of your type inference / hinting is very Haskell-like.
Any thoughts about tail recursion and lazy eval while you're at it? :-D
I expected the link you gave was C code. What do you mean by C backend then?
ReplyDelete