GHC used to always generalize let-bindings, but our experience
with GADTs lead us to decide that let should not be generalized
with GADTs. So, it's not like we /wanted/ MonoLocalBinds, but
that having them makes the GADT machinery simpler.
This blog post gives more details on the matter:
http
Such order dependent could be very confusing for the users. I thought I
turned off certain feature but some other extension turning it on is
strange. Wouldn't it be better to decouple GADT and MonoLocalBinds?
2015년 06월 04일 20:31에 Edward Z. Yang 이(가) 쓴 글:
This is because -XGADTs implies -XMonoL
This is because -XGADTs implies -XMonoLocalBinds.
Edward
Excerpts from Ki Yung Ahn's message of 2015-06-04 20:29:50 -0700:
> \y -> let x = (\z -> y) in x x
>
> is a perfectly fine there whose type is a -> a.
> (1) With no options, ghci infers its type correctly.
> (2) However, with -XGADTs, typ
> Simon Peyton Jones microsoft.com> writes:
>
> I think it's pretty good as-is.
>
Thank you Simon, I'm agreeing with "pretty good",
though possibly not with "pretty" ;-)
> ...
> * Use a closed family (with overlap and top-to-bottom matching)
>to deal with that part of the space:
>
> Doing
I think it's pretty good as-is.
* Use an open family (with non-overlapping instances) to get yourself
into part of the match space:
type instance OpenF (Foo b c) = FFoo (Foo b c)
* Use a closed family (with overlap and top-to-bottom matching) to
deal with that part of the space:
ty
