I mean for the fixed / new one I’m proposing :) On Sun, May 20, 2018 at 8:21 PM Carter Schonwald <carter.schonw...@gmail.com> wrote:
> No. I’m saying make same variables get the parent quantified, even if it’s > implicit. > > Breaking changes are ok if they make things better. > > Measuring impact really comes down to making the patch and measuring. It > will be an easy to fix breaking change and my experience has been that > teams in an industrial context are a ok with none silent breaking changes. > This would be very easy to catch :) > > On the pedagogy side it actually makes learning simpler afaict :) > > On Sun, May 20, 2018 at 8:03 PM Anthony Clayden < > anthony_clay...@clear.net.nz> wrote: > >> On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald < >> redir...@vodafone.co.nz> wrote: >> >>> indeed .. and we can reasonably say "lets deal with the bandaid in one >>> go by cleaning it up in the next standard" >>> >> >> Thanks Carter/Brandon, the reason for asking how we should go about the >> discussion was exactly: where/how are we going to maximise the chance of >> finding out what code is out there, and how disruptive any 'clean up' might >> be? >> >> Ghc has occasionally made breaking releases (not saying that's what we >> want to do), usually with some advance warning/deprecation period. And >> generally the Haskell community has accommodated that with understanding of >> the decision, to fix their code. >> >> >> >>> so what would the next gen look like? >>> >>> eg: fresh variables get the usual implicit forall at the front of the >>> type, and everything else either needs an explicit quantifier OR it refers >>> to the outer implicit quantified variable? >>> >> >> I wanted to avoid discussing 'next gen' in possibly-obscure/write-only >> mailing lists; and preferably get the discussion where posterity can see >> the reasoning/examination of options. >> >> "fresh variables get the usual implicit forall" is what happens now. >> (It's just that the User Guide explains it really badly -- I'm trying to >> fix that separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If >> the outer variable(s) are not explicitly forall-quantified, then even >> same-named variables count as fresh. IOW merely putting a `forall` can >> change the meaning of a program -- that's what causes the most confusion >> (judging by SO). >> >> The exception is variables bound in a pattern signature for an >> existentially-quantified data constructor: they *must* be fresh. This is >> hard for a reader to follow because the pattern signature with data >> constructor looks the same whether or not the constructor is >> existentially-quantified. What's worse a constructor might have a mix of >> existential and universal variables. >> >> AntC >> >> >>> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery <allber...@gmail.com> >>> wrote: >>> >>>> On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden < >>>> anthony_clay...@clear.net.nz> wrote: >>>> >>>>> So the explanation I've seen for the current design is it was >>>>> deliberately idiosyncratic, to minimise any disruption to existing code. >>>>> Then I'm asking whether any of that code is still around? If not/if it's >>>>> been re-factored to use ScopedTypeVariables, then any tweak to the design >>>>> could have a freer hand. >>>>> >>>>> >>>> The reason there's no discussion about that is that nobody here has the >>>> ability to go hunt down every last piece of code in every public or private >>>> (think Standard Chartered, Facebook, etc.) code base and its current owner, >>>> and order them to "fix" it. You can't win that battle. >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine >>>> associates >>>> allber...@gmail.com >>>> ballb...@sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>>
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
