3 ms·

But if they can add generics then they can solve that problem. They don't need explicit 'generics' like in Java 1.5 -- they need to go back to the source, and

by blasdel 17y ago

But if they can add generics then they can solve that problem. They don't need explicit 'generics' like in Java 1.5 -- they need to go back to the source, and adopt Haskell's type inference and parametric polymorphism. They already have basic type deduction, but it's only at the syntax level. They should really add GADTs to the type system, with pattern-matching over them, but that doesn't fit at all with Protocol Buffers, so it might never make it. Their 'case' statement is pattern matching already -- it doesn't do passthrough by default, it isn't a jump-table (not restricted to constants), and already has a special form for matching over types. They'd just have to cross the streams...

bad_user 17y ago
Adding a Hindley-Milner-like type-inference to a language that has subtype polymorphism and method overloading is really not a good idea (or possible for that matter). let plus x y = x + y let sum = plus 1 2 This is Ocaml, but let's assume it has type-classes. Method "plus" would be a generic method with a type like ... (Num 'a) -> (Num 'a) -> (Num 'a) The actual return type (int) is detected when the actual call is made. But that's assuming you know the actual types of the parameters at compile-time. And that's not the case in OOP languages ... by definition they have (at least) single-dispatch. That's why languages like Ocaml don't allow this. Full type-inference and languages like Java / C# don't mix.
- jbellis 17y ago
  Go doesn't have method overloading, and it doesn't have polymorphism in the traditional sense either. (Not sure what effect Go's Interface inference has on H-M.)
  - jganetsk 17y ago
    I think it's ok. I would think it's like type classes, which work pretty well for Haskell. And Go doesn't need full-fledged type inference. I bet they could work something out that's simpler and more explicit. Regardless, even explicit type variables would be very useful.

by blasdel 17y ago

bad_user 17y ago

Adding a Hindley-Milner-like type-inference to a language that has subtype polymorphism and method overloading is really not a good idea (or possible for that matter). let plus x y = x + y let sum = plus 1 2 This is Ocaml, but let's assume it has type-classes. Method "plus" would be a generic method with a type like ... (Num 'a) -> (Num 'a) -> (Num 'a) The actual return type (int) is detected when the actual call is made. But that's assuming you know the actual types of the parameters at compile-time. And that's not the case in OOP languages ... by definition they have (at least) single-dispatch. That's why languages like Ocaml don't allow this. Full type-inference and languages like Java / C# don't mix.

jbellis 17y ago
Go doesn't have method overloading, and it doesn't have polymorphism in the traditional sense either. (Not sure what effect Go's Interface inference has on H-M.)
- jganetsk 17y ago
  I think it's ok. I would think it's like type classes, which work pretty well for Haskell. And Go doesn't need full-fledged type inference. I bet they could work something out that's simpler and more explicit. Regardless, even explicit type variables would be very useful.