Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

I mean for the fixed / new one I’m proposing :) On Sun, May 20, 2018 at 8:21 PM Carter Schonwald 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

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

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

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald 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

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

indeed .. and we can reasonably say "lets deal with the bandaid in one go by cleaning it up in the next standard" 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

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

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

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

On Wed, 9 May 2018 03:01 UTC, cheater00 wrote: > I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out Yes absolutely. To be clear: nobody's talking about removing it. The question is, could we get the same functionality without being so confusing

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out 1. if the type being inferred is the one I expect 2. what type a specific thing in code I am working with is Also useful for adding that one bit the inferer is missing without immediately

Re: Open up the issues tracker on ghc-proposals

> On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote: > I am worried about the signal-to-noise ratio for those poor committee > members who have not given up on following the GitHub notifications for > the ghc-proposals repository > > Almost by definition, Issue-tracker traffic should

Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

This thread is a discussion about discussions, not the discussion itself ;-) I'm cc'ing to the cafe; but I'd prefer replies to come to glasgow-haskell-users. >> I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on

Scoped type variables Re: Open up the issues tracker on ghc-proposals

Please do this! I don’t care what forums or list or whatever. As long as it’s collated and such It could even be on the prime issue tracker for prime proposals. Just that it’s written down :) On Wed, May 2, 2018 at 7:17 PM Anthony Clayden wrote: > On Th, 3 May

RE: Open up the issues tracker on ghc-proposals

beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. The title of this thread, “Open up the issues tracker on ghc-proposals”, identifies a solution rather than a problem. Perhaps a constructive place to start would

Re: Open up the issues tracker on ghc-proposals

On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote: > I am worried about the signal-to-noise ratio for those poor committee members ... Thanks Joachim, Yes that's exactly the worry. So please tell the rest of us how to best use your collective time. First help yourselves/get your own shit

Re: Open up the issues tracker on ghc-proposals

Hi, Am Mittwoch, den 02.05.2018, 09:53 + schrieb Anthony Clayden: > Speaking as a non-developer of ghc, often there's a bright idea with no very > clear notion how best it fits into Haskell, or could be implemented > effectively/efficiently: > > * maybe it's something seen in another

Re: Open up the issues tracker on ghc-proposals

omes another backwater where ideas go to get ignored? > > > AntC > > >> >> | -Original Message- >> | From: Glasgow-haskell-users > | boun...@haskell.org> On Behalf Of Anthony Clayden >> | Sent: 02 May 2018 02:34 >> | To: glasgow-haske

Re: Open up the issues tracker on ghc-proposals

| To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org > | Subject: Re: Open up the issues tracker on ghc-proposals > | > | > On May 1, 2018, at 2:24 PM, David Feuer | gmail.com> wrote: > | > > | > Sometimes, a language extension idea could benefit from > |

RE: Open up the issues tracker on ghc-proposals

ite community discussion, prior to submitting to the committee for decision. Simon | -Original Message- | From: Glasgow-haskell-users On Behalf Of Anthony Clayden | Sent: 02 May 2018 02:34 | To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org | Subject: Re: Open up the i

Re: Open up the issues tracker on ghc-proposals

> On May 1, 2018, at 2:24 PM, David Feuer wrote: > > Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. Can I point out it's not only ghc developers who make proposals. I'd rather you post this idea more widely. As a