Talk:Type inference

message: Is it just me, does this article dive right into the deep end with technical jargon and mark-up? Perhaps at least some pointers to articles which might explain some of the notation as well as terminology would be in order...?
(P.S., isn't there a template to mark an article as too technical?) —The preceding unsigned comment was added by 71.70.210.188 (talk) 04:49, 11 December 2006 (UTC)
replies: text: 27-Oct-2007: The article was expanded with a non-technical explanation (on 22-Feb-2007), showing a simple coding example. In October 2007, I expanded the example to also show what won't work for type inference.  I think that is enough simplification, because the detailed technical issues are numerous and deserve more space in the article to encourage a full treatment of the subject. We must balance a novice view, against the right of technical readers to present and read full details.  I have removed tag "" and suggested writing a more detailed analysis if the article still seems troublesome. -Wikid77 18:49, 27 October 2007 (UTC)
thread_title:  too technical 

message: is it possible to say that c++ implements static type inferencing for functions ? ie give given a templated method definition template< class T> void func( T &v) then depending on the use context (caller type of argument) an appropriate version of func will be inststantiated; what is it that distinguishses this sort of behavoir from ml or ocaml type infererncing. note i am not arguing for c++ inclusion as representative example in the article but am interested to know the distinction.  —Preceding unsigned comment added by 213.56.155.247 (talk) 20:05, 5 July 2008 (UTC)
replies: text: No, that isn't type inference, just polymorphism/specialization. Type inference is where you don't specify the type, yet there is a "correct" type for that variable, and type inference works it out for you. (eg. it must be a string here — no other type will fit, type inference might infer that). Whereas templates in C++ is where you don't specify the type, indicating that all types are allowed there (there is no "correct" type). When the caller passes a specific typed argument and the appropriate version of the function is instantiated, that is called specialization. So the two are actually very different concepts. Type inference is just about figuring out types that the programmer was too lazy to write themselves :) —EatMyShortz (talk) 16:39, 19 August 2008 (UTC)
replies: text: I know that this was posted a really long time ago, but actually C++ templates have rather more to do with type inference than your comment here states. The whole argument-dependent lookup algorithm (or whatever it is called) really is a form of type inference. In fact, templates can and are used for exactly what you say -- "figuring out types that the programmer was too lazy to write themselves." For instance, the STL contains a make_pair function which takes two arguments of any type and returns a pair of those two values. However, this function is entirely redundant except in one respect, because the pair constructor itself performs the same task. The only reason it's provided is so that you don't have to explicitly specify the resulting type. EvanED (talk) 03:15, 6 April 2010 (UTC)
replies: text: That isn't type inference, which determines the types of expressions from the operations used to compose them. There is currently no type inference in C++. -- 98.108.202.144 (talk) 07:15, 14 September 2010 (UTC)
replies: text: I disagree. Type arguments are in fact inferred in C++ and Java, and at least for Java the specification talks about type inference - the definition of type inference you give describes in fact how type-checking determines 1+2 to have type Int. Yet, the allowed inference is severely limited, compared to what C++0x allows. System Fomega is a canonical example of lambda-calculus where type inference is impossible, and type arguments are allowed - and there not even the type arguments are inferred. --Blaisorblade (talk) 12:49, 6 May 2011 (UTC)
thread_title:  c++ generic functions 

message: In 1978 Robin Milner, independently of Hindley's work, provided an equivalent algorithm
I think this tells the truth, but not the whole truth.
From Milner "A Theory of Type Polymorphism in Programming" (1978):
After doing this work we became aware of Hindley's method for deriving the "principal type scheme" (which is what we call a polymorphic type) for a term in combinatory logic. Hindley appears to have been the first to notice that the Unification Algorithm of Robinson is appropriate to this problem. Our work can be regarded as an extension of Hindley’s method to programming languages with local declarations, and as a semantic justification of the method.
Looks like it was independent, but immediately acknowledged and Milner prefers to see his work as a "semantic justification" of Hindley's method. —EatMyShortz (talk) 16:44, 19 August 2008 (UTC)
thread_title:  Milner independent of Hindley? 

message: The opening paragraph contains a sentence starting with "Some languages that include type inference are [...]", followed by a list of languages with type inference. Please note the word "some" –  this is not supposed to be an exhaustive list, and I think only the most important languages ("important" in relation to type inference) ought to actually be listed there. Someone keeps adding Vala to the list; I would like to know why Vala is important enough to be on this list? – Adrian Willenbücher (talk) 10:19, 31 August 2010 (UTC)
thread_title:  List of languages with type inference 

message: The body of the section on Algorithm W (Hindley–Milner type inference algorithm) purporting to outline it, presents only an unrelated type checking (not type inference!) algorithm. This would be acceptable, if the section would be continued to present the real one. But since the section is unfinished, it harms more but it helps. Algorithm W uses unification in a very different manner. Right now, the section misleads completely.
If no expert is available to summarize Algorithm W, the quality of the article could be improved by removing everything from
this section but the introduction. The section itself should be kept, since Hindley-Milner is the type inference method for
languages dealing with functions and expressions.
In a way, removing the body of the section would help much to re-balance the article. IMO, it would be better to devote a separate article to Algorithm W and only mention it here.
:I'm probably sufficiently "expert" to give a crack at a reasonable Algorithm W explanation...I'm therefore working on a fairly comprehensive revision that I expect to finish within a couple of days.  It's true that it's a bit long with a proper explanation of Algorithm W, but as the algorithm really is the type inference algorithm it's perhaps a bit redundant to separate the two.  Clegoues (talk) 04:42, 5 February 2011 (UTC)
thread_title:  Article Quality (Algorithm W) 

message: The new article on Hindley-Milner is now on-line.
This should close the above mentioned issue.
Please let me know about related concerns or suggestions.
-- Cobalt pen (talk) 17:04, 10 September 2011 (UTC)
thread_title:  ANNOUNCE: New Article on "Hindley-Milner" 

message: I believe this article is almost entirely wrong.
Type inference is a system whereby the types of variables, expressions and functions are computed from their use. A restricted form of this, where types of expressions are calculated from their subterms, it called type deduction.
Technically, deduction is a simple recursive descent, S-attributed or bottom up calculation which ALL compilers with static type systems can do. For example in C++98 
int x = 1;
the compiler can deduce the type x should have from the initialising expression, and check it is compatible with the declared type. In C++11 you can write:
auto x = 1;
Now you don't need to state the type of the variable, but the type calculation is the same. There is no type inference in either case. Here is type inference in Ocaml:
let f x = x + 1
The compiler infers x is of type int, because the function + has been applied to it. This is inference not deduction, because the type is calculated from the way the variable is used later. And here:
let  f x = g x in f 1
the argument to f is taken to be int because f is applied to an int later, and thus the argument of g must also be int. Again, this is type inference.
As a result of the wrong definition in this article a lot of languages are claiming to have inferencing type systems, including Rust and Go, which cannot do type inference. As a general guide any language with overloading is unlikely to also have any kind of inference, since the two features are very hard to mix. [Actually C# has overloading and a limited kind of inference, and there are research papers which demonstrate systems with both features and discuss the restrictions which arise as a result]
I think I must add the interesting note that in fact C++ can do type inference, not quite the kind you'd expect. C++ can infer the type of function template type parameters from function arguments. This calculation requires unification, and is not S-attributed, so technically it qualifies as type inference (despite the fact the Standard actually describes this as deduction :)
 
Skaller (talk) 15:25, 29 May 2013 (UTC)
thread_title:  Definition and examples are wrong 

message: In Type inference: 
 The opposite operation of type inference is called type erasure.
In Type erasure: 
 The opposite of type erasure is called reification.
And yet there is no mention of reification in Type inference, or mentioning of type inferencing in Reification (computer science). --Voidvector (talk) 05:05, 24 November 2014 (UTC)
thread_title:  Contradiction in text 

message: Visual Basic 6.0 supported defining variables with the type "Any". However, I'm not sure if this means that Visual Basic 6.0 supports type inference. Does anyone have any ideas?
Lcaa9 (talk) 10:43, 31 January 2016 (UTC)
thread_title:  Visual Basic type inference