search

goldfirere / units

The home of the units Haskell package
95 stars 19 forks source link

Type errors appear at wrong place. #33

Closed nushio3 closed 9 years ago

nushio3 commented 10 years ago

Yesterday, I was able to locate the source of an error that have been haunting me for a while. First, please look at the following code. The function area1 is defined with correct unit, but is used with wrong unit in another function ratio . The type error is correctly reporting the unit error in the body of ratio. https://github.com/goldfirere/units/blob/master/Tests/Compile/Error/Case1b.hs

However, if we make a slight modification to the above code, evil happens. https://github.com/goldfirere/units/blob/master/Tests/Compile/Error/Case1a.hs

In Case1a.hs, the function modelNorm is defined with correct unit, but is used with wrong unit in another function. However, the error is reported at the point definition (which is nothing wrong) and not at the point of use. These kind of error message may cause the users to waste time looking hard for error in the functions, that contains no error (as I did.) Strangely enough, the error related to function area1 is also reported at wrong place in Case1a.hs, even though the source code parts related to area1 is not modified at all.

The only thing I can see that connects the two parts is the QofU type synonym. I can also reproduce the symptom using MkQu_ULN , a type synonym that belongs to units library.

https://github.com/goldfirere/units/blob/master/Tests/Compile/Error/Case1c.hs

I cannot figure out any further about this error. Is this a mis-design of the library (hard to believe,) or is it a GHC bug? The behavior reproduces on the latest ghc-7.8.3. Since this is beyond my understanding, Let me report and consult to upstream (first to @goldfirere and then maybe to the GHC team.)

goldfirere commented 10 years ago

Filed [https://ghc.haskell.org/trac/ghc/ticket/9318 GHC#9318]. This does not seem to be units's error. Thanks for discovering!

Keeping this ticket open to re-test after GHC#9318 is fixed.

nushio3 commented 10 years ago

Thank you for reporting upstream. Indeed, the source of the error is much simplified!

goldfirere commented 9 years ago

This looks fixed in GHC 7.10. It turns out that reporting this error spurred on major innovation in GHC's solver.