[GHC] #14771: TypeError reported too eagerly
GHC
ghc-devs at haskell.org
Thu Feb 8 18:02:26 UTC 2018
#14771: TypeError reported too eagerly
-------------------------------------+-------------------------------------
Reporter: hsyl20 | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 8.2.2
checker) | Keywords:
Resolution: | CustomTypeErrors
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect | Unknown/Multiple
error/warning at compile-time | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by diatchki):
As for issue 1), I am a bit weary of doing the change, as the current
behavior has a fairly simple explanation; the alternative I mentioned
would be more of a heuristic, as I don't think we have a specific order of
evaluation, and it could make some custom errors not show up, when you'd
like them to show.
Generally, even though `TypeError` is implemented just as a type function,
I really think of it more of a special right-hand side in type function
definitions. If you use it in this way, then you don't encounter the
problems you found, because the type error is only ever generated when
there is no other alternative. So this is how I'd structure your example
in this style:
{{{
type family Assert (prop :: Bool) (val :: k) (msg :: ErrorMessage) where
Assert 'True val msg = val
Assert 'False val msg = TypeError msg
}}}
In fact, we should probably add this type function to `Data.Type.Bool`.
With this combinator, you could define `F` simply as:
{{{
type F n = Assert (n <=? 8) Int (Text "Input to F should be no greater
than 8")
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14771#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list