4 ms·

I apologize in advance but I couldn't not bring this up: it's too hilarious. About a year ago there was a bug in the elm compiler that occasionally caused the

by rnhmjoj 11y ago

I apologize in advance but I couldn't not bring this up: it's too hilarious. About a year ago there was a bug in the elm compiler that occasionally caused the types in a type mismatch error message to be swapped. For example the compiler told you: Something weird is happening with this value: x Expected Type: number Actual Type: String but it actualy meant the opposite: Expected Type: String Actual Type: number Evan said it wasn't so easy to fix. You can see the issue here: https://github.com/elm-lang/elm-compiler/issues/216 https://github.com/elm-lang/elm-compiler/issues/216 At the time I was trying to learn elm (and functional programming) and I didn't know it was a bug so it gave me a lot of troubles: I could never fully trust the compiler. Then I left elm and focused on haskell but now I think I see how he solved the bug: As I infer the type of values flowing through your program, I see a conflict between these two types: String number Anyway these new messages are very helpful, especially when compared to haskell error like: Could not deduce (b ~ c) from the context (Num b, Num c) bound by the type signature for f :: (Num b, Num c) => [a] -> (b, c) at restriction.hs:(4,1)-(5,32) `b' is a rigid type variable bound by the type signature for f :: (Num b, Num c) => [a] -> (b, c) Great job.

reagency 11y ago
Not entirely fair. The Haskell is example is more complicated code (using type classes and type variables), and the error message provides more detail. But Haskell would benefit from better wording and not relying on symbols like ~
Nitramp 11y ago
That's a common problem with globally inferencing compilers, you strictly cannot know who's right about a type. I think that's a good reason to prefer a language with local type inference, but no type inference across function boundaries. It saves you from too much boiler plate to type and has (IMHO) better developer ergonomics.
- renox 11y ago
  In Jay (a language not finished) there is a prefix for the parameter who is the 'master' type (if memory serves '$'), this has the following benefits: -in fun f(a:$T, b:T) and f(1, 'hello') you can say Error parameter 'b' is a string but generic type T is int as defined by parameter 'a'. -no need to have a separate definition of generic types as in fn f<T>(a:T): fn f(a:$T) tells you already which type is generic.

by rnhmjoj 11y ago

reagency 11y ago

Not entirely fair. The Haskell is example is more complicated code (using type classes and type variables), and the error message provides more detail. But Haskell would benefit from better wording and not relying on symbols like ~

Nitramp 11y ago

That's a common problem with globally inferencing compilers, you strictly cannot know who's right about a type. I think that's a good reason to prefer a language with local type inference, but no type inference across function boundaries. It saves you from too much boiler plate to type and has (IMHO) better developer ergonomics.

renox 11y ago
In Jay (a language not finished) there is a prefix for the parameter who is the 'master' type (if memory serves '$'), this has the following benefits: -in fun f(a:$T, b:T) and f(1, 'hello') you can say Error parameter 'b' is a string but generic type T is int as defined by parameter 'a'. -no need to have a separate definition of generic types as in fn f<T>(a:T): fn f(a:$T) tells you already which type is generic.