MonoLocalBinds and darcs

Neil Mitchell ndmitchell at
Tue Nov 2 18:54:08 EDT 2010

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.sittampalam at> 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:
> ===============================================================================
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list