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

| > 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. | | I was using RC2. But darcs uses GADTs globally so MonoLocalBinds is always | on. | | I've now retested with NoMonoLocalBinds properly enabled and I just needed | one extra signature. OK that's better! I was surprised when you said it didn't work. If you had type signatures to make GADTs work, you may be able to remove some of them, in which case you'd be in profit :-) | That's quite compelling, but I'm aware it's not | considered a "reliable" feature so I'm not quite sure which way to go. Well, I'm aware that it's a compromise. I don't know how to do a bang-up principled job of typechecking local polymorphism, so GHC does a best-effort job. In fact best effort is pretty good, and it's not hard to implement, so a) I don't expect to remove NoLocalMonoBinds b) I expect it will work fine 99% of the time My suggestion would be to keep it as a {-# LANGUAGE NoLocalMonoBinds #-} in each module that needs it for now. You can remove it gradually. Concrete examples of where the absence of local polymorphism is painful would also be a good thing; you could attach a comment to my blog post. Maybe there are useful special cases or something. Simon

| > Well, I'm aware that it's a compromise. I don't know how to do a bang-up principled | job of typechecking local polymorphism, so GHC does a best-effort job. In fact best | effort is pretty good, and it's not hard to implement, so | > a) I don't expect to remove NoLocalMonoBinds | > b) I expect it will work fine 99% of the time | | What happens in the other 1%? Does the program just get rejected for no | apparent reason, or can more nefarious things happen In the 1% case I fear that an apparently-innocuous change to the program would make it change from rejected to accepted or vice versa. Or, to put it another way, the same program compiled with one Haskell compiler is accepted, but is rejected by another Haskell compiler. The realist says "who cares, I only use GHC". But I find that un-satisfying. There should be a good definition of what is a Haskell program and what isn't. "Whatever GHC accepts" isn't a good answer. But that's as nefarious as it gets Simon