Forum: Ruby [ANN] Diamondback Ruby - Static Typing for Ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Mike F. (Guest)
on 2009-04-23 02:27
I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!

          http://www.cs.umd.edu/projects/PL/druby/

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
   intervention.

 * 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
webpage).

Cheers,
Mike F.
Phlip (Guest)
on 2009-04-23 02:56
(Received via mailing list)
> webpage).
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?

http://www.oreillynet.com/onlamp/blog/2008/05/dyna...
Louis-Philippe (Guest)
on 2009-04-23 03:06
(Received via mailing list)
Ho..., there is a typo in the first example of the quick start
in duck1.rb, shouldn't

puts d.qauck

first be

puts d.quack

?




2009/4/22 Mike F. <removed_email_address@domain.invalid>
Mike F. (Guest)
on 2009-04-23 03:12
Phlip wrote:
>> webpage).
> 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?
>
> http://www.oreillynet.com/onlamp/blog/2008/05/dyna...

We do use the programmer's test suite to augment the typing analysis
(for things like eval), but one of the main advantages of the static
analysis, is that it can determine the types used at every program
point, even those not covered by the test suite.
Mike F. (Guest)
on 2009-04-23 03:13
Louis-Philippe wrote:
> Ho..., there is a typo in the first example of the quick start
> in duck1.rb, shouldn't

Oops, thanks!  (fixed)

-Mike
Daniel B. (Guest)
on 2009-04-23 05:14
(Received via mailing list)
Mike F. wrote:
> I am pleased to announce that the first public release of the
> Diamondback Ruby static type inference system is now available!
>
>           http://www.cs.umd.edu/projects/PL/druby/

<snip>

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.

Regards,

Dan
James B. (Guest)
on 2009-04-23 05:39
(Received via mailing list)
Mike F. wrote:
> I am pleased to announce that the first public release of the
> Diamondback Ruby static type inference system is now available!
>
>           http://www.cs.umd.edu/projects/PL/druby/
>
> 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:

FWIW, the name "druby" already has a history:

   http://raa.ruby-lang.org/project/druby/

   http://www.cse.dmu.ac.uk/~hgs/ruby/dRuby/


But otherwise, quite cool looking.



--
James B.

www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
Mike F. (Guest)
on 2009-04-23 17:19
Daniel B. wrote:
> 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.

The way DRuby detects dependencies is by querying ocamlfind, so if
you're installing the dependencies by hand, you need to be sure you
install the ocamlfind "META" files.  For ocamlgraph, you need to run
"make install-findlib" to install these and I think that should fix your
problem.

-Mike
Roger P. (Guest)
on 2009-05-01 14:38

>  * Type annotations: Methods may be given explicit type annotations
>    with an easy to use syntax inspired by RDoc.

Cool.  I wonder if it could integrate with yard or what not.

>
>  * 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.

Nice. I wonder if a psyco-like JIT could leverage this :)
-=r
pat eyler (Guest)
on 2009-05-07 19:29
(Received via mailing list)
On Wed, Apr 22, 2009 at 4:27 PM, Mike F. <removed_email_address@domain.invalid> 
wrote:
>
> I am pleased to announce that the first public release of the
> Diamondback Ruby static type inference system is now available!
>
>          http://www.cs.umd.edu/projects/PL/druby/
>

Mike F. and his co-worker Mike Hicks were kind enough to
do an interview with me about Diamondback Ruby.  I've posted
it here:

http://on-ruby.blogspot.com/2009/05/diamondback-ru...


--
thanks,
-pate
-------------------------
 Don't judge those who choose to sin differently than you do

http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com
Roger P. (Guest)
on 2009-05-25 23:04
> I am pleased to announce that the first public release of the
> Diamondback Ruby static type inference system is now available!

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 :)
Thanks!
-=r
Mike F. (Guest)
on 2009-05-26 23:27
Roger P. wrote:
>> I am pleased to announce that the first public release of the
>> Diamondback Ruby static type inference system is now available!
> What's an example of it in use?

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.

> Could it theoretically be used to create a ruby->c translator?

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.

Cheers,
-Mike
Roger P. (Guest)
on 2009-05-27 16:40
> 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.

gotcha--it shows you paths you may not have anticipated.


>> Could it theoretically be used to create a ruby->c translator?
>
> 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.

Interesting.  There are a few projects like ruby2c [1] 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?
-=roger


[1] http://betterlogic.com/roger/?p=1170 comment 1 lists a slew of them.
Mike F. (Guest)
on 2009-05-27 20:21
Roger P. wrote:
> Interesting.  There are a few projects like ruby2c [1] 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?

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
dynamic VMs.

Cheers,
-Mike
Roger P. (Guest)
on 2009-05-29 16:53
> 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?

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"?

> 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
> dynamic VMs.

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.
Thoughts?
-=r
Roger P. (Guest)
on 2009-06-01 20:12
Mike F. wrote:
> Roger P. wrote:
>>> I am pleased to announce that the first public release of the
>>> Diamondback Ruby static type inference system is now available!
>> What's an example of it in use?
>
> 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.

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
Cheers!
-=r
This topic is locked and can not be replied to.