Hi Ganesh, Make sure you are using RC2 of the compiler, from what I remember RC1 required signatures it shouldn't have, or enabled MonoLocalBinds more than it should - RC2 required less signatures. However, your code could well just be heavily using the relevant features.
Thanks, Neil On Tue, Nov 2, 2010 at 1:28 PM, Sittampalam, Ganesh <ganesh.sittampa...@credit-suisse.com> wrote: > Simon Marlow wrote: >> On 02/11/2010 07:37, Sittampalam, Ganesh wrote: >>> I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40 >>> signatures for MonoLocalBinds in about 140 files/30K LOC. Is that >>> about normal? darcs does make fairly heavy use of rank 2 polymorphism >>> which leads to quite a lot of local definitions needing to be >>> polymorphic. >> >> Sounds about right given my experience so far, but as you say it >> depends a lot on the style of code involved. Some people tend to >> write a lot more polymorphic local bindings than others :-) > > In the case of darcs much of the fundamental structure of the code > pushes us that way; code that works on repositories is written as > "withRepository (some polymorphic function)" so that it's generic on the > specific repository type, and since where clauses generally scope > outside the withRepository they get bitten. Similarly our witnesses > lists of patches have map operations with rank-2 types. > >>> Also, NoMonoLocalBinds didn't help at all, which surprised me a bit - >>> I thought it might at least make some of the signatures unnecessary. >> >> I suspect MonoLocalBinds is being turned on again by an option later >> in the ordering. I had this problem a lot when trying to use >> NoMonoLocalBinds, it's actually quite hard to make it stick. e.g. if >> you have LANGUAGE GADTs in the source file, that will override >> NoMonoLocalBinds on the command line. > > Ahh. I'd put it as the first option! > >> I'm not sure what (if anything) we should do about this. > > It intuitively feels like language specifiers should be > order-independent, but when you have positive and negative extensions > like we do that's not trivial to achieve. Perhaps we could do better if > more combinations were errors instead of taking the last selection. > Also, perhaps options that imply other options could be decomposed into > the underlying pieces, with the high-level options being aliases for > baskets of the lower-level ones. So GADTs = GADTsCore + MonoLocalBinds, > and then GADTS + NoMonoLocalBinds (in any order) = GADTsCore + > MonoLocalBinds + NoMonoLocalBinds = an error. > >>> Finally, is NoMonoLocalBinds supposed to imply NPlusKPatterns? The >>> only changes I was able to revert when I enabled it were a couple of >>> those! >> >> It certainly is not, if you have evidence to the contrary please >> submit a bug report. > > OK, I'll check. > > Cheers, > > Ganesh > > =============================================================================== > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > =============================================================================== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users