Fix ambiguous type error example by MatthijsBlom · Pull Request #144 · learnyouahaskell/learnyouahaskell.github.io

MatthijsBlom · 2026-03-12T22:41:51Z

Due to ExtendedDefaultRules being enabled by default, GHCi no longer produces an error in the example about ambiguous type variables.

This change amends the original explanation.
It explains the new situation in GHCi, and compares with and elaborates on GHC's behavior.

Fixes #25

if b22f71a is accepted: open issue about adding section about type variable defaulting. See Fix ambiguous type error example #144 (comment).

ulysses4ever · 2026-03-13T00:00:11Z

Thank you for submitting this patch! I'll try to review by the end of the week.

ulysses4ever · 2026-03-13T13:38:23Z

In the meantime, it'd be great if you could resolve the conflicts.

ulysses4ever · 2026-03-13T13:42:24Z

+GHC even tells us as much: whatever the type of `four` is, it must be part of `Read`.
+But it can't tell that it is, because it doesn't know the actual type: it is ambiguous.
+Whereas GHCi at this point tried to guess, GHC does not.
+Instead, it immediately complains and demands that we clarify the type.


Can you and an example that type check and works in the end? E.g.

> read "4" :: Int 4

There are already several such examples immediately before this added section.

I tacked on the read "13" :: Bool example for contrast with the preceding examples, and also to demonstrate that the GHCi-guessed-wrong explanation is correct.

Do you still feel there should be an example of success further down?

ulysses4ever · 2026-03-13T19:28:55Z

 If we used it as a boolean, it knew it had to return a `Bool`.
 But now, it knows we want some type that is part of the `Read` class, it just doesn't know which one.
+And sometimes, when it cannot figure out a type, GHCi tries to be helpful by taking a guess.
+Not just any guess of course, but wrong in this case anyway.


Have you considered showing what guess it took? It's the unit type.

λ> :set -Wtype-defaults λ> read "4" <interactive>:6:1: warning: [GHC-18042] [-Wtype-defaults] • Defaulting the type variable ‘a0’ to type ‘()’ in the following constraints (Show a0) arising from a use of ‘print’ at <interactive>:6:1-8 (Read a0) arising from a use of ‘it’ at <interactive>:6:1-8 • In a stmt of an interactive GHCi command: print it *** Exception: Prelude.read: no parse λ>

Maybe mentioning that it's the unit is enough. Otherwise, -Wtype-defaults may be a good candidate for a NOTE.

I have, but I couldn't find a satisfactory way of figuring it out.
Even already knowing the answer, I failed to trace the exact route that led to it. I thought I remembered a default declaration with number types somewhere in base, but I couldn't find any default declaration that I'm confident is actually used (and remotely relevant).
There seems to be no way of listing all default rules in scope.

As it currently stands, nowhere in the book is there any mention of compiler warnings, compiler flags, :set, language extensions, or pragmas. Any first mention would likely require quite a bit of extra explanation.

-Wtype-defaults seems too specific. But it is included in -Wall.
What do you think about writing a suitable .ghci and recommending it early in the book?

And sometimes, when it cannot figure out a type, GHCi tries to be helpful by taking a guess.
Not just any guess of course, but wrong in this case anyway.

IMO, this is a little bit too vague, because it makes the reader feel that ghci behavior is a surprise. It is kind of tricky to clarify because () was not introduced yet. I am not totally sure how to solve this tension.

But it is a surprise, isn't it? 😏
I'd prefer GHC(i) just didn't do this by default.

() is in fact introduced earlier in this same chapter.
I don't think the bulk of the trickiness lies with (). But it sure is tricky.
I'll do some more thinking.

errors.haskell.org/messages/GHC-39999 seems outdated, by the way.

I think my preference would be to add a .hintbox here with a reference to a yet-to-be-written appendix specifically about type variable defaulting.

There is a lot to be explained (extensions/settings, GHCi vs. GHC, default rules, the defaulting mechanisms, possibly warnings, possibly interaction with the monomorphism restriction), and probably several examples should be included. Including all this in this chapter would, I feel, disrupt the text too much. But defaulting is still worth discussing. Therefore: split it off.

What do you think?

If this way is chosen, I'd prefer to defer adding this appendix to a future PR.

Sure, perfect is the enemy of good.

I added b22f71a for now.

pierluc-codes

My apologies, I put a lot of comment on your work: do not take that as a criticism of the quality of the work. I really appreciate your changes here.

I especially appreciate the effort of keeping the tone of the rest of the book.

Thank you!

pierluc-codes · 2026-03-14T10:56:52Z

 If we used it as a boolean, it knew it had to return a `Bool`.
 But now, it knows we want some type that is part of the `Read` class, it just doesn't know which one.
+And sometimes, when it cannot figure out a type, GHCi tries to be helpful by taking a guess.
+Not just any guess of course, but wrong in this case anyway.


And sometimes, when it cannot figure out a type, GHCi tries to be helpful by taking a guess.
Not just any guess of course, but wrong in this case anyway.

IMO, this is a little bit too vague, because it makes the reader feel that ghci behavior is a surprise. It is kind of tricky to clarify because () was not introduced yet. I am not totally sure how to solve this tension.

pierluc-codes · 2026-03-14T11:03:08Z

+Whereas GHCi at this point tried to guess, GHC does not.
+Instead, it immediately complains and demands that we clarify the type.
+
 Most expressions are such that the compiler can infer what their type is by itself.


I think this part should be moved.

Yeah, I considered doing this as well. In the end I kept it because of its final line, because I thought the repetition wouldn't hurt, and because it seemed to flow better into the next section.

I'll do some thinking about how to incorporate the last line's information somewhere else.

Addressed in 73a8fd1.

MatthijsBlom · 2026-03-15T15:45:18Z

My apologies, I put a lot of comment on your work: do not take that as a criticism of the quality of the work. I really appreciate your changes here.

No worries!

I especially appreciate the effort of keeping the tone of the rest of the book.

Good to hear that this has apparently been successful.

ulysses4ever · 2026-04-07T13:13:26Z

I promise I'll get to this one this month of April! Sorry for the delay!

MatthijsBlom requested review from konsumlamm, memowe, pierluc-codes, smith558, ulysses4ever and xogcox as code owners March 12, 2026 22:41

MatthijsBlom force-pushed the ambiguous-type-example branch from 22ffc40 to 4c6f98c Compare March 13, 2026 15:31

Fix ambiguous type error example (learnyouahaskell#25)

26f0b70

MatthijsBlom force-pushed the ambiguous-type-example branch from 4c6f98c to 26f0b70 Compare March 13, 2026 15:38

ulysses4ever reviewed Mar 13, 2026

View reviewed changes

pierluc-codes reviewed Mar 14, 2026

View reviewed changes

minor adjustments in response to feedback

d2d75dc

MatthijsBlom changed the title ~~Fix ambiguous type error example (#25)~~ Fix ambiguous type error example Mar 15, 2026

clarify cause of runtime error

2769361

MatthijsBlom force-pushed the ambiguous-type-example branch from be8a30c to 2769361 Compare March 26, 2026 09:35

MatthijsBlom added 2 commits March 26, 2026 11:12

refer to GHC User's Guide on type defaulting

b22f71a

move up final paragraph

73a8fd1

Conversation

MatthijsBlom commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ulysses4ever commented Mar 13, 2026

Uh oh!

ulysses4ever commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MatthijsBlom Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pierluc-codes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MatthijsBlom commented Mar 15, 2026

Uh oh!

ulysses4ever commented Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MatthijsBlom commented Mar 12, 2026 •

edited

Loading

MatthijsBlom Mar 13, 2026 •

edited

Loading