4 ms·

Swift is not unique in using constraint solving to provide bidirectional type inference. Scala and Haskell provide the same level of flexibility; although not w

Swift is not unique in using constraint solving to provide bidirectional type inference. Scala and Haskell provide the same level of flexibility; although not with the same compile-time problems. In the case of Haskell, this is ultimately because the language is intentionally simpler in some ways. Swift brings together three features that can be hard on type inference: * Overloaded literals. When overloaded literals like maps can themselves contain literals, there are actually quite a few possible overloadings to choose from. * Subtyping. We infer not types but type bounds (ranges). * Overloading. Haskell has notably no overloading at all and no subtyping. Somehow Scala manages to combine all these things and a quite astonishing conversions system, too.

JoshTriplett 10y ago
Haskell does have overloaded literals: integer literals have type `Num a => a`, and floating-point literals have type `Fractional a => a`. And GHC has an extension OverloadedStrings to make string literals have type `IsString a => a` (which makes it easier to work with ByteString and other different string-like types).
- cousin_it 10y ago
  AFAIK, Haskell doesn't really have overloading in the sense that other languages use it. "Num a => a" is just one type. Contrast with Java, where a class can have two methods named "foo" with completely different arguments and return types.
  - minitech 10y ago
    “Overloaded literals” only has one meaning as far as I know, and what Haskell has is it: a literal whose type isn’t solely determined by its contents.
    - Sean1708 10y ago
      Essentially the parent commenters are talking about too different things, one is talking about the first bullet point and the other is talking about the third.
- ufo 10y ago
  However, it seems that the really tricky overloads in Swift's case are the lists, which can contain other overloaded literals inside them.
- capitalsigma 10y ago
  Haskell is also very happy to throw "ambiguous literal..." errors at you when it gets a little confused.
- solidsnack9000 10y ago
  Sorry, I was not being clear. Since I treated "overloaded literals" and "overloading" as separate bullet points I was using "overloading" to mean only overloaded declarations -- declaring the same function multiple times with different types.
smikhanov 10y ago
Interesting, didn't know that about Swift compiler. What does constraint solving provide that Hindley-Milner doesn't? My understanding of HM was that it's reducible to the system of linear equations, therefore solvable in linear time. What is that that Swift type checker requires that HM doesn't provide?
- Sharlin 10y ago
  HM has no concept of subtyping or overloading, I think. Scala has both of those and cannot do full type inference, only local inference.
- deleted 10y ago
  [deleted]
- solidsnack9000 10y ago
  It is worth considering that neither Haskell nor Scala are strictly Hindley-Milner.
- trurl 10y ago
  Type inference for HM is actually exponential, due to generalization for let-polymorphism. You're probably thinking of inference for a language with just simple types.
spullara 10y ago
Paul Philips showed me methods in Scala that took minutes to compile as it tried to solve for the return type. It has similar problems and is related to why the compiler is so slow.

JoshTriplett 10y ago

Haskell does have overloaded literals: integer literals have type `Num a => a`, and floating-point literals have type `Fractional a => a`. And GHC has an extension OverloadedStrings to make string literals have type `IsString a => a` (which makes it easier to work with ByteString and other different string-like types).

cousin_it 10y ago
AFAIK, Haskell doesn't really have overloading in the sense that other languages use it. "Num a => a" is just one type. Contrast with Java, where a class can have two methods named "foo" with completely different arguments and return types.
- minitech 10y ago
  “Overloaded literals” only has one meaning as far as I know, and what Haskell has is it: a literal whose type isn’t solely determined by its contents.
  - Sean1708 10y ago
    Essentially the parent commenters are talking about too different things, one is talking about the first bullet point and the other is talking about the third.
ufo 10y ago
However, it seems that the really tricky overloads in Swift's case are the lists, which can contain other overloaded literals inside them.
capitalsigma 10y ago
Haskell is also very happy to throw "ambiguous literal..." errors at you when it gets a little confused.
solidsnack9000 10y ago
Sorry, I was not being clear. Since I treated "overloaded literals" and "overloading" as separate bullet points I was using "overloading" to mean only overloaded declarations -- declaring the same function multiple times with different types.

smikhanov 10y ago

Interesting, didn't know that about Swift compiler. What does constraint solving provide that Hindley-Milner doesn't? My understanding of HM was that it's reducible to the system of linear equations, therefore solvable in linear time. What is that that Swift type checker requires that HM doesn't provide?

Sharlin 10y ago
HM has no concept of subtyping or overloading, I think. Scala has both of those and cannot do full type inference, only local inference.
deleted 10y ago
[deleted]
solidsnack9000 10y ago
It is worth considering that neither Haskell nor Scala are strictly Hindley-Milner.
trurl 10y ago
Type inference for HM is actually exponential, due to generalization for let-polymorphism. You're probably thinking of inference for a language with just simple types.

spullara 10y ago

Paul Philips showed me methods in Scala that took minutes to compile as it tried to solve for the return type. It has similar problems and is related to why the compiler is so slow.