# Type inference **URL:** \ **Category:** ruby-talk\ **Created:** [3 October 2005 15:14 UTC](https://rubytalk.org/t/type-inference/21282 "2005-10-03T15:14:43Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [3 October 2005 15:14 UTC](https://rubytalk.org/t/type-inference/21282/1 "2005-10-03T15:14:43Z")
Yes, "we" do. As in the Ruby community. And I'm willing to be that presumptious because I happen to have spent time looking into how this can function as an enabling technology for both the possibility to compile Ruby (though I don't think that that should be to C++), for static analysis, and possibly for better introspection. I'm somewhat uncertain about the latter, because there are cases where the types cannot be inferred perfectly (perfect inference of types in Ruby is a reformulation of the halting problem). There are immediate speedups possible from type inference, even with an interpreter: We could lose dynamic dispatch for most cases "under the hood" - we would still have duck typing, it's just that the interpretation would go faster (it would probably be necessary with a prescanning step, though, as the inference can take time.) I think there might be more uses, too - though the above is more than enough to make this important. Eivind. > **路路路** > > On 10/3/05, Tanner Burson \ wrote: > > > On 10/3/05, Eivind Eklund \ wrote: > > \> If you don't, please stop scaring people - we want them to go > > \> implement type inference for Ruby 馃檪 > > > > 'We' do? ---
**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\ **Post date:** [3 October 2005 15:27 UTC](https://rubytalk.org/t/type-inference/21282/2 "2005-10-03T15:27:19Z")
Hi -- > **路路路** > > On Tue, 4 Oct 2005, Eivind Eklund wrote: > > > On 10/3/05, Tanner Burson \ wrote: > > > > > On 10/3/05, Eivind Eklund \ wrote: > > > > > > > If you don't, please stop scaring people - we want them to go > > > > implement type inference for Ruby 馃檪 > > > > > > 'We' do? > > > > Yes, "we" do. As in the Ruby community. > > I think "we" would be better off not predicating membership in the > Ruby community on interest in a particular project or direction of > development. It's inaccurate, in this case, and rather an > unattractive precedent. > > Thanks -- > > David > > -- > David A. Black > dblack@wobblini.net ---
**Author:** ![Eric\_Mahurin1](https://avatars.discourse-cdn.com/v4/letter/e/34f0e0/32.png) [@Eric\_Mahurin1](https://rubytalk.org/u/Eric_Mahurin1)\ **Post date:** [3 October 2005 15:46 UTC](https://rubytalk.org/t/type-inference/21282/3 "2005-10-03T15:46:50Z")
I kind of talked about this before in a previous thread: [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/5563](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/5563) To take advantage of type (really class) inference in an optimal way, you'd need to know that the methods aren't changing. There may be some very difficult ways to handle changing methods, but you will burn performance (runtime and/or memory). I was basically proposing that there be a way to freeze methods and prevent certain methods from being overridden (java: final, c++: non-virtual). All of those methods would have good optimization potential. > **路路路** > > --- Eivind Eklund \ wrote: > > > On 10/3/05, Tanner Burson \ wrote: > > \> On 10/3/05, Eivind Eklund \ wrote: > > \> \> If you don't, please stop scaring people - we want them > > to go > > \> \> implement type inference for Ruby 馃檪 > > \> > > \> 'We' do? > > > > Yes, "we" do. As in the Ruby community. And I'm willing to > > be that > > presumptious because I happen to have spent time looking into > > how this > > can function as an enabling technology for both the > > possibility to > > compile Ruby (though I don't think that that should be to > > C++), for > > static analysis, and possibly for better introspection. I'm > > somewhat > > uncertain about the latter, because there are cases where the > > types > > cannot be inferred perfectly (perfect inference of types in > > Ruby is a > > reformulation of the halting problem). There are immediate > > speedups > > possible from type inference, even with an interpreter: We > > could lose > > dynamic dispatch for most cases "under the hood" - we would > > still have > > duck typing, it's just that the interpretation would go > > faster (it > > would probably be necessary with a prescanning step, though, > > as the > > inference can take time.) > > > > I think there might be more uses, too - though the above is > > more than > > enough to make this important. > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > **[Yahoo Mail - Organized Email](https://mail.yahoo.com/)** > > > > It's time to get stuff done with Yahoo Mail. Just add your Gmail, Outlook, AOL or Yahoo Mail to get going. We automatically organize all the things life throws at you, like receipts and attachments, so you can find what you need fast. Plus, we've got... ---
**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\ **Post date:** [3 October 2005 16:03 UTC](https://rubytalk.org/t/type-inference/21282/4 "2005-10-03T16:03:19Z")
Hi -- > To take advantage of type (really class) inference in an > optimal way, you'd need to know that the methods aren't > changing. What about type (really type) inference? 馃檪 There have been some interesting projects looking at the matter of checking types in Ruby (not based on class/module membership), including one by Eivind and I think one by Florian Gross. It's not easy... but anything less is, I think inevitably and almost by definition, going to reduce what one can do in Ruby. David > **路路路** > > On Tue, 4 Oct 2005, Eric Mahurin wrote: > > -- > David A. Black > dblack@wobblini.net ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [3 October 2005 16:50 UTC](https://rubytalk.org/t/type-inference/21282/5 "2005-10-03T16:50:01Z")
I meant it quite differently and much more positive: As an inclusive "what I believe to be a majority opinion, at least given an informed majority" (without excluding anybody.) Eivind. > **路路路** > > On 10/3/05, David A. Black \ wrote: > > > Hi -- > > > > On Tue, 4 Oct 2005, Eivind Eklund wrote: > > > > \> On 10/3/05, Tanner Burson \ wrote: > > \>\> On 10/3/05, Eivind Eklund \ wrote: > > \>\>\> If you don't, please stop scaring people - we want them to go > > \>\>\> implement type inference for Ruby 馃檪 > > \>\> > > \>\> 'We' do? > > \> > > \> Yes, "we" do. As in the Ruby community. > > > > I think "we" would be better off not predicating membership in the > > Ruby community on interest in a particular project or direction of > > development. It's inaccurate, in this case, and rather an > > unattractive precedent. ---
**Author:** ![Eric\_Mahurin1](https://avatars.discourse-cdn.com/v4/letter/e/34f0e0/32.png) [@Eric\_Mahurin1](https://rubytalk.org/u/Eric_Mahurin1)\ **Post date:** [3 October 2005 16:38 UTC](https://rubytalk.org/t/type-inference/21282/6 "2005-10-03T16:38:48Z")
Maybe I misunderstood what Eivind was asking for. From the last message it sounded like he was asking for the interpreter/comilier/VM to try to infer what the class was for the object of some variable. The reason for doing this would be to transform something dynamically typed (all ruby variables) to something statically typed. I think this is the critical thing needed in dynamically typed languages to give performance that approaches statically typed languages. I don't know of any dynamically typed languages that have been able to do this yet, but I think it is the next threshold. Maybe the "self" language has, but I still haven't found any benchmarks for it. It sounds like you are talking about type checking not class inference. I don't see a whole lot of use for specifying something in the code to show the duck typing you are using for various arguments in a method. Maybe having rdoc scan the code to see what methods the arguments are using would be useful (somehow format this info in the generated docs). This would not be a trivial thing and I'm even sure how you would completely describe the duck-type (I know you hate that term) of an argument. > **路路路** > > --- "David A. Black" \ wrote: > > > Hi -- > > > > On Tue, 4 Oct 2005, Eric Mahurin wrote: > > > > \> To take advantage of type (really class) inference in an > > \> optimal way, you'd need to know that the methods aren't > > \> changing. > > > > What about type (really type) inference? 馃檪 There have been > > some > > interesting projects looking at the matter of checking types > > in Ruby > > (not based on class/module membership), including one by > > Eivind and I > > think one by Florian Gross. It's not easy... but anything > > less is, I > > think inevitably and almost by definition, going to reduce > > what one > > can do in Ruby. > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > **[Yahoo Mail - Organized Email](https://mail.yahoo.com/)** > > > > It's time to get stuff done with Yahoo Mail. Just add your Gmail, Outlook, AOL or Yahoo Mail to get going. We automatically organize all the things life throws at you, like receipts and attachments, so you can find what you need fast. Plus, we've got... ---
**Author:** ![rue](https://avatars.discourse-cdn.com/v4/letter/r/b77776/32.png) [@rue](https://rubytalk.org/u/rue)\ **Post date:** [3 October 2005 22:11 UTC](https://rubytalk.org/t/type-inference/21282/7 "2005-10-03T22:11:47Z")
Eivind Eklund wrote: > \> Hi -- > \> > \> > \> \>\>\> If you don't, please stop scaring people - we want them to go > \> \>\>\> implement type inference for Ruby 馃檪 > \> \>\> > \> \>\> 'We' do? > \> \> > \> \> Yes, "we" do. As in the Ruby community. > \> > \> I think "we" would be better off not predicating membership in the > \> Ruby community on interest in a particular project or direction of > \> development. It's inaccurate, in this case, and rather an > \> unattractive precedent. > > I meant it quite differently and much more positive: As an inclusive > "what I believe to be a majority opinion, at least given an informed > majority" (without excluding anybody.) Insulting those who disagree with you is a brilliant tactic; what better way of convincing them of the strength of your argument? > Eivind. E > **路路路** > > > On 10/3/05, David A. Black \ wrote: > > \> On Tue, 4 Oct 2005, Eivind Eklund wrote: > > \> \> On 10/3/05, Tanner Burson \ wrote: > > \> \>\> On 10/3/05, Eivind Eklund \ wrote: ---
**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\ **Post date:** [4 October 2005 03:21 UTC](https://rubytalk.org/t/type-inference/21282/8 "2005-10-04T03:21:47Z")
In article \, > **路路路** > > Eivind Eklund \ wrote: > > > On 10/3/05, David A. Black \ wrote: > > > > > Hi -- > > > > > > On Tue, 4 Oct 2005, Eivind Eklund wrote: > > > > > > \> On 10/3/05, Tanner Burson \ wrote: > > > \>\> On 10/3/05, Eivind Eklund \ wrote: > > > \>\>\> If you don't, please stop scaring people - we want them to go > > > \>\>\> implement type inference for Ruby 馃檪 > > > \>\> > > > \>\> 'We' do? > > > \> > > > \> Yes, "we" do. As in the Ruby community. > > > > > > I think "we" would be better off not predicating membership in the > > > Ruby community on interest in a particular project or direction of > > > development. It's inaccurate, in this case, and rather an > > > unattractive precedent. > > > > I meant it quite differently and much more positive: As an inclusive > > "what I believe to be a majority opinion, at least given an informed > > majority" (without excluding anybody.) > > Did you take a poll? > > Does 'informed majority' mean the opinions of those who agree with you? 馃槈 > > Phil ---
**Author:** ![Gene\_Tani](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@Gene\_Tani](https://rubytalk.org/u/Gene_Tani)\ **Post date:** [4 October 2005 02:41 UTC](https://rubytalk.org/t/type-inference/21282/9 "2005-10-04T02:41:47Z")
I jus tfound this, which may be relevant or no > **[optimizing\_python.pdf](https://kascade.org/optimizing_python.pdf)** > > 1543 B Eric Mahurin wrote: > **路路路** > > > --- "David A. Black" \ wrote: > > > > \> Hi -- > > \> > > \> On Tue, 4 Oct 2005, Eric Mahurin wrote: > > \> ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [4 October 2005 11:57 UTC](https://rubytalk.org/t/type-inference/21282/10 "2005-10-04T11:57:51Z")
> \> \> To take advantage of type (really class) inference in an > \> \> optimal way, you'd need to know that the methods aren't > \> \> changing. > \> > \> What about type (really type) inference? 馃檪 There have been > \> some interesting projects looking at the matter of checking types > \> in Ruby (not based on class/module membership), including one by > \> Eivind and I think one by Florian Gross. It's not easy... but anything > \> less is, I think inevitably and almost by definition, going to reduce > \> what one can do in Ruby. > > Maybe I misunderstood what Eivind was asking for. From the > last message it sounded like he was asking for the > interpreter/comilier/VM to try to infer what the class was for > the object of some variable. Not class. What is possible is to infer the binding of certain messages (method calls). The "Class" concept in Ruby sort of isn't classes, more a way to launch an object with a predefined set of method bindings. > The reason for doing this would be to transform something dynamically typed (all ruby > variables) to something statically typed. I think this is the > critical thing needed in dynamically typed languages to give > performance that approaches statically typed languages. Not really. It's possible to do this at run-time, and that's easier than doing it at "compile time". The combination result in the fastest code, of course. > I don't know of any dynamically typed languages that have been > able to do this yet, but I think it is the next threshold. > Maybe the "self" language has, but I still haven't found any > benchmarks for it. This reference: [http://research.sun.com/self/papers/chambers-thesis/t1.ps.Z](http://research.sun.com/self/papers/chambers-thesis/t1.ps.Z) indicate 1/3 to 1/2 the speed of optimized C (for standard cross-language benchmarks.) That meshes with the claims here: [http://research.sun.com/self/compiler.html](http://research.sun.com/self/compiler.html) I have not seen any specific benchmark numbers. > It sounds like you are talking about type checking not class > inference. These are (or can be, at least) aspects of the same thing. Inference of the binding for messages (methods) let us do static inference of the real types (not classes) involved, and can give early warnings, like "That method call is going to result in an uncaught NoMethodError" or "That code branch will never ever be called". > I don't see a whole lot of use for specifying > something in the code to show the duck typing you are using for > various arguments in a method. Maybe having rdoc scan the code > to see what methods the arguments are using would be useful > (somehow format this info in the generated docs). This would > not be a trivial thing and I'm even sure how you would > completely describe the duck-type (I know you hate that term) > of an argument. You cannot completely describe the duck-type of an argument in the general case. I've experimented with an implementation for fairly free form description, and I've written an approx 10 page paper with a taxonomy of various ways of changing "things around types" in Ruby. That's unfortunately been lying dormant for a year or so - it just lack final editing to be possible to release as an overview paper. My experimentation indicated that the use of type declarations inside normal Ruby code was just in the way during programming, at least the ways I tried out (programming alone over a fairly short time period.) The analysis I ended up with in the paper shows some cases where declaration may be useful anyway, especially at the edge of modules, used as communication tool between programmers. There's also a suggestion for a new way to use this; one of the reasons it's delayed is that I'd like to do a test implementation of that, too, and have been too bogged down in Perl at work to do more work on this. Eivind. > **路路路** > > On 10/3/05, Eric Mahurin \ wrote: > > > --- "David A. Black" \ wrote: > > \> On Tue, 4 Oct 2005, Eric Mahurin wrote: ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [4 October 2005 12:19 UTC](https://rubytalk.org/t/type-inference/21282/11 "2005-10-04T12:19:02Z")
> In article \, > \>\> > \>\> \>\>\> If you don't, please stop scaring people - we want them to go > \>\> \>\>\> implement type inference for Ruby 馃檪 > \>\> \>\> > \>\> \>\> 'We' do? > \>\> \> > \>\> \> Yes, "we" do. As in the Ruby community. > \>\> > \>\> I think "we" would be better off not predicating membership in the > \>\> Ruby community on interest in a particular project or direction of > \>\> development. It's inaccurate, in this case, and rather an > \>\> unattractive precedent. > \> > \>I meant it quite differently and much more positive: As an inclusive > \>"what I believe to be a majority opinion, at least given an informed > \>majority" (without excluding anybody.) > > Did you take a poll? I took a number of discussions. > Does 'informed majority' mean the opinions of those who agree with you? 馃槈 I'll pretend this wasn't rethorical and answer: Usually, yes. I try very very hard to not have an opinion until I've become informed. I usually end up going with the majority opinion among those that are informed. When I hold another opinion, I try to avoid speaking for the majority, and instead say things like "I believe we should". In this particular case, I thought intially that the opinion was fairly non-controversial. I've discussed the topic with a number of people - people that have actually taken the time to check the references - and as far as I remember, they've all come to the conclusion "I didn't think that was possible - cool - that would be a boon". I'm not offended by your comments - it seems like I communicate badly these days, so I should forgive everybody else for it, too - but I'll still give a small warning: Most of the dire problems I've seen in open source projects (up to and including people leaving in anger, becoming seriously depressed, and hating each other for years) have started from the use of sarcasm/irony in mailing lists and on IRC. I recommend staying away from rethorical questions, sarcasm, irony, and similar devices - they can totally explode in your face. In peace, Eivind. > **路路路** > > On 10/4/05, Phil Tomson \ wrote: > > > Eivind Eklund \ wrote: > > \>On 10/3/05, David A. Black \ wrote: > > \>\> On Tue, 4 Oct 2005, Eivind Eklund wrote: > > \>\> \> On 10/3/05, Tanner Burson \ wrote: > > \>\> \>\> On 10/3/05, Eivind Eklund \ wrote: ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [4 October 2005 12:33 UTC](https://rubytalk.org/t/type-inference/21282/12 "2005-10-04T12:33:53Z")
\*sigh\* Please interpret what I write as positively intended unless it is very obviously differently intended. If I mean to call people that disagree clueless or lacking knowledge, I write "Those that disagree in this are clueless." or "I believe those that disagree with this just lack information" or similar. If I mean that I believe this to be a majority opinion among those that are informed on the topic, I write that I believe this to be a majority opinion among those that are informed on the topic and that it would be a majority opinion if everybody was informed, or a shorthand like ' "what I believe to be a majority opinion, at least given an informed majority" (without excluding anybody.)' And if I write a "we want ..." without a context, that will usually mean something "We, this community including you, does in my opinion using the knowledge that I have and feel certain enough about to have an opinion and with priorities I believe you would agree with, want ..." I hope I've made myself clear now and we can get back to the topic. Eivind. > **路路路** > > On 10/4/05, rue \ wrote: > > > Eivind Eklund wrote: > > \> I meant it quite differently and much more positive: As an inclusive > > \> "what I believe to be a majority opinion, at least given an informed > > \> majority" (without excluding anybody.) > > > > Insulting those who disagree with you is a brilliant tactic; > > what better way of convincing them of the strength of your > > argument? ---
**Author:** ![Eric\_Mahurin1](https://avatars.discourse-cdn.com/v4/letter/e/34f0e0/32.png) [@Eric\_Mahurin1](https://rubytalk.org/u/Eric_Mahurin1)\ **Post date:** [4 October 2005 13:35 UTC](https://rubytalk.org/t/type-inference/21282/13 "2005-10-04T13:35:02Z")
> \> \> \> To take advantage of type (really class) inference in > an > \> \> \> optimal way, you'd need to know that the methods aren't > \> \> \> changing. > \> \> > \> \> What about type (really type) inference? 馃檪 There have > been > \> \> some interesting projects looking at the matter of > checking types > \> \> in Ruby (not based on class/module membership), including > one by > \> \> Eivind and I think one by Florian Gross. It's not > easy... but anything > \> \> less is, I think inevitably and almost by definition, > going to reduce > \> \> what one can do in Ruby. > \> > \> Maybe I misunderstood what Eivind was asking for. From the > \> last message it sounded like he was asking for the > \> interpreter/comilier/VM to try to infer what the class was > for > \> the object of some variable. > > Not class. What is possible is to infer the binding of > certain > messages (method calls). The "Class" concept in Ruby sort of > isn't > classes, more a way to launch an object with a predefined set > of > method bindings. "class" is still closer to what you are talking about than the ruby definition of "type" I've seen running around. The one I've seen is basically analogous to interfaces in Java, but includes all methods. For example IO and StringIO could be considered the same "type". I don't think that kind of "type" inference does any good for improving performance (the methods for IO and StringIO are completely independent). For ruby, I'd still say class is close enough. And if an object changes it's meta class (initially the normal class), that meta/singleton class should be treated as it's class for "class" inference purposes. > \> The reason for doing this would be to transform something > dynamically typed (all ruby > \> variables) to something statically typed. I think this is > the > \> critical thing needed in dynamically typed languages to > give > \> performance that approaches statically typed languages. > > Not really. It's possible to do this at run-time, and that's > easier > than doing it at "compile time". The combination result in > the > fastest code, of course. I didn't say it needed to be done at compile-time. This transformation can be done at compile-time or run-time. I think that having to allow for methods of objects to change (either by changing class methods or meta class methods) after this transformation is done becomes problematic. The ideal situation for this type of optimization would be all methods are immutable once an object comes to life. You could still make a clone of an object with a changed method, but not directly change the method of an existing object. > \> I don't know of any dynamically typed languages that have > been > \> able to do this yet, but I think it is the next threshold. > \> Maybe the "self" language has, but I still haven't found > any > \> benchmarks for it. > > This reference: > [http://research.sun.com/self/papers/chambers-thesis/t1.ps.Z](http://research.sun.com/self/papers/chambers-thesis/t1.ps.Z) > indicate 1/3 to 1/2 the speed of optimized C (for standard > cross-language benchmarks.) > > That meshes with the claims here: > [http://research.sun.com/self/compiler.html](http://research.sun.com/self/compiler.html) > > I have not seen any specific benchmark numbers. This chapter has benchmarks: [http://research.sun.com/self/papers/chambers-thesis/t14.ps.Z](http://research.sun.com/self/papers/chambers-thesis/t14.ps.Z) Performance ranges from 22% to 65% of optimized C. Compare that to ruby - from about 0.25% to 10% of C (language shootout). Seems like somebody should try implementing ruby in the self virtual machine. I read somewhere that smalltalk was implemented on this VM, so why not ruby? ruby got many of its features from smalltalk, right? > \> It sounds like you are talking about type checking not > class > \> inference. > > These are (or can be, at least) aspects of the same thing. > Inference > of the binding for messages (methods) let us do static > inference of > the real types (not classes) involved, and can give early > warnings, > like "That method call is going to result in an uncaught > NoMethodError" or "That code branch will never ever be > called". Again it depends on what your definition of "type" is. If your method checks to make sure that an argument responds to all that is needed (psuedo checking the "duck-type"), I don't think that helps the type (exact method bindings) inference problem. If it checks for a specific class, that would trivialize this inference. > \> I don't see a whole lot of use for specifying > \> something in the code to show the duck typing you are using > for > \> various arguments in a method. Maybe having rdoc scan the > code > \> to see what methods the arguments are using would be useful > \> (somehow format this info in the generated docs). This > would > \> not be a trivial thing and I'm even sure how you would > \> completely describe the duck-type (I know you hate that > term) > \> of an argument. > > You cannot completely describe the duck-type of an argument > in the general case. I could see that since it is so recursive. But, you may if you limit the depth. > **路路路** > > --- Eivind Eklund \ wrote: > > > On 10/3/05, Eric Mahurin \ wrote: > > \> --- "David A. Black" \ wrote: > > \> \> On Tue, 4 Oct 2005, Eric Mahurin wrote: > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > **[Yahoo Mail - Organized Email](https://mail.yahoo.com/)** > > > > It's time to get stuff done with Yahoo Mail. Just add your Gmail, Outlook, AOL or Yahoo Mail to get going. We automatically organize all the things life throws at you, like receipts and attachments, so you can find what you need fast. Plus, we've got... ---
**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\ **Post date:** [4 October 2005 17:11 UTC](https://rubytalk.org/t/type-inference/21282/14 "2005-10-04T17:11:50Z")
In article \, > > In article \, > > > \>\> > > \>\> \>\>\> If you don't, please stop scaring people - we want them to go > > \>\> \>\>\> implement type inference for Ruby 馃檪 > > \>\> \>\> > > \>\> \>\> 'We' do? > > \>\> \> > > \>\> \> Yes, "we" do. As in the Ruby community. > > \>\> > > \>\> I think "we" would be better off not predicating membership in the > > \>\> Ruby community on interest in a particular project or direction of > > \>\> development. It's inaccurate, in this case, and rather an > > \>\> unattractive precedent. > > \> > > \>I meant it quite differently and much more positive: As an inclusive > > \>"what I believe to be a majority opinion, at least given an informed > > \>majority" (without excluding anybody.) > > > > Did you take a poll? > > I took a number of discussions. > > > Does 'informed majority' mean the opinions of those who agree with you? ;= > > -) > > I'll pretend this wasn't rethorical and answer: Usually, yes. I try > very very hard to not have an opinion until I've become informed. I > usually end up going with the majority opinion among those that are > informed. When I hold another opinion, I try to avoid speaking for > the majority, and instead say things like "I believe we should". > > In this particular case, I thought intially that the opinion was > fairly non-controversial. I've discussed the topic with a number of > people - people that have actually taken the time to check the > references - and as far as I remember, they've all come to the > conclusion "I didn't think that was possible - cool - that would be a > boon". > > I'm not offended by your comments - it seems like I communicate badly > these days, so I should forgive everybody else for it, too - but I'll > still give a small warning: Most of the dire problems I've seen in > open source projects (up to and including people leaving in anger, > becoming seriously depressed, and hating each other for years) have > started from the use of sarcasm/irony in mailing lists and on IRC. I > recommend staying away from rethorical questions, sarcasm, irony, and > similar devices - they can totally explode in your face. > > In peace, > Eivind. Elvind, No offense was intended (please note the presence of the winking smiley in my comments above). I just thought that your comments (the ones I replied to earlier) sounded a little, uh, well, 'elitist' might be a bit strong, but it seems to fit. Maybe that's not what you intended, but that's how I read it. ...and I wasn't aware that there was wide agreement on the topic of type inference/type checking in Ruby (but hey, I don't hang out on IRC, so maybe something's happened there). Seems like a very contentious issue, actually. The reality is that whenever someone brings up a subject like this it raises the specter of 'static typing'. That sort of thing worries a lot of people here who really like 'duck typing'. You're talking about 'type inference' which isn't 'static typing' (not yet, anyway 馃槈 \<- (Note the only slightly ironic smiley) so maybe some of us are overreacting, but then again we've seen a lot of these discussions before and we've seen how they've gone. If you can do type inference with some sort add-on module(s), then more power to you. We eagerly await the code. I even think it would be useful in some cases, but I don't want to see the elegance of the philosophy of the core language negatively impacted by it, that's why I emphasize that it sould be some sort of add-on module. definitely no non-peaceful intents here. Phil > **路路路** > > Eivind Eklund \ wrote: > > > On 10/4/05, Phil Tomson \ wrote: > > > > > Eivind Eklund \ wrote: > > > \>On 10/3/05, David A. Black \ wrote: > > > \>\> On Tue, 4 Oct 2005, Eivind Eklund wrote: > > > \>\> \> On 10/3/05, Tanner Burson \ wrote: > > > \>\> \>\> On 10/3/05, Eivind Eklund \ wrote: ---
**Author:** ![Anonymous\_Coward](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Anonymous\_Coward](https://rubytalk.org/u/Anonymous_Coward)\ **Post date:** [4 October 2005 20:55 UTC](https://rubytalk.org/t/type-inference/21282/15 "2005-10-04T20:55:58Z")
> > Eivind Eklund wrote: > > \> I meant it quite differently and much more positive: As an inclusive > > \> "what I believe to be a majority opinion, at least given an informed > > \> majority" (without excluding anybody.) > > > > Insulting those who disagree with you is a brilliant tactic; > > what better way of convincing them of the strength of your > > argument? > > \*sigh\* > > Please interpret what I write as positively intended unless it is very > obviously differently intended. > > If I mean to call people that disagree clueless or lacking knowledge, > I write "Those that disagree in this are clueless." or "I believe > those that disagree with this just lack information" or similar. I would advise you to err on caution's side: your statement came out quite aloof and, frankly, offensive. Whether you meant it to is quite another thing. Typically, as I am sure you know, actually explaining the scenario (which you have since, but not before) done will work wonders. That being said... > If I mean that I believe this to be a majority opinion among those > that are informed on the topic, I write that I believe this to be a > majority opinion among those that are informed on the topic and that > it would be a majority opinion if everybody was informed, or a > shorthand like ' "what I believe to be a majority opinion, at least > given an informed majority" (without excluding anybody.)' > > And if I write a "we want ..." without a context, that will usually > mean something "We, this community including you, does in my opinion > using the knowledge that I have and feel certain enough about to have > an opinion and with priorities I believe you would agree with, want > ..." > > I hope I've made myself clear now and we can get back to the topic. Sure. This is certainly something I am interested in and, overall, a very good idea to attempt to implement for ruby; perhaps this work might be done in parallel with YARV. I think the topic and the earlier discussion might have been somewhat misleading. Your proposal deals with, in particular, the ruby interpreter (or compiler) itself rather than anything in 'client code', correct? Maybe point that out clearly just to pacify those among us who, like I, abhor any sort of explicit typing (in ruby). > Eivind. E > **路路路** > > > On 10/4/05, rue \ wrote: ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [4 October 2005 14:48 UTC](https://rubytalk.org/t/type-inference/21282/16 "2005-10-04T14:48:48Z")
> \> \> Maybe I misunderstood what Eivind was asking for. From the > \> \> last message it sounded like he was asking for the > \> \> interpreter/comilier/VM to try to infer what the class was > \> for > \> \> the object of some variable. > \> > \> Not class. What is possible is to infer the binding of > \> certain > \> messages (method calls). The "Class" concept in Ruby sort of > \> isn't > \> classes, more a way to launch an object with a predefined set > \> of > \> method bindings. > > "class" is still closer to what you are talking about than the > ruby definition of "type" I've seen running around. The one > I've seen is basically analogous to interfaces in Java, but > includes all methods. For example IO and StringIO could be > considered the same "type". I don't think that kind of "type" > inference does any good for improving performance (the methods > for IO and StringIO are completely independent). That's what's usually called an abstract type. What we are (or at least I am) discussing is inferring what's usually called concrete types. > For ruby, I'd still say class is close enough. And if an > object changes it's meta class (initially the normal class), > that meta/singleton class should be treated as it's class for > "class" inference purposes. I still think we should call it (concrete) type inference, because everybody else does, and having two subtly different definitions for "class" seems likely to trip up communication. And this area is hard enough as it is. > \> \> The reason for doing this would be to transform something > \> dynamically typed (all ruby > \> \> variables) to something statically typed. I think this is > \> the > \> \> critical thing needed in dynamically typed languages to > \> give > \> \> performance that approaches statically typed languages. > \> > \> Not really. It's possible to do this at run-time, and that's > \> easier > \> than doing it at "compile time". The combination result in > \> the > \> fastest code, of course. > > I didn't say it needed to be done at compile-time. This > transformation can be done at compile-time or run-time. There's somewhat more that can be done at run time than at compile time. The run time techniques are usually considered as outside the scope of type inference, though they're also relevant for a general discussion of optimization techniques. I would prefer to stick with discussing type inference techniques first, as they can be used for more than pure optimization. > I think that having to allow for methods of objects to change > (either by changing class methods or meta class methods) after > this transformation is done becomes problematic. This problem has already been handled by the Self implementation, unless I've significantly misunderstood. > This chapter has benchmarks: > > [http://research.sun.com/self/papers/chambers-thesis/t14.ps.Z](http://research.sun.com/self/papers/chambers-thesis/t14.ps.Z) > > Performance ranges from 22% to 65% of optimized C. Compare > that to ruby - from about 0.25% to 10% of C (language > shootout). Seems like somebody should try implementing ruby in > the self virtual machine. I read somewhere that smalltalk was > implemented on this VM, so why not ruby? ruby got many of its > features from smalltalk, right? Yes. I think pure Ruby should be possible to translate to the Self interpreter in a fairly direct fashion, more or less with just a parser throwing things to the backend. The challenge is that the Ruby standard library is written in C, and we do not have a complete implementation in Ruby available (or didn't the last time I checked, anyway.) There's metaruby, which has some of it, and RIR (Ruby-in-Ruby), that may have some other parts. I don't think there's anything complete? > \> \> It sounds like you are talking about type checking not > \> class > \> \> inference. > \> > \> These are (or can be, at least) aspects of the same thing. > \> Inference > \> of the binding for messages (methods) let us do static > \> inference of > \> the real types (not classes) involved, and can give early > \> warnings, > \> like "That method call is going to result in an uncaught > \> NoMethodError" or "That code branch will never ever be > \> called". > > Again it depends on what your definition of "type" is. By "real type" I mean "concrete type" which again means "what exact code will be run by method calls and what memory layout the type has". I think this is fairly universally accepted terminology among those doing research on types (though maybe I've just picked up terminology used by a subcommunity - I've restricted myself to reading research that seemed interesting.) > If your > method checks to make sure that an argument responds to all > that is needed (psuedo checking the "duck-type"), I don't think > that helps the type (exact method bindings) inference problem. It might actually help somewhat, as the call flow gets more limited. When we do that check, it is no longer possible for an error to happen further down in the call graph and create an exception. This may also avoid some cases of half-executed code, which again maybe could simplify the rest of the analysis (because half-changed objects don't happen.) > If it [your method -EE] checks for a specific class, that would trivialize this > inference. If it check for a specific concrete type, that trivialize the inference. However, classes in Ruby are \*not\* concrete types, and that's very important to remember. That's why I want to have other terminology. I'm not sure if you mean concrete type (and if so, how are we going to specify concrete types?) or Ruby classes above. The latter help little (as it is trivial to override kind\_of? and instance\_of?). > \> You cannot completely describe the duck-type of an argument > \> in the general case. > > I could see that since it is so recursive. But, you may if you > limit the depth. That's the way I think it's been done in the Self environment. The inference engine finds the types to a certain depth, add some assertions that check that those parts are true, and runs the code under those assumptions. If the assertions fail, the relevant part is recompiled or interpreteted. This is done partially at compile time (in the form of extraction of the relevant part of the environment to create a single "application binary" to ship to users), and partially through "type feedback" at runtime, which notice that something always is the same concrete types, and JIT-compiles code based on that. Eivind. > **路路路** > > On 10/4/05, Eric Mahurin \ wrote: > > > --- Eivind Eklund \ wrote: > > \> On 10/3/05, Eric Mahurin \ wrote: ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [4 October 2005 17:46 UTC](https://rubytalk.org/t/type-inference/21282/17 "2005-10-04T17:46:50Z")
Eric Mahurin wrote: -snip- > Compare that to ruby - from about 0.25% to 10% of C (language > shootout). Which language shootout? On these Ruby can be 100x slower than C (and is never shown faster than C). [http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) [http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) ---
**Author:** ![Eric\_Mahurin1](https://avatars.discourse-cdn.com/v4/letter/e/34f0e0/32.png) [@Eric\_Mahurin1](https://rubytalk.org/u/Eric_Mahurin1)\ **Post date:** [4 October 2005 18:04 UTC](https://rubytalk.org/t/type-inference/21282/18 "2005-10-04T18:04:19Z")
> Eric Mahurin wrote: > -snip- > \> Compare that to ruby - from about 0.25% to 10% of C > (language > \> shootout). > > Which language shootout? > > On these Ruby can be 100x slower than C (and is never shown > faster than > C). [http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) > [http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) That's the one I'm talking about. I said the speed of ruby was 0.25% to 10% of C. That means 10X to 400X slower. Compare that to "self" which is no more than about 5X slower. I wouldn't mind seeing "self" in your benchmarks too using the self virtual machine. This would be the only dynamically typed language that is even in the same magnitude of performance as C. > **路路路** > > --- Isaac Gouy \ wrote: > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > **[Yahoo Mail - Organized Email](https://mail.yahoo.com/)** > > > > It's time to get stuff done with Yahoo Mail. Just add your Gmail, Outlook, AOL or Yahoo Mail to get going. We automatically organize all the things life throws at you, like receipts and attachments, so you can find what you need fast. Plus, we've got... ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [4 October 2005 19:51 UTC](https://rubytalk.org/t/type-inference/21282/19 "2005-10-04T19:51:47Z")
Eric Mahurin wrote: > \> Eric Mahurin wrote: > \> -snip- > \> \> Compare that to ruby - from about 0.25% to 10% of C > \> (language > \> \> shootout). > \> > \> Which language shootout? > \> > \> On these Ruby can be 100x slower than C (and is never shown > \> faster than > \> C). > \> > \> > [http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) > \> > \> > [http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu](http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&lang2=icc&sort=fullcpu) > > That's the one I'm talking about. I said the speed of ruby was > 0.25% to 10% of C. That means 10X to 400X slower. Compare > that to "self" which is no more than about 5X slower. Say X times faster or slower and even I will understand what you mean 馃槈 > I wouldn't mind seeing "self" in your benchmarks too using the > self virtual machine. This would be the only dynamically typed > language that is even in the same magnitude of performance as > C. Some would be in the same magnitude of performance if we reduced the C run time 馃檪 Ruby is less than 10x slower than C on tcp-request. Lua is less than 10x slower on 2 or 3. Python is less than 10x slower on 2 or 3. etc And Ruby is missing programs where it could be expected to perform well. > **路路路** > > > --- Isaac Gouy \ wrote: > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > [http://mail.yahoo.com](http://mail.yahoo.com)