#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