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 impact really comes down to makin
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 indu
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 exactly: where/how are we going
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 refers
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
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 an
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 modifyin
> 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 *not*
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
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 2018 at 13:53 UTC, Joachim Breit
llenge
because 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
st
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 tog
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 langua
should be withdrawn and resubmitted as a 'fresh
> start'.
>
> OTOH, as I said, there's plenty of other forums those less
> formal/pre-proposal discussions could happen. Some used to happen on
> Trac/started life as bug reports -- which is rightfully discouraged.
appen. Some used to happen on
Trac/started life as bug reports -- which is rightfully discouraged.
_Could_ happen but often doesn't raise a response. What if Github issues
tracker just becomes another backwater where ideas go to get ignored?
AntC
>
> | -Original Message-----
>
are drafts that invite 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:
> 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 datapo
17 matches
Mail list logo