[Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
eir at cis.upenn.edu
Sun Feb 7 14:59:25 UTC 2016
On Feb 7, 2016, at 4:22 AM, Evan Laforge <qdunkan at gmail.com> wrote:
> 1, Just to clarify, there are no actual known uses for a
> TypeRep-polymorphic ($), right? I thought I saw someone say that.
Here is where this treatment of ($) was introduced: https://ghc.haskell.org/trac/ghc/ticket/8739
> 2, ($) has had a fib in its type for a very long time, but did it ever
> hurt anyone? The closest I saw was a generalized concern about it
> being bad when people report a bug and then hear that things are more
> general than they thought and I guess this makes their bug not a bug
> or something? Results in some confusing back-and-forth? It would be
> nice to get more specific about how much trouble the ($) lie has
I don't have data, but there is a real cost to lying. It shows up in the slow-ish but steady stream of posts / questions / bug reports that are produced saying something is weird. I've seen a good number of these come up in my years in the Haskell community. I'll note that there is also a real cost to telling the truth: witness this thread. This all adds up to a need to do both, which is what we would get by having a richer REPL environment.
> 3, Is anything other than ($) TypeRep-polymorphic?
Yes: undefined and error. These really are used at unlifted types.
> If 2 is "not very much", an obvious solution is to keep lying and not
> worry about it. But clearly someone had a reason strong enough to
> make this change... what was it?
The change to the user-visible type of ($) is due to updates around TypeInType. But ($)'s ability to handle this case has been around since 7.8. Note that if you say :i $ in GHCi 7.10 you get a mention of OpenKind, which is the ancestor of current representation-polymorphism. It's just that :t ($) did a nice job of hiding it.
> I hesitate to get distracted from the specifics, but I agree with Ben
> Lippemeier in that I like how haskell doesn't make me worry about
> boxed vs. unboxed. I'm not saying one little type annotation on one
> operator is suddenly making me worry since I've never even thought to
> run :t ($). But I'm happy that # is mostly off in its own little
> corner and you don't even have to know it exists until you need to get
> into low level optimization.
And this is what the new -fshow-runtime-rep flag will (re-)enable.
More information about the Haskell-Cafe