From: Trevor Andrade Date: 2005-01-09T05:28:25+09:00 Subject: Re: Type inference in ruby Let me just point out that I am NOT ADVOCATING STATIC TYPING. I don't think ruby should force users to static type. I am also not advocating any changes whatsoever to the language Ruby with one exception and that is multiple assignment which I don't see any need for. I could, of course, be wrong and if anybody knows a good example where multiple assignment makes things easier I could easily be persuaded that it is useful. I guess the only reason for preserving multiple assignment that I can think of is to preserve idioms like x = x + 1 which as pointed out is different from x.+(1). You could of course make x = x + 1 translate into x.+(1) as a bit of syntactic sugar but that might lead to other problems. Type inference is something that would exist in the interpreter as some kind of error messages. You could turn it off if necessary. I think that in most cases it would be helpful in that it would catch real errors and I believe although I can't prove this that any ruby program at all no matter how dynamic would pass through the type inference system without any error provided it did not have any statement that if executed would lead to an error of the form "NoMethodError: undefined method 'foo' for someobject". This of course is the error you get when you call a method on an object that does not have that method defined. In a dynamic language like Ruby errors of the form I alluded to above are the only type errors that I believe are in general possible. I have a very simple model for object oriented language like Ruby which is probably wrong but I think ultimately captures the gist of things. In Ruby or Smalltalk you can only essentially do one thing and that is send messages to objects. Everything in Ruby consists of essentially message passing. Thus the only error possible is that an object does not know how to respond to a message. Of course my model is not completely correct because ultimately in any language you have to actually "do something" at some point. For instance if you want to add 2 numbers or concatenate a string that is "doing something" and not just message passing. However the "doing something" part of Ruby and Smalltalk only exists either at the lowest levels of the language that are built in or in extensions to the language written in c. You cannot define how to add integers in Ruby and in fact you cannot even define integers themselves. Integers are low level constructs that must be built into the language. You can still even do type inference at this low level because the number of low level object are finite and the built in operations you can do with them are already defined like for instance adding integers or concatenating strings. So it always known that you can't add an integer to a string and this can always produce an error before runtime which currently does not happen. For instance you can run the following in ruby and it is valid def ass(blah) q = 4 + "fjdkjkf" end and I this error will be caught only at runtime. There is only one thing wrong with type inference and that is that new methods can be defined at runtime in Ruby which means it is possible that an object does not know how to respond at compile time to a message but it does know how to respond at runtime. However I think this scenario happens very rarely and if it was happening the programmer could just turn off type inference.