MonoLocalBinds and darcs

Sittampalam, Ganesh ganesh.sittampalam at
Tue Nov 2 09:28:49 EDT 2010

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.



Please access the attached hyperlink for an important electronic communications disclaimer: 

More information about the Glasgow-haskell-users mailing list