MonoLocalBinds and darcs

[Neil Mitchell]

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 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>