3 ms·

If you don't call what C++ and Go do "type inference", would you call it "type deduction"?

by ngrilly 10y ago

catnaroek 10y ago
I don't think it deserves a special name. Would you use a special term for the fact you don't need to specify that the sum of two ints is an int?
- ngrilly 10y ago
  I disagree. Naming things is useful. "Type deduction" says clearly what happens, and is still distinct enough from "type inference" which is a different, more sophisticated concept. I've seen the term "type deduction" used many times in the context of C++ and Rust.
  - catnaroek 10y ago
    Rust has actual type inference. It just happens to be a local affair. For example, you can create a vector, even an empty one, without explicitly specific its element type. But, somewhere in the current function, you have to provide information about the element type, say, by inserting elements into the vector, or by using an element in a way that constrains its type.
  - catnaroek 10y ago
    The ability to name things is useful, but there are far more things out there than we can come up with good names for, so we have to decide wisely what things we name and what things we don't. Something like C++'s `auto` doesn't need a name of its own. It's just unidirectionally propagating type information from child to parent nodes in the AST. This is something even FORTRAN (when its name was all caps) and ALGOL implementations did during normal type checking.
ceor4 10y ago
It really doesn't matter what he calls it, as type inference has a well accepted definition that includes Go and C++. See: https://en.wikipedia.org/wiki/Type_inference https://en.wikipedia.org/wiki/Type_inference Perhaps the parent was trying to talk about "HM type inference" or something, but "type deduction" is also a fine name for a subset of type-inference, and perhaps more explicit for C++ and Go.
- catnaroek 10y ago
  Type inference (not just Hindley-Milner) is divided in two logical phases: (0) Generating a system of type equations, by recursively scanning the AST. (1) Solving the system of equations. The nontrivial nature of this step is what makes type inference, well, inference. In Go and C++'s case, the generated type equations come out already solved (that is, of the form `TypeVar = TypeExpr`), so there's nothing to infer!
  - ceor4 10y ago
    Perhaps you'd be best up taking it up on wikipedia and primary sources, instead of arguing with random internet people when using their same definitions.

If you don't call what C++ and Go do "type inference", would you call it "type deduction"?

by ngrilly 10y ago

If you don't call what C++ and Go do "type inference", would you call it "type deduction"?

I don't think it deserves a special name. Would you use a special term for the fact you don't need to specify that the sum of two ints is an int?

ngrilly 10y ago
I disagree. Naming things is useful. "Type deduction" says clearly what happens, and is still distinct enough from "type inference" which is a different, more sophisticated concept. I've seen the term "type deduction" used many times in the context of C++ and Rust.
- catnaroek 10y ago
  Rust has actual type inference. It just happens to be a local affair. For example, you can create a vector, even an empty one, without explicitly specific its element type. But, somewhere in the current function, you have to provide information about the element type, say, by inserting elements into the vector, or by using an element in a way that constrains its type.
- catnaroek 10y ago
  The ability to name things is useful, but there are far more things out there than we can come up with good names for, so we have to decide wisely what things we name and what things we don't. Something like C++'s `auto` doesn't need a name of its own. It's just unidirectionally propagating type information from child to parent nodes in the AST. This is something even FORTRAN (when its name was all caps) and ALGOL implementations did during normal type checking.

ceor4 10y ago

It really doesn't matter what he calls it, as type inference has a well accepted definition that includes Go and C++. See: https://en.wikipedia.org/wiki/Type_inference https://en.wikipedia.org/wiki/Type_inference Perhaps the parent was trying to talk about "HM type inference" or something, but "type deduction" is also a fine name for a subset of type-inference, and perhaps more explicit for C++ and Go.

catnaroek 10y ago
Type inference (not just Hindley-Milner) is divided in two logical phases: (0) Generating a system of type equations, by recursively scanning the AST. (1) Solving the system of equations. The nontrivial nature of this step is what makes type inference, well, inference. In Go and C++'s case, the generated type equations come out already solved (that is, of the form `TypeVar = TypeExpr`), so there's nothing to infer!
- ceor4 10y ago
  Perhaps you'd be best up taking it up on wikipedia and primary sources, instead of arguing with random internet people when using their same definitions.