
Hiya Haskellers, So there I was, punching away at the keys, working on the Haskell Weekly News tools when the solution to one of my problems fell on me like a ton of lambdas. The solution and problem it solved are immaterial, but suffice to say it involved the combination of associated types and monad transformers, as well as some fancy deriving to end up with this code: ##### type Context = ReaderT Email type Match t = StateT t IO type ContextMatch t a = Context (Match t) a newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO) class FilterState t where data FState t deliver :: FState t -> IO () ##### Again, the fine details are unimportant, but the punchline is `Filter` is a Monad which houses not only results, but also an internal state which will be used in the delivery of emails in some yet-to-be- determined way. Naturally, I want to use `deriving` to turn this puppy into a monad over it's second argument. In fact, the whole thing kind- checks alright, but presents me with this, the titular 'weirdest error I've ever seen...' ##### [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ HackMail/Email/ParseEmail.hs, interpreted ) [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ Email/Email.hs, interpreted ) [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/ Filter/Filter.hs, interpreted ) *** Exception: No match in record selector Var.tcTyVarDetails ##### Now, there are three tickets open on the GHC trac, found for me by the ever-helpful `copumpkin` on #haskell -- because I didn't think to look -- they are numbers 3621, 3422 and 2714. But none of them are sufficiently close to my case for them to make sense to me, nor are the solutions presented suitable for entry into my feeble noggin. (Thats just a purty way of saying I'm not smart enough to understand what any of it means...) So I beseech my fellow Haskellers[1], What the heck did I do to anger the Var.tcTyVarDetail gods? My guess (given what I can glean from the Trac entries) is that the `deriving ... MonadState ...` needs changing in some specific-yet- cryptic way, but I've only got my gut to go on... For the Record, and in the event it matters... [jfredett@Erdos]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 [jfredett@Erdos]$ uname -a Linux Erdos 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST 2009 i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux Thanks in advance for any help offered. /Joe [1] Bet you've never been beseeched before...

| [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | HackMail/Email/ParseEmail.hs, interpreted ) | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | Email/Email.hs, interpreted ) | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/ | Filter/Filter.hs, interpreted ) | *** Exception: No match in record selector Var.tcTyVarDetails This is a bug in GHC without a doubt. It's possible that it's fixed in 6.12 -- can you try the release candidate? If it is not fixed, or if it's too hard for you to try, can you submit a Trac bug report please? (Include your code, and instructions for how to reproduce. Thanks Simon

Okay, so -- I feel totally awesome -- I never found a GHC bug before... and a Haskell Celebrity responded to my post! *swoons* :) Serious question now, There's a fair amount of definitely irrelevant code (like the definition of the `Email` type, etc), should I post that in the report too (assuming it doesn't work in 6.12 or I can't get 6.12 working to try it)? Thanks, /Joe On Nov 12, 2009, at 4:07 AM, Simon Peyton-Jones wrote:
| [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | HackMail/Email/ParseEmail.hs, interpreted ) | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | Email/Email.hs, interpreted ) | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/ HackMail/ | Filter/Filter.hs, interpreted ) | *** Exception: No match in record selector Var.tcTyVarDetails
This is a bug in GHC without a doubt.
It's possible that it's fixed in 6.12 -- can you try the release candidate? If it is not fixed, or if it's too hard for you to try, can you submit a Trac bug report please? (Include your code, and instructions for how to reproduce.
Thanks
Simon

Actually, I just solved the problem... I think... In my original code, I had the newtype: newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO) I was trying to confirm that it actually was the `deriving ... MonadState Bool ...` part that was causing the problem, and then I realized, it's not `MonadState Bool` I want, it's `MonadState t`. Upon changing that, everything compiles fine and ghc hums along happily. Should I still submit a bug report for a bad error message? /Joe On Nov 12, 2009, at 12:58 PM, Joe Fredette wrote:
Okay, so -- I feel totally awesome -- I never found a GHC bug before... and a Haskell Celebrity responded to my post! *swoons* :)
Serious question now, There's a fair amount of definitely irrelevant code (like the definition of the `Email` type, etc), should I post that in the report too (assuming it doesn't work in 6.12 or I can't get 6.12 working to try it)?
Thanks,
/Joe
On Nov 12, 2009, at 4:07 AM, Simon Peyton-Jones wrote:
| [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | HackMail/Email/ParseEmail.hs, interpreted ) | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | Email/Email.hs, interpreted ) | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/ HackMail/ | Filter/Filter.hs, interpreted ) | *** Exception: No match in record selector Var.tcTyVarDetails
This is a bug in GHC without a doubt.
It's possible that it's fixed in 6.12 -- can you try the release candidate? If it is not fixed, or if it's too hard for you to try, can you submit a Trac bug report please? (Include your code, and instructions for how to reproduce.
Thanks
Simon

Hi Joe,
Serious question now, There's a fair amount of definitely irrelevant code (like the definition of the `Email` type, etc), should I post that in the report too (assuming it doesn't work in 6.12 or I can't get 6.12 working to try it)?
http://hackage.haskell.org/trac/ghc/wiki/ReportABug - this is the reference. Do as many steps on this list as you want to, the more the easier it is for the GHC people, but they all take time: 1) Attach all the source code, enough to replicate the bug. 2) Download GHC 6.12 and check that it's still a bug there (if it's been fixed then it doesn't matter). 3) Start to boil down the test case by removing Email etc The important thing is to replicate the bug, but if you go further then it's less work for the GHC people. Don't try reducing the bug with GHC 6.10.4 though, because if it's a very subtle bug then you may stop it happening on other versions.
Upon changing that, everything compiles fine and ghc hums along happily.
Should I still submit a bug report for a bad error message?
Yes, you crashed the compiler - that's a bug, even if it was caused by
invalid source code.
Thanks, Neil
On Thu, Nov 12, 2009 at 6:12 PM, Joe Fredette
Actually, I just solved the problem... I think...
In my original code, I had the newtype:
newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO)
I was trying to confirm that it actually was the `deriving ... MonadState Bool ...` part that was causing the problem, and then I realized, it's not `MonadState Bool` I want, it's `MonadState t`.
Upon changing that, everything compiles fine and ghc hums along happily.
Should I still submit a bug report for a bad error message?
/Joe
On Nov 12, 2009, at 12:58 PM, Joe Fredette wrote:
Okay, so -- I feel totally awesome -- I never found a GHC bug before... and a Haskell Celebrity responded to my post! *swoons* :)
Serious question now, There's a fair amount of definitely irrelevant code (like the definition of the `Email` type, etc), should I post that in the report too (assuming it doesn't work in 6.12 or I can't get 6.12 working to try it)?
Thanks,
/Joe
On Nov 12, 2009, at 4:07 AM, Simon Peyton-Jones wrote:
| [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | HackMail/Email/ParseEmail.hs, interpreted ) | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | Email/Email.hs, interpreted ) | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/ | Filter/Filter.hs, interpreted ) | *** Exception: No match in record selector Var.tcTyVarDetails
This is a bug in GHC without a doubt.
It's possible that it's fixed in 6.12 -- can you try the release candidate? If it is not fixed, or if it's too hard for you to try, can you submit a Trac bug report please? (Include your code, and instructions for how to reproduce.
Thanks
Simon
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

It's not a bad error message -- it's a crash, and that should never happen. Ideally, boil down the program to something small that still exhibits the crash, and submit that. Perhaps just the newtype declaration alone, with supporting definitions for ContextMatch etc? Try removing unnecessary stuff, to get it as small as possible. Thanks Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On | Behalf Of Joe Fredette | Sent: 12 November 2009 18:12 | To: Joe Fredette | Cc: Simon Peyton-Jones; Haskell Cafè | Subject: Re: [Haskell-cafe] The weirdest error I've ever seen... | | Actually, I just solved the problem... I think... | | In my original code, I had the newtype: | | | newtype FilterState t => Filter t a = Filter (ContextMatch t a) | deriving (Functor, Monad, MonadReader Email, MonadState Bool, | MonadIO) | | I was trying to confirm that it actually was the `deriving ... | MonadState Bool ...` part that was causing the problem, and then I | realized, it's not `MonadState Bool` I want, it's `MonadState t`. | | Upon changing that, everything compiles fine and ghc hums along happily. | | Should I still submit a bug report for a bad error message? | | /Joe | | On Nov 12, 2009, at 12:58 PM, Joe Fredette wrote: | | > Okay, so -- I feel totally awesome -- I never found a GHC bug | > before... and a Haskell Celebrity responded to my post! *swoons* :) | > | > Serious question now, There's a fair amount of definitely irrelevant | > code (like the definition of the `Email` type, etc), should I post | > that in the report too (assuming it doesn't work in 6.12 or I can't | > get 6.12 working to try it)? | > | > Thanks, | > | > /Joe | > | > On Nov 12, 2009, at 4:07 AM, Simon Peyton-Jones wrote: | > | >> | [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/ | >> | HackMail/Email/ParseEmail.hs, interpreted ) | >> | [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/ | >> | Email/Email.hs, interpreted ) | >> | [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/ | >> HackMail/ | >> | Filter/Filter.hs, interpreted ) | >> | *** Exception: No match in record selector Var.tcTyVarDetails | >> | >> This is a bug in GHC without a doubt. | >> | >> It's possible that it's fixed in 6.12 -- can you try the release | >> candidate? If it is not fixed, or if it's too hard for you to try, | >> can you submit a Trac bug report please? (Include your code, and | >> instructions for how to reproduce. | >> | >> Thanks | >> | >> Simon | > | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Joe Fredette
-
Neil Mitchell
-
Simon Peyton-Jones