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
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