Skip to content

Commit 3c29e7e

Browse files
committed
Add another example for GHC-39999
1 parent a77842c commit 3c29e7e

3 files changed

Lines changed: 39 additions & 0 deletions

File tree

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
module Lib where
2+
3+
foo :: [Int]
4+
foo = map (+ 1) [0]
Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
module Lib where
2+
3+
foo :: [Int]
4+
foo = map (+ 1) 0
Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
---
2+
title: No instance for ‘Num [Int]’ arising from the literal ‘0’
3+
order: 5
4+
---
5+
6+
## Error message
7+
8+
```
9+
Lib.hs:4:17: error: [GHC-39999]
10+
• No instance for ‘Num [Int]’ arising from the literal ‘0’
11+
• In the second argument of ‘map’, namely ‘0’
12+
In the expression: map (+ 1) 0
13+
In an equation for ‘foo’: foo = map (+ 1) 0
14+
|
15+
4 | foo = map (+ 1) 0
16+
| ^
17+
```
18+
19+
## Explanation
20+
21+
Sometimes, when GHC encounters a type error, it suggests solving
22+
it from an unexpected end. In this case, when it encouters a literal
23+
instead of a list, it does not just complain about it. Instead it suspects
24+
that maybe an author meant to overload numeric literals so that they can mean lists too.
25+
26+
Every time you write a numeric literal in Haskell,
27+
it gets desugared using `fromInteger :: Num a => Integer -> a`. So the program above
28+
would be absolutely valid if only `[Int]` itself (not just `Int`) was an instance of `Num`.
29+
While such interpretation of lists is not entirely out of the realm of possibility
30+
(say, imagine that lists represent coefficients of polynomials), it's much more likely
31+
that `map (+ 1) 0` is just a typo.

0 commit comments

Comments
 (0)