[Haskell-cafe] Cannot update a field in a record with a polymorphic type.
evincarofautumn at gmail.com
Sun Sep 6 18:13:57 UTC 2020
On Sun, Sep 6, 2020, 7:24 AM Ignat Insarov <kindaro at gmail.com> wrote:
> If a value of the
> transient instantiation of `defaultY` _(that exists only in the moment
> before its field is updated)_ is never observed, why does it need to
> be monomorphized? Why not be lazy about it?
You could just as well ask why ‘(== )’ or ‘(== Nothing)’ require an ‘Eq’
constraint even though it will provably never be used. The reason, of
course, is that the typechecker is only using purely local reasoning—yes,
if you inlined that function far enough into any use site, it would lead to
showing the ‘Eq’ redundant; and here, if you examined the update as a
whole, you would find the type of the subterm is redundant as well.
The same is true for typeclasses generally—instead of having bounded
polymorphism, we could just substitute types and see what happens, like C++
templates do, but having the requirements stated in the type improves the
predictability of whether something will typecheck, and improves the
quality of error messages when it doesn’t.
Basically, we accept that types will always be an *approximation* of terms.
You can draw the line at different points—with refinement types, you can
reason about the particular values or ranges of integers, for instance,
instead of the coarse-grained ‘Int’. But all solutions that give you finer
granularity also have tradeoffs in terms of ergonomics and predictability.
Haskell has largely chosen to draw the line at “syntax-directed” as our
criterion for how checking ought to work, assigning a type to every subterm
in the same way, without context. This has turned out to be pretty usable
in practice, even if there are some frustrating circumstances like this
where you as a human can plainly *see* a fact that the typechecker cannot.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe