Example for "ambiguous type variable" error doesn't work anymore

[konsumlamm]

Chapter 3 has an example that read "4" produces an "ambiguous type variable" error. However, this is not the case anymore, since GHCi disables the MonomorphismRestriction, it now throws a "no parse" exception. The problem is that this is used to explain how to specify a type with an explicit type annotation.

I think the easiest solution would be to simply put the definition in a file. Can you think of a better solution?

[MatthijsBlom]

Many readers will try this for themselves, in GHCi. The new behaviour should probably be explained.

I see value in additionally comparing the behaviours of files vs. GHCi.

Type defaulting is also at play: Read a => a defaults to ().

TypeApplications come in handy in situations like this, but chapter 3 is probably a bit too early for introducing language extensions. On the other hand: GHC2021 implies TypeApplications, and is included and on by default since GHC 9.0.

[smith558]

Isn't the example still quite appropriate (because the solution to the presented problem is an explicit typing annotation) but only needs updating and an explanation of the "no parse" error? Interested in your thoughts. Open to a complete rework of the example as well.

[MatthijsBlom]

Isn't the example still quite appropriate (because the solution to the presented problem is an explicit typing annotation)

I'd say yes, it is still appropriate. Not because the solution is the same though, but rather because read "4" remains a reasonable query from the reader's perspective. Removal of this example would be a loss, I think.

Open to a complete rework of the example

It seems to me the old explanation mostly still holds up, and that only a bit about extended defaulting rules in GHCi needs be be woven through.