------extPart_000_0000_01C4F589.389CC7A0
Content-Type: text/plain;
	charsets-ascii"
Content-Transfer-Encoding: 7bit

Hello all,

I was wondering whether it would be possible to have a type inference system
in ruby.  My question was asked before
<http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/95821>  by
gabriele renzi but it never received much of a response.  This system might
try to figure out whether you are writing code with some obvious errors.
There has been a  <http://www.cc.gatech.edu/~lex/ti/ti.html> project on this
for smalltalk.  For instance if you have a function like the following

 

def foo(object)

return object.call(9, 7, 3)

end

 

couldn't the type system figure out that object must respond to the call
command and thus eliminate an error like:

 

foo(5)

 

I guess I am also wondering about a lot of other things like why do you need
multiple assignment in Ruby?  There doesn't seem to be any need for it since
you can just modify an object by sending it a message eg x   + 1 is the
same as x.+(1).  I am not sure if this would help type inference systems but
it seems like it should.  There is a  <http://rubyforge.org/projects/truby/>
ruby project that is trying to create a type inference system although it is
very experimental.  Can people give some examples where type inference would
be very difficult in Ruby?   Does anybody know what kinds of things make it
difficult to do type inference in a language.  On the smalltalk type
inference project site they say the following 

 

"Type inference in Smalltalk-like languages has been studied since at least
1981, when Norihisa Suzuki published a type inference algorithm for
Smalltalk-80. Chuck's algorithm DDP is unusual, however, in two ways: it is
demand-driven and prunes subgoals. A demand-driven algorithm is architected
around the notion of "goals", where each goal is either answered directly
("what is the type of 47?"), or via subgoals ("what is the type of x+y?").
The advantage of this approach is that, whenever too many goals are being
studied, it is possible to "prune" some of the goals by giving them obvious
but poor answers ("the type could be anything"); the analysis can then
procede, and it may still find good answers to other questions. Pruning in
this fashion does not appear possible in the competing approaches of
abstract interpretation and of constraint solving; such approaches must
completely solve any subproblems they generate."

 

It seems like a system like this would be good for Ruby because it would
allow you to catch some errors and maybe even do some optimizations if you
were making a compiler since you would know the representations of some of
the objects.

 

Regards,

Trevor Andrade


------extPart_000_0000_01C4F589.389CC7A0--