I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
Diamondback Ruby (DRuby) is a research project that aims to bring the
benefits of static typing to Ruby without compromising the feel of the
language. The main features of DRuby are:
* Type inference: DRuby uses inference to model most of Ruby's idioms
as precisely as possible without any need for programmer
* Type annotations: Methods may be given explicit type annotations
with an easy to use syntax inspired by RDoc.
* Dynamic checking: When necessary, methods can be type checked at
runtime, using contracts to isolate and properly blame any errant
code, similar to gradual typing.
* Metaprogramming support: DRuby includes a combined static and
dynamic analysis to precisely model dynamic meta-programming
constructs, such as eval and method_missing.
Although still in development, DRuby is already able to type small,
self-contained applications. We are working to improve DRuby's
analysis so that it can type larger code bases, including the standard
library which is not yet supported. Most of DRuby is implemented in
OCaml, but pre-compiled binary gems are available for several
platforms from our webpage. Anyone who is interested in developing
their own program analyses for Ruby are also encouraged to check out
DRuby, as the core implementation is intended to be of general use.
If you are interested in hearing about future releases, or have any
questions or comments, please join our mailing list (see the above
How about the language journal all the results of running the
user-programmer's unit tests, and use them to determine the actual types
currently in use?
Ho..., there is a typo in the first example of the quick start
in duck1.rb, shouldn't
Looks interesting. I managed to get all the dependencies installed (I
think), but I got stuck here:
--- Checking for ocamlgraph... ocamlfind: Package 'ocamlgraph' not found
I can see the graph* files under /usr/local/lib, though.
Could this be because they're called "graph" instead of "ocamlgraph"?
Otherwise I'm lost.
OCaml 3.11, Linux (Ubuntu), latest stable version of all dependencies.
FWIW, the name "druby" already has a history:
But otherwise, quite cool looking.
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
Cool. I wonder if it could integrate with yard or what not.
Nice. I wonder if a psyco-like JIT could leverage this :)
Mike Furr and his co-worker Mike Hicks were kind enough to
do an interview with me about Diamondback Ruby. I've posted
Don't judge those who choose to sin differently than you do
What's an example of it in use? Could it theoretically be used to create
a ruby->c translator?
(i.e. here's all my ruby--spit it all out as C for me :)
Diamondback Ruby is intended to be another development tool in the
Rubyist's toolbox. When developing an application, you can use it to
discover bugs that may have been missed by your test suite or to verify
documentation through the use of explicit type signatures.
Diamondback Ruby is built on top of a framework for Ruby source code
analysis and transformation, so "theoretically" you could use that to
build such a translator. However, the framework only gives you a
representation of the Ruby syntax (not unlike RubyParser) and does not
directly reason about the evaluation of this code. Thus, a C translator
would need significantly more information about the semantics of Ruby,
as all of this would have to be encoded in the emitted C code.
gotcha--it shows you paths you may not have anticipated.
Interesting. There are a few projects like ruby2c  that have
attempted "something like that" I wonder if, given a code base of say a
few ruby files that together make up a system, and, operating under the
assumption that the code never uses define_method or eval or
method_missing, you could convert the whole thing into C :)
Has anything similar been invented?
 http://betterlogic.com/roger/?p=1170 comment 1 lists a slew of them.
There have been several projects that attempt to translate high level
languages into C (e.g., the Scheme Chicken compiler). However, I don't
know why you would want to do this for Ruby now that 1.9 uses a proper
VM. Instead of developing a compiler to target C, why not just target
the YARV bytecode? If you are trying to really optimize Ruby, then
you'll likely want both static optimizations (generating efficient
bytecode, minimizing GC pressure), and dynamic optimizations (hotspot
JIT compilation). The latter is especially important for Ruby since you
could support for features like eval (just eject any optimizations that
are invalidated by the eval'd code and recompile as necessary). In
fact, I believe that many of the ideas that went into making the JVM so
efficient came out of the Smalltalk community's work on optimizing
Perhaps you can explain this slightly more so I know what you meant
exactly? As you mentioned there's kind of two sides to the
optimizing--the initial static stuff and the dynamic "oh this has
changed let's recompile" stuff. Ahh so you are referring to the dynamic
side when you refer to "targeting bytecode"?
Yeah I still wish for a psyco for Ruby -- wishes are cheap. I'd imagine
the first step is to get the static side going, though, hence my
focusing on that.
I suppose that's all you'd need for "small scripts that don't use eval
or change methods after a fixed load time"
but you're right--being able to JIT compile [either to c, like ruby
inline, or to llvm/libjit] would be best. There have been some limited
efforts in this regard (ludicrous, jruby), but not much for KRI.
Gotcha--so currently diamondback ruby is basically used to "double check
your unit tests" to make sure that there is no chance you would pass in
an object to a method that doesn't "quack right" [i.e. wrong object
somehow]. Does it with both static and dynamic analysis. That's cool.
My first request from such a project would be it being able to generate
the rdoc style
##% something -> something_else
*for* you so that it could be fed into a C translator or what not.
i.e. druby file.rb > file_with_types.rb