[GHC] #10048: {-# UNPACK #-} support for size-indexed types
#10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I don't know too much of the theory, but it seems to me that `{-# UNPACK #-}` should be able to work for something like this: {{{#!hs data Tup (l::[*]) where Nil :: HList '[] Cons :: e -> {-# UNPACK #-} !(HList l) -> HList (e ': l) }}} This is essentially just `HList` from the `HList` package but strict in the second `Cons` argument. What I would want is for `Tup '[a,b,c]` to be represented in just the same way as `(a,b,c)`. When possible, I'd want the getters/setters/lenses to be optimized to index into the unpacked structure rather than walking along it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10048 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): How would we implement {{{ hlength :: HList l -> Int hlength Nil = 0 hlength (Cons _ xs) = 1 + hlength xs }}} then? (Bear in mind that we have no access to the type parameter `l` at runtime.) I think this sort of thing could only work with a type family rather than a GADT (and even then I haven't thought about whether it actually could work). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10048#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
How would we implement
{{{ hlength :: HList l -> Int hlength Nil = 0 hlength (Cons _ xs) = 1 + hlength xs }}}
then? (Bear in mind that we have no access to the type parameter `l` at runtime.)
I think this sort of thing could only work with a type family rather
#10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Replying to [comment:1 rwbarton]: than a GADT (and even then I haven't thought about whether it actually could work). Ah, you make a very good point. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10048#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): A difficulty is that in GHC today, each data constructor (such as `Cons` above) has a single, fixed memory layout. So if we have {{{ data T = MkT Bool {-# UNPACK !(Int, Int) #-} }}} we can decide to lay out `MkT` with a `Bool` field and two `Int` fields. But if we don't know `l`, we don't know how `HList l` is represented, so we can't do that. It's not just an implementation matter. Suppose at an allocation site we were allocating a `Cons` whose first arg was `'[Int,Bool]`. Then you could imagine whizzing up a specialised `Cons` constructor. But then `hlength` above would have to be able to consume that constructor! I don't know any way to do this without monomorphising the code. Which is often, ''but not always'' possible, so you'd also need an escape hatch for the impossible case -- and it's not obvious how to build the hatch. PhD thesis anyone? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10048#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC