On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese <dominique.devri...@cs.kuleuven.be> wrote: > As an outsider, I would like to suggest thinking about MonoLocalBinds. GHC > has a rather convincing story (at least to me) that "(local) let should not > be generalised" (since it becomes problematic in combination with several > other language extensions) and the journal version of the OutsideIn(X) paper > has empirical data that indicates it is not a big problem to remove. If > there is a concern about backwards compatibility, perhaps the committee > could deprecate local let generalisation in Haskell2020 and remove it in a > subsequent iteration of the report?
FWIW, I'm against MonoLocalBinds. I understand the rational given in the paper, but I disagree with it. In my experience the medicine is worse than the disease. It used to be that where-clauses where a nice clean way of organizing code, especially for things like the worker/wrapper transform; but with MonoLocalBinds all the benefits of where-clauses are eliminated. For every local binding I'm forced to provide a type signature —because part of the whole *point* of factoring things out is that you're going to use them repeatedly, which for GADTs virtually guarantees the uses will be at different index types and therefore will require universal quantification— and these requisite type signatures almost entirely duplicate information provided by the signature for the primary/top-level binding. Indeed, in almost every situation I end up needing to manually provide type signatures which are identical to what let-generalization would have inferred. This repetition is not merely annoying, it actively harms legibility and maintainability of code. -- Live well, ~wren _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime