Re: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation

9 Aug 2015

      #10716: Metadata in GHC.Generic should give access to strictness annotation
-------------------------------------+-------------------------------------
        Reporter:  StefanWehr        |                   Owner:
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by StefanWehr):

 == Extended API ==

 A new class is added to `GHC.Generics`:

 {{{#!hs
 class StrictSelector s
 }}}

 This class has no methods; it only serves as a type-level constraint for a
 selector having a bang pattern.

 Also, I suggest changing the `NoSelector` type from `GHC.Generics` to
 accept a new type parameter:

 {{{#!hs
 data NoSelector t
 }}}

 The new type parameter is either `NoStrict` or `Strict`. These two types
 are also added to `GHC.Generics`:

 {{{#!hs
 data NoStrict
 data Strict
 }}}

 For anonymous selectors, we define an instance for `StrictSelector`:

 {{{#!hs
 instance StrictSelector (NoSelector Strict)
 }}}

 So far, this encodes strictness of a selector on the type-level. To access
 this information on the value-level, I suggest adding a new method to the
 type class `Selector` from `GHC.Generics`:

 {{{#!hs
 class Selector s where
     selName :: t s (f :: * -> *) a -> [Char]
     selIsStrict :: t s (f :: * -> *) a -> Bool -- NEW
 }}}

 My API proposal is not backwards compatible: the change to `NoSelector`
 will definitely break existing code, the addition of a new type class and
 two new data types might break existing code if the names are already used
 for something different. I tried avoiding the change to `NoSelector` but
 couldn't come up with a solution that brings the strictness (or lazyness)
 of a selector to the type-level. (For the application I have in mind, it's
 not enough to have these information on the value-level only.)

 == Changes to the deriving mechanism ==

 The deriving mechanism for generics is extended in the following way:

 * replace occurrences of `NoSelector` with `NoSelector Strict` or
 `NoSelector NoStrict`
 * for named selectors carrying a bang pattern, generate an instance of
 `StrictSelector T`, where `T` is the type generated for the selector.

 I'm happy to provide a patch for this, but first I want to make sure that
 my design is reasonable. Any comments?

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10716#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler