#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: 9097, 9380 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mboes): To be clear, as I have said before, I'm not arguing for reverting back to the status quo that we have in GHC 7.8. It's pretty clear that we want to avoid having (an infinite number of) exotic inhabitants of kinds that are intended to be closed (and often with a finite number of inhabitants). As I see it if the old `Any`-as-datatype is revived under a different name, without imposing any restrictions on what kinds it inhabits (i.e. only open kinds), it would have to be in an `Unsafe.*` module, and only brought in scope in some very clearly delineated modules. At least in the case of Cloud Haskell, there is no reason why the user needs to even know of its existence - it's use can be contained, "behind the scenes". That may well still be unsatisfactory. simonpj: I'm all for a better solution that is not a hack like `rank1dynamic` is, but do you have any ideas for how generating `TypeRep`s for polymorphic types might work? `rank1dynamic` has the merit of existing today, and the reason we're seeking to extend it is precisely to help with #7015 without having to rewrite some of the internals of `distributed- process`. Of course, if we do understand how to get type reps for polymorphic types, Facundo and I are happy to volunteer some time to do the rewriting. So again, there are 4 possible solutions here. I don't know which one would be best, but it would be nice to support a better story for Cloud Haskell, which already has a number of users, while still keeping to a minimal impact on the compiler. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9429#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler