[GHC] #14917: Allow levity polymorphism in binding position
GHC
ghc-devs at haskell.org
Fri Apr 6 13:05:26 UTC 2018
#14917: Allow levity polymorphism in binding position
-------------------------------------+-------------------------------------
Reporter: andrewthad | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.2.2
Resolution: | Keywords:
| LevityPolymorphism
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by andrewthad):
There was a reddit discussion[1] that reminded me of this, and it got a
tangential but related idea going in my mind. I wonder if there's any
connection between user-defined functions with a compulsory unfolding and
`UNPACK` on polymorphic fields in a data constructor (currently disallowed
because they result in code that cannot be compiled). Roughly, the idea
was that a compulsory unfolding would be required for functions that
target data types with unpacked polymorphic fields. For example:
{{{
data Foo a = Foo {-# UNPACK -#} !Int {-# UNPACK #-} !a
{-# INLINE MANDATE useFoo #-}
useFoo :: Foo a -> a
useFoo (Foo _ a) = a
}}}
This would also lift the restriction on levity-polymorphic fields in a
data constructor. There are a bunch of other problems with this that may
not be possible to resolve. How does pattern matching actually work with
this? How can `Foo Word` be stored inside of another data type? Anyway,
I'm not convinced this could actually go anywhere, but I thought I'd jot
it down.
[1]
https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontainers/
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14917#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list