Are there GHC extensions we'd like to incorporate wholesale?

[Simon Peyton Jones]

Just to be clear, MonoLocalBinds, as implemented, does not apply to local bindings that could equally well have been written at top level; that is, they do not mention any locally-bound variables (except other local bindings that could themselves be floated).

So you are at liberty to use where for stylistic reasons.

You may still dislike the cure, but the disease is pretty bad.  Do suggest alternative cures!

This is not to argue for or against MonoLocalBinds for Haskell Prime.

Simon

|  -----Original Message-----
|  From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: haskell-prime at haskell.org List <Haskell-prime at haskell.org>
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|  <dominique.devriese at 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 at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d