4 ms·

I still think that, for the most part, Go doesn't need contracts (yet). I think it's common, coming from the object oriented world, to expect polymorphism to be

I still think that, for the most part, Go doesn't need contracts (yet). I think it's common, coming from the object oriented world, to expect polymorphism to be intrinsically tied to method overloading. But it doesn't have to be. Of the 12 examples at the end of the draft, there is only one real contract used, `comparable`, which could be easily done without contracts (but with generics) by passing in an extra argument `lessThanOrEqual func(T, T) bool`. The other kind of contract is harder to do without contracts, as it is the contract which combines all numeric types. However, most of the examples would be possible to write, albeit a little more messily, with a parameter `toDouble f(T) double`. Alternatively, we could go the route of baking in a few special contracts into the language, such as a numeric contract, just like how map and slice are baked in polymorphic structures. What do we gain from writing code this way? It leaves the Go language with more freedom from the future. Everyone agrees Go needs polymorphism. So add polymorphism. But as we can't agree on contracts, we can just leave it out. We'll get 90% of the benefits upfront, and then we can wait and see what are the actual edge cases we run into with contracts, and decide where to go from there.

stcredzero 7y ago
I think it's common, coming from the object oriented world, to expect polymorphism to be intrinsically tied to method overloading. But it doesn't have to be. Please provide some examples. For example, I don't think polymorphism in direct variable references is all that good. It leaves the Go language with more freedom from the future. Everyone agrees Go needs polymorphism. So add polymorphism. This statement confuses me. Go has polymorphism.
- uryga 7y ago
  > Go has polymorphism polymorphism is often distinguished into ad-hoc polymorphism (interfaces) and parametric polymorphism (generics) – i'm guessing GP was referring to the latter?
  - lalaithion 7y ago
    You're right, in my head I was writing parametric polymorphism, and it just didn't make it's way to my fingers somehow.
- lalaithion 7y ago
  If you go and look at the Map/Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts. All that is required for those sections to work is to declare a type parameter, and then allow that parameter to be filled by any type, but still typecheck that all of the variables with the same parameter are the same type at the calling site. There's no need to have a contract for which methods can be called on the type, because we don't need to call any methods or access any fields. In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures. If you need a little bit of behavior for those types, such as for a TreeMap data structure or a Sort function, Go's higher order functions make this possible without contracts, by passing in functions. The draft's Containers section uses this approach to construct a TreeMap. The SliceFn function, described in the Sort section, also uses this approach: func SliceFn(type Elem)(s []Elem, f func(Elem, Elem) bool) { Sort(sliceFn(Elem){s, f}) } Although this does use method overloading via contracts in implementation (via Sort), it doesn't need it. I expect that Go's existing interfaces (which yes, are a form of polymorphism, mea culpa) + unbounded parametric polymorphism are enough to solve 90% of Go's current issues. The more complex cases are still possible to handle with parametrically polymorphic structs containing functions. Yes, that's bad code, but we'd be able to look for this use case, judge how often it occurs, and use it's use cases as data to inform further discussions on contracts. The only case I struggle to easily deal with is the numeric case. My solution doesn't allow generic numeric functions, although I think there's room to explore that in more detail.
  - stcredzero 7y ago
    If you go and look at the Map/Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts. I see. I'm of the opinion that the Go team might be more cautious and introduce a more limited form of generics first, which seems in line with what you're saying. In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures. How would one make something like ConcurrentMap? Perhaps some operations on a map could be exposed and "overridden?"
    - 7y ago
xyzzy_plugh 7y ago
> Everyone agrees Go needs polymorphism. Huh? This couldn't be further from the truth.
- lalaithion 7y ago
  You're right, I overstated that. It might be more appropriate to say "The core development team has made it clear that they intend to add parametric polymorphism in some form".

stcredzero 7y ago

I think it's common, coming from the object oriented world, to expect polymorphism to be intrinsically tied to method overloading. But it doesn't have to be. Please provide some examples. For example, I don't think polymorphism in direct variable references is all that good. It leaves the Go language with more freedom from the future. Everyone agrees Go needs polymorphism. So add polymorphism. This statement confuses me. Go has polymorphism.

uryga 7y ago
> Go has polymorphism polymorphism is often distinguished into ad-hoc polymorphism (interfaces) and parametric polymorphism (generics) – i'm guessing GP was referring to the latter?
- lalaithion 7y ago
  You're right, in my head I was writing parametric polymorphism, and it just didn't make it's way to my fingers somehow.
lalaithion 7y ago
If you go and look at the Map/Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts. All that is required for those sections to work is to declare a type parameter, and then allow that parameter to be filled by any type, but still typecheck that all of the variables with the same parameter are the same type at the calling site. There's no need to have a contract for which methods can be called on the type, because we don't need to call any methods or access any fields. In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures. If you need a little bit of behavior for those types, such as for a TreeMap data structure or a Sort function, Go's higher order functions make this possible without contracts, by passing in functions. The draft's Containers section uses this approach to construct a TreeMap. The SliceFn function, described in the Sort section, also uses this approach: func SliceFn(type Elem)(s []Elem, f func(Elem, Elem) bool) { Sort(sliceFn(Elem){s, f}) } Although this does use method overloading via contracts in implementation (via Sort), it doesn't need it. I expect that Go's existing interfaces (which yes, are a form of polymorphism, mea culpa) + unbounded parametric polymorphism are enough to solve 90% of Go's current issues. The more complex cases are still possible to handle with parametrically polymorphic structs containing functions. Yes, that's bad code, but we'd be able to look for this use case, judge how often it occurs, and use it's use cases as data to inform further discussions on contracts. The only case I struggle to easily deal with is the numeric case. My solution doesn't allow generic numeric functions, although I think there's room to explore that in more detail.
- stcredzero 7y ago
  If you go and look at the Map/Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts. I see. I'm of the opinion that the Go team might be more cautious and introduce a more limited form of generics first, which seems in line with what you're saying. In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures. How would one make something like ConcurrentMap? Perhaps some operations on a map could be exposed and "overridden?"
  - 7y ago

xyzzy_plugh 7y ago

> Everyone agrees Go needs polymorphism. Huh? This couldn't be further from the truth.

lalaithion 7y ago
You're right, I overstated that. It might be more appropriate to say "The core development team has made it clear that they intend to add parametric polymorphism in some form".