Haskell error messages: come on

But their lies more problems for a beginner.

What are extensions?

How do I find out about them?

Which should be enabled?

Is my code broken because of me?

Or because I should enable an extension?

Anyway. It’s all not caring about beginners the whole way down when it comes to Haskell and it’s community

Compare this to the error message you get from Rust with the same program though:

  error[E0277]: cannot add `[{integer}; 2]` to `{integer}`
   --> src/main.rs:2:7
    |
  2 |     1 + [2, 3]
    |       ^ no implementation for `{integer} + [{integer}; 2]`
    |
    = help: the trait `Add<[{integer}; 2]>` is not implemented for `{integer}`
  
  For more information about this error, try `rustc --explain E0277`.

Good error messages are important for adoption of languages with strong type systems. The complexity is already foreign enough for people who aren't familiar with type theory.

That error's a bit better, but not much. You basically have to know that `+` only works on stuff that implements `Num` or else it still makes no sense. Compare that to the Rust/Python errors which are so much easier to understand.

Haskell performance ime is actually super easy.

I'd say I've run into performance issues professionally 5-10 times. None took more than a day to resolve.

A bit OT, but what about executable size? I installed shellcheck (using brew on macos) that is written in Haskell and the executable is over 70 MiB.

> needless category theory and algebra jargon

Examples? Sometimes there is a need for precising definitions.

As a Haskell beginner I have no idea what this error message means.

What is `it`? Perhaps it is the argument for ghciInteractivePrint? That is what the error says. But what is ghciInteractivePrint that wasn't in the original code? I'm guessing an alias for print.

The error seems to be

    No instance for (Num [Integer])

Which doesn't say anything about +

So I'm still in the dark about this error message!

I was going to say the same thing. While it may be true that beginners are not sufficiently appreciated or that error quality is not sufficiently prioritized, these extrapolations do seem a little rude in the context of what is effectively a defect report to a volunteer project.

Rust does not treat integer types as interchangeable.

Rust integers have a type (width and signedness) and you can't combine them without explicitly handling for overflow, etc. Any polymorphism through traits (eg. std::ops::Add) typically only operates over the same type as the source integer.

If types are left unspecified, it's only because type inference knows what type you mean. Since integers are frequently used in structs and function params (places where Rust requires typing), Rust knows the type when you perform operations on these variables. Outside of these cases, Rust will generally require you to disambiguate.

Rust is very deliberate about numerics.

Ehh, that's a bit overblown. In particular, even if you actually did make the weird list-number, you'd end up with a type error as soon as you tried to use it somewhere expecting a regular number.

Any sufficiently polymorphic strongly typed language is indistinguishable from Javascript

for an opposite take https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...

That’s not what “strongly typed” means, though.

"Haskell is a dynamically-typed, interpreted language" https://aphyr.com/posts/342-typing-the-technical-interview

In OCaml, 1.0 + 1.0 isn't even well-typed. You don't need to mix operand types to run into walls with OCaml. The lack of operator overloading may not hurt much in practice, but doesn't scream "elegant solution" to me.

Haskell doesn't overload its operators either (in the sense of there being multiple definitions with different type signatures); instead, it has a working type hierarchy that allows the same arithmetic operators to be used for all numeric types (through Num->Integral, Num->Real, Num->Rational and even Num->RealFloat->Complex). (1::Int) + 1.0 isn't well-typed in Haskell either, but at least (a + b) is a valid operation for all numeric data types. And, most importantly, as a developer you can define your own types that also implement these same operators.

OCaml does have polymorphic literals too: "%s" can be both type string and type formatter. It's just very limited and requires built-in compiler support, so it's not something you as developer can take advantage of in your own code. Although in practice I use OCaml more than Haskell, there's many times in OCaml where I wish it had more of Haskell's expressive type system.

The errors used to be somewhat better in the past, but more features have been added to the language, type system and std libs. Those features required the core parts to be slightly more expressive and generic, resulting in more abstract error messages.

Not great, but I think there are definitely no easy fixes here.

GHC is like a mathematican: unable to explain mathematical jargon without resorting to more mathematical jargon

The weak/strong classsification is a bit less well-defined than the dynamic/static classification, but in general, languages differ in how strongly they 'care' about their types.

For example, in Javascript, you can add anything to anything, with rules that define which automatic conversions will be performed. Sometimes, hilarity ensues. In contrast, a strong language would require explicit conversions and throw an error otherwise.

In languages with ad-hoc polymorphism and operator overloading, you can emulate the Javascript experience by manually adding all the different cases yourself, in some sense 'weakening' the type system.

Rust is strongly typed, it won't let you add or compare two values of different datatypes, even if they're both integers. For example you can't add a `u8`(byte) and a `i64`(long int) without casting.

Meanwhile Python, JS and many other weakly typed languages will happily add an integer and a float, maybe even a string and a number without complaints.

The advantage of the former are more rigorous compile-time checks, which might catch bugs where you added/compared the wrong values. But of course it's a bit more cumbersome especially if you're not used to it. I personally prefer it, I've had numerous cases where my Python script crashed 10 minutes into some data processing because it realised I tried to add two incompatible values.

No, those aren't the same thing. For example, C is both statically typed (there's no type checks or type information at runtime) and weakly typed (if you use a value of one type, like char, somewhere that another type, like _Bool, was expected, an implicit conversion will usually happen instead of an error).

GHC does do those things when you're compiling code in files. The only reason you aren't seeing it in this article is that these errors came from entering one expression at a time into the REPL.

Yeah, that's definitely a confusing part of GHCi. If you see an error message like the one in the post

  Prelude> 1+[2,3]
  
  <interactive>:1:1: error:
      • Non type-variable argument in the constraint: Num [a]
        (Use FlexibleContexts to permit this)
      • When checking the inferred type
          it :: forall a. (Num a, Num [a]) => [a]

The "line-number" is found on this line

  <interactive>:1:1: error:

Since it's in a REPL, it is referring to the first line you entered.

The more confusing part is that the important error is found here

        • When checking the inferred type
            it :: forall a. (Num a, Num [a]) => [a]

where it is assumed that you know all REPL statements that don't bind to a variable are bound to a variable named "it". So the error is really saying that the whole expression 1+[2,3] has that inferred type, and that type is bad.

If you load your example into a file and run GHC on it, it will produce a still confusing error message, but it will at least show you where the problems are

  error-message.hs:3:11: error:
      • No instance for (Num [a0]) arising from a use of ‘+’
      • In the expression: 1 + [1, 2]
        In an equation for ‘badType’: badType = 1 + [1, 2]
    |
  3 | badType = 1 + [1,2]
    |           ^^^^^^^^^

(I've omitted another, much longer error message it spewed out which is similarly confusing)

In this case the code is just above in the REPL. If you compile a source file, the exact spot is always pointed at by the compiler.

Some advanced Haskell features make this hard because constraints like 'a is a number' are solved separately. For instance

    data Tag a where
        IsInt :: Tag Int
        IsDouble :: Tag Double

    someNum :: Num a => a
    someNum = 3 * 4 + 5

    pickNum :: Tag a -> a
    pickNum IsInt = someNum
    pickNum IsDouble = someNum * 2.5

Constraints can be delayed and changed by pattern matching, so the origin might not be obvious. There are ways around this, but they require tracking why values are set and to propagate this information around. Haskell has Turing complete type level functions so you have to figure out how they propagate this dependency information.

GHC handles some easy cases, if you compiler in a file it does point to `+`, but it can get hairy. Also, currying can make it harder to say 'you swapped to arguments'

A garbage collected language.