From: Trevor Andrade Date: 2005-01-09T03:54:13+09:00 Subject: Type inference in ruby ------=_NextPart_000_0000_01C4F589.389CC7A0 Content-Type: text/plain; charset="us-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 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 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 = 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 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 ------=_NextPart_000_0000_01C4F589.389CC7A0--