[GHC] #15247: Use empty types for TTG extension constructors

[GHC]

#15247: Use empty types for TTG extension constructors
-------------------------------------+-------------------------------------
        Reporter:  adamgundry        |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:  TTG
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 adamgundry):

 Replying to [comment:2 alanz]:
 > I just tried this, and it seems the additional match is still required.
 I end up with
 >
 > {{{#!hs
 > compiler/hsSyn/HsTypes.hs:1286:1: error: [-Wincomplete-patterns, -Werror
 =incomplete-patterns]
 >     Pattern match(es) are non-exhaustive
 >     In an equation for ‘unambiguousFieldOcc’:
 >         Patterns not matched: (XAmbiguousFieldOcc _)
 >      |
 > 1286 | unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel
 > }}}
 >
 > having removed the last line of
 >
 > {{{#!hs
 > unambiguousFieldOcc :: AmbiguousFieldOcc GhcTc -> FieldOcc GhcTc
 > unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel
 > unambiguousFieldOcc (Ambiguous   rdr sel) = FieldOcc rdr sel
 > unambiguousFieldOcc (XAmbiguousFieldOcc _) = panic "unambiguousFieldOcc"
 > }}}
 >
 > Perhaps I misunderstand how this is intended to work?

 You can't remove the last line entirely because it can still potentially
 match (if called with `XAmbiguousFieldOcc undefined`). But you can
 eliminate the empty data type with an empty case analysis (or calling my
 `noExtConstructor`).


 Replying to [comment:3 Shayan-Najd]:
 > Take a look at ImplementingTreesThatGrow/TreesThatGrowGuidance, there we
 use the "standard" empty type Void and its eliminator absurd from
 Data.Void.
 >
 > Currently, TTG does not fully follow the guidelines as the extension
 constructors are barely used. I will soon have a pass over the current TTG
 implementation and fix it to match the guidelines.

 Okay, it sounds like we are in agreement. That page could be a bit more
 explicit about the use of the empty type (the only mention I can see is
 one line of an example using `Void`). Moreover, it doesn't seem to mention
 `NoExt`.


 > As we used NoExt instead of (), we can possibly use a GHC-Specific empty
 datatype instead of Void.

 Yes, I think this would be a good idea. It's clearer for documentation
 purposes to use a custom empty datatype, and given that the only
 duplication consists of precisely one type constructor and one function,
 reusing `Data.Void` doesn't buy much.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15247#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler