Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sqrt' can convert meters to seconds with ghc8 #22

Closed
expipiplus1 opened this issue Sep 4, 2016 · 6 comments
Closed

sqrt' can convert meters to seconds with ghc8 #22

expipiplus1 opened this issue Sep 4, 2016 · 6 comments

Comments

@expipiplus1
Copy link
Contributor

expipiplus1 commented Sep 4, 2016

Among other things

ghc-7.10.3 seems to be fine.

This code compiles with ghc-8.0.1:

{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE DataKinds #-}
{-# OPTIONS_GHC -fplugin Data.UnitsOfMeasure.Plugin #-}

module Bug where

import Data.UnitsOfMeasure.Defs     ()
import Data.UnitsOfMeasure

bug :: Floating a => Quantity a [u|s|] -> Quantity a [u|m|]
bug = sqrt' 

{- Neither of these compile
bug' :: Floating a => Quantity a u -> Quantity a [u|m|]
bug' = sqrt' 

bug'' :: Floating a => Quantity a [u|s|] -> Quantity a u
bug'' = sqrt' 
-}
@expipiplus1
Copy link
Contributor Author

compiling with ghc instead of ghci panics:

[1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-unknown-linux):
        StgCmmEnv: variable not found
  irred_a8Lt
  local binds for:
  $trModule
  $trModule1_r8L9
  $trModule2_r8LJ
  $dFloating_s8LP

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

@adamgundry
Copy link
Owner

Hmm, this is surprising, thanks for the report. It looks like the constraint Base "s" ~ Base "m" ^: 2 is somehow getting forgotten. I'll investigate.

@expipiplus1
Copy link
Contributor Author

Thanks!

@expipiplus1
Copy link
Contributor Author

It's also possible to leave off the Floating a constraint too

@adamgundry
Copy link
Owner

Okay, I think I see what is going on here. Here's an explanation for posterity...

The plugin is correctly reporting the constraint Base "s" ~~ Base "m" ^: 2 as insoluble (note the use of ~~, which is a type family provided by uom-plugin that is a pseudo-synonym of ~). However, it turns out that the GHC error-reporting machinery requires a subtle invariant, namely that only certain kinds of constraint can be regarded as insoluble. Equalities are included, but not irreducible predicates such as ~~. Failure to respect this invariant means that errors are silently ignored.

Here's my plan to work around this:

  • for an insoluble wanted, neglect to report the constraint as insoluble, so it will be reported as unsolved instead (we can't change the actual wanted, otherwise it will be reported twice);
  • for an insoluble given, replace ~~ with ~ when reporting the constraint as insoluble, so it will be picked up by GHC.

This isn't completely satisfactory. It might be possible to do better using the new custom type errors machinery, but I haven't had time to look at that yet.

I suspect it would be a good idea to change GHC to always report insoluble constraints, even unusual ones arising from plugins. Otherwise this seems like a good source of subtle bugs.

@expipiplus1
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants