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

[Carter Schonwald]

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 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 
>>> 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

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

[Carter Schonwald]

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 
> 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 
>> 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

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

[Anthony Clayden]

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 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 
> 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

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

[Carter Schonwald]

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 to the
outer implicit quantified variable?

On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
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

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

[Brandon Allbery]

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, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Anthony Clayden]

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 and contrary to how Haskell usually works with type
variables? (I'm not saying yea or nay, I'm trying to invite
discussion.)

> ...

> Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc?

The current design for ScopedTypeVariables potentially changes the
types for programs that are valid H98/H2010. (Or for programs that
were valid as at when ScopedTypeVariables was introduced ~10 years
ago, perhaps using ExplicitForAll.) Probably the effect would be that
they don't compile, but it might be more subtle.


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.


But seems there's no enthusiasm for such discussion, so I'm going to
let it die. I hear there might be moves afoot elsewhere ...


AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[cheater00 cheater00]

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 modifying a complex type sig. I can do that later, but the
proof of concept should be quick and easy.

Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc?

On Sat, 5 May 2018 04:35 Anthony Clayden, 
wrote:

> 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
> github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
> thread? (It'll get ignored.)
>
> > ... 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 :)
>
> Thanks Carter, but I understand Haskell Prime to be to assess
> mature/stable proposals (preferably already delivered as extensions). This
> discussion is at first going to be more exploratory:
> * likes and dislikes about ScopedTypeVariables as currently.
> * confusions experienced by users (especially newbies)
> -- although absolute newbies wouldn't be using it(?), so intermediates?
> * feedback from those teaching Haskell.
> * wild ideas for possible alternative designs.
> * possible improvements to the current design.
> * I think we're all agreed that ScopedTypeVariables should have been in
> Haskell from the beginning;
> but it wasn't, so now we have to worry about backwards compatibility for
> programs that worked around the omission.
> Or do we? What code would break? How much pain would that cause?
> * anything else?
>
> > We have lots of forums, but your point is that certain sorts of
> discussions never get going with the right audience – you especially point
> to “confused beginners”.
> > ... It’s quite a challenge because beginners tend not to be vocal, and
> yet they are a crucial set of Haskell users. Every Haskell user started as
> a beginner.
>
> On this particular topic, there's plenty of confused people asking
> questions on StackOverflow. (Heads up: they're especially asking why they
> need explicit `forall` whereas in reguar Haskell that 'intermediates' see,
> the forall is implicit.)
>
> Can other people point me to questions/likes/dislikes on other forums?
> Reddit for example.
>
> If you've read this far, you now understand what we're trying to cover.
> It's going to be random/varied thoughts at first, then perhaps coalescing
> to an approach or two. At that point a formal proposal on github proper;
> and the random stuff might be interesting background but will essentially
> get archived/thrown away.
>
> I do agree with David's suggestion that github Issue tracker looks like a
> suitable solution. We can write formatted code and text. We can add links
> and references. What do others think? Joachim has opened up Issues tracker,
> as a try-out. If using it doesn't work out, that's fine and in keeping with
> my "thrown away" above.
>
> Also where else should I post links to this message to 'advertise' the
> thread? I don't reddit much, so if that's suitable, please someone post
> there.
>
> Thank you
> AntC
> ___
> 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

Re: Open up the issues tracker on ghc-proposals

[Anthony Clayden]

> 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* be going to
committee members, unless they deliberately opt in to some issue.

I don't get github traffic except for proposals I've opted in to; and I can
always 'mute the thread'. So specifically no traffic for the Issue David's
just raised [good]. I go and sweep github for interesting pickings every
now and then, and subscribe.

Looks like (from his puzzled reply) Simon did get traffic for that issue. I
dread to think what other github traffic Simon might have suffered recently.

Can a user configure to get proposal traffic but not Issue tracker traffic?
(There seem to be options for everything.) I suggest the committee members
do that.

AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Anthony Clayden]

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
github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
thread? (It'll get ignored.)

> ... 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 :)

Thanks Carter, but I understand Haskell Prime to be to assess mature/stable
proposals (preferably already delivered as extensions). This discussion is
at first going to be more exploratory:
* likes and dislikes about ScopedTypeVariables as currently.
* confusions experienced by users (especially newbies)
-- although absolute newbies wouldn't be using it(?), so intermediates?
* feedback from those teaching Haskell.
* wild ideas for possible alternative designs.
* possible improvements to the current design.
* I think we're all agreed that ScopedTypeVariables should have been in
Haskell from the beginning;
but it wasn't, so now we have to worry about backwards compatibility for
programs that worked around the omission.
Or do we? What code would break? How much pain would that cause?
* anything else?

> We have lots of forums, but your point is that certain sorts of
discussions never get going with the right audience – you especially point
to “confused beginners”.
> ... It’s quite a challenge because beginners tend not to be vocal, and
yet they are a crucial set of Haskell users. Every Haskell user started as
a beginner.

On this particular topic, there's plenty of confused people asking
questions on StackOverflow. (Heads up: they're especially asking why they
need explicit `forall` whereas in reguar Haskell that 'intermediates' see,
the forall is implicit.)

Can other people point me to questions/likes/dislikes on other forums?
Reddit for example.

If you've read this far, you now understand what we're trying to cover.
It's going to be random/varied thoughts at first, then perhaps coalescing
to an approach or two. At that point a formal proposal on github proper;
and the random stuff might be interesting background but will essentially
get archived/thrown away.

I do agree with David's suggestion that github Issue tracker looks like a
suitable solution. We can write formatted code and text. We can add links
and references. What do others think? Joachim has opened up Issues tracker,
as a try-out. If using it doesn't work out, that's fine and in keeping with
my "thrown away" above.

Also where else should I post links to this message to 'advertise' the
thread? I don't reddit much, so if that's suitable, please someone post
there.

Thank you
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Carter Schonwald]

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 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 together:
> there's now a long discussion on the committee mailing list about the
> specifics of #99. There are good questions, good answers, good ideas. None
> of the rest of use can contribute to that. The committee list is supposed
> to be low volume/decision making only. WTF?
>
> (That seems to be triggered by one particular committee member who
> seldom/never looks at github, and prefers email discussion. Yous others
> could perhaps coach him?)
>
> > hmm, some of that sounds like it would be better suited for haskell-cafe,
> StackOverflow, ...
>
> My point about "sometimes it's more of a niggle" was aimed at exactly your
> (Joachim's) series of proposals 'Resurrect Pattern Signatures'. The
> motivation is it helps "confused beginners". But those beginners won't be
> providing feedback on github. Instead you've got feedback from experienced
> users who've all said they see no point in the proposal. So the discussion
> has gone round and round and spun off other proposals. That whole series of
> discussions would be better happening somewhere else: where?
>
> David's quite correct
> >> Haskell-cafe might work, but it's a bit tricky to pull up all the
> language extension ideas discussed there.
>
> My impression is not many people who could help refine a pre-proposal ever
> take part in the cafe.
>
> Stackoverflow likewise. (I did raise a 'how do I do this?' type question
> there. It was David who responded, thank you. But I ended up answering it
> myself; and it turned out there was already a proposal on the slate.)
>
> >> My limited experience with glasgow-haskell-users is that it's where
> threads go to die.
>
> (I did try to continue one of David's threads there a few months ago.) But
> yes, my experience too. And that's sad because it's a wasted resource. I'm
> grateful to Simon for noticing this thread; but most topics I've raised on
> ghc-users have gone nowhere. So then I've tried pursuing them by poaching
> on Trac or github -- which is an abuse, I know.
>
> > Most vague ideas get better when the proposer is nudged to sit down and 
> > write
> it up properly! (And some get dropped in the process, which is also good
> :-)).
>
> Yes exactly what I'm trying to get to happen. How/where?
>
> Here's a specific example: there's talk of baking ScopedTypeVariables into
> the H2020 standard. There's also people unhappy with ScopedTypeVariables as
> currently (I'm one, but I don't know if my reservations are the same as
> others'). If we don't have an alternative proposal (and preferably an
> experimental extension) by 2020, the committee can only go with the as
> currently fait accompli or continue the H2010 status quo.
>
> I can volunteer to at least scrape together all the objections to
> ScopedTypeVariables as currently. It's not yet a proposal, so not on
> github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
> thread? (It'll get ignored.)
>
>
> AntC
>
>
> ___
> 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

RE: Open up the issues tracker on ghc-proposals

[Simon Peyton Jones via 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 github. 
Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll 
get ignored.)

That’s a fair question.  We have lots of forums, but your point is that certain 
sorts of discussions never get going with the right audience – you especially 
point to “confused beginners”.

I don’t know how to engage that audience effectively, and by definition I’m the 
wrong person even to have a well-informed view.   It’s quite a challenge 
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 
start would be to articulate the challenge directly, in a new thread, and 
invite input from others about whether it’s a problem they encounter, and what 
possible solutions might be?

Thanks!

Simon

From: Glasgow-haskell-users <glasgow-haskell-users-boun...@haskell.org> On 
Behalf Of Anthony Clayden
Sent: 03 May 2018 00:17
To: GHC users <glasgow-haskell-users@haskell.org>
Cc: Joachim Breitner <m...@joachim-breitner.de>
Subject: Re: Open up the issues tracker on ghc-proposals

On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote:
…

> hmm, some of that sounds like it would be better suited for haskell-cafe, 
> StackOverflow, ...

My point about "sometimes it's more of a niggle" was aimed at exactly your 
(Joachim's) series of proposals 'Resurrect Pattern Signatures'. The motivation 
is it helps "confused beginners". But those beginners won't be providing 
feedback on github. Instead you've got feedback from experienced users who've 
all said they see no point in the proposal. So the discussion has gone round 
and round and spun off other proposals. That whole series of discussions would 
be better happening somewhere else: where?

David's quite correct
>> Haskell-cafe might work, but it's a bit tricky to pull up all the language 
>> extension ideas discussed there.

My impression is not many people who could help refine a pre-proposal ever take 
part in the cafe.

Stackoverflow likewise. (I did raise a 'how do I do this?' type question there. 
It was David who responded, thank you. But I ended up answering it myself; and 
it turned out there was already a proposal on the slate.)

>> My limited experience with glasgow-haskell-users is that it's where threads 
>> go to die.

(I did try to continue one of David's threads there a few months ago.) But yes, 
my experience too. And that's sad because it's a wasted resource. I'm grateful 
to Simon for noticing this thread; but most topics I've raised on ghc-users 
have gone nowhere. So then I've tried pursuing them by poaching on Trac or 
github -- which is an abuse, I know.

> Most vague ideas get better when the proposer is nudged to sit down and write 
> it up properly! (And some get dropped in the process, which is also good :-)).

Yes exactly what I'm trying to get to happen. How/where?

Here's a specific example: there's talk of baking ScopedTypeVariables into the 
H2020 standard. There's also people unhappy with ScopedTypeVariables as 
currently (I'm one, but I don't know if my reservations are the same as 
others'). If we don't have an alternative proposal (and preferably an 
experimental extension) by 2020, the committee can only go with the as 
currently fait accompli or continue the H2010 status quo.

I can volunteer to at least scrape together all the objections to 
ScopedTypeVariables as currently. It's not yet a proposal, so not on github. 
Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll 
get ignored.)


AntC


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Open up the issues tracker on ghc-proposals

[Anthony Clayden]

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 together:
there's now a long discussion on the committee mailing list about the
specifics of #99. There are good questions, good answers, good ideas. None
of the rest of use can contribute to that. The committee list is supposed
to be low volume/decision making only. WTF?

(That seems to be triggered by one particular committee member who
seldom/never looks at github, and prefers email discussion. Yous others
could perhaps coach him?)

> hmm, some of that sounds like it would be better suited for haskell-cafe,
StackOverflow, ...

My point about "sometimes it's more of a niggle" was aimed at exactly your
(Joachim's) series of proposals 'Resurrect Pattern Signatures'. The
motivation is it helps "confused beginners". But those beginners won't be
providing feedback on github. Instead you've got feedback from experienced
users who've all said they see no point in the proposal. So the discussion
has gone round and round and spun off other proposals. That whole series of
discussions would be better happening somewhere else: where?

David's quite correct
>> Haskell-cafe might work, but it's a bit tricky to pull up all the
language extension ideas discussed there.

My impression is not many people who could help refine a pre-proposal ever
take part in the cafe.

Stackoverflow likewise. (I did raise a 'how do I do this?' type question
there. It was David who responded, thank you. But I ended up answering it
myself; and it turned out there was already a proposal on the slate.)

>> My limited experience with glasgow-haskell-users is that it's where
threads go to die.

(I did try to continue one of David's threads there a few months ago.) But
yes, my experience too. And that's sad because it's a wasted resource. I'm
grateful to Simon for noticing this thread; but most topics I've raised on
ghc-users have gone nowhere. So then I've tried pursuing them by poaching
on Trac or github -- which is an abuse, I know.

> Most vague ideas get better when the proposer is nudged to sit down and write
it up properly! (And some get dropped in the process, which is also good
:-)).

Yes exactly what I'm trying to get to happen. How/where?

Here's a specific example: there's talk of baking ScopedTypeVariables into
the H2020 standard. There's also people unhappy with ScopedTypeVariables as
currently (I'm one, but I don't know if my reservations are the same as
others'). If we don't have an alternative proposal (and preferably an
experimental extension) by 2020, the committee can only go with the as
currently fait accompli or continue the H2010 status quo.

I can volunteer to at least scrape together all the objections to
ScopedTypeVariables as currently. It's not yet a proposal, so not on
github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
thread? (It'll get ignored.)


AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Open up the issues tracker on ghc-proposals

[Joachim Breitner]

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 language;
> * maybe the proposer finds themself writing the same boilerplate
> repeatedly, and wonders if that's a common idiom the language could
> capture;
> * sometimes it starts as more of a 'how do I do this?' question; then
> you get told you can't; then other people chip in with 'yes I'd like
> to do that too'.
> * sometimes it's more of a niggle: this really annoys me/is
> awkward/is confusing every time I bump into it/even though I can work
> round it.


hmm, some of that sounds like it would be better suited for haskell-
cafe, StackOverflow, Reddit or your personal twitter feed, at least
until the idea has matured a little bit more. 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.

We can try, but I reserve the right to abondon the experiment if we end
up with a few unproductive long discussions around some obviously
whacky idea, and a larger number of vague abandoned “wouldn’t it be
nice” issues.

Most vague ideas get better when the proposer is nudged to sit down and
write it up properly! (And some get dropped in the process, which is
also good :-)).

Cheers,
Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Open up the issues tracker on ghc-proposals

[David Feuer]

My main motivation was that I had a vague idea, not remotely ready for a
proposal, and wanted a place to try hashing it out. My limited experience
with glasgow-haskell-users is that it's where threads go to die.
Haskell-cafe might work, but it's a bit tricky to pull up all the language
extension ideas discussed there. So I figured maybe the ghc-proposals issue
tracker would be the best way. Might be worth a try, anyway.

On Wed, May 2, 2018, 5:54 AM Anthony Clayden <anthony_clay...@clear.net.nz>
wrote:

>
> On Wed, 2 May 2018 at 8:28 PM, Simon Peyton Jones <redir...@vodafone.co.nz>
> 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.
>>
>
> (I meant for David to post more widely the idea of using Github issues
> tracker. Because I suspect the people who would most benefit from the
> 'community discussion' are not participants on ghc-devs.)
>
>
>> The Right Thing is surely for the main GHC proposals pav[g]e
>> https://github.com/ghc-proposals/ghc-proposals
>> to describe how you can up a "pre-proposal".  That is, document
>> the entire process in one, easy to find, place.
>>
>> Mind you, I'm unclear about the distinction between a pre-proposal
>> and a proposal. ...
>
>
> Thanks Simon,
>
> 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 language;
> * maybe the proposer finds themself writing the same boilerplate
> repeatedly, and wonders if that's a common idiom the language could capture;
> * sometimes it starts as more of a 'how do I do this?' question; then you
> get told you can't; then other people chip in with 'yes I'd like to do that
> too'.
> * sometimes it's more of a niggle: this really annoys me/is awkward/is
> confusing every time I bump into it/even though I can work round it.
>
>
>  Both are drafts that invite community discussion,
>> prior to submitting to the committee for decision.
>>
>
> I'm guessing as to why David raised the question. I've noticed (a minority
> of) proposals generate a huge amount of discussion, a lot of which is: you
> can already do that, or nearly all of that, or there's good reasons why
> ghc/Haskell shouldn't do that. Then maybe the difficulty that needs
> tackling is that the submitter isn't really following the process/perhaps
> the process document should be clearer about what threshold of readiness
> the ideas should be in before formalising(?) I'll try to avoid specifics
> here, but two proposals I can think of essentially amounted to: Language
> XXX has YYY; language XXX is similar to Haskell; I think YYY is great;
> please put YYY in Haskell; P.S. I don't really understand ghc and all the
> extensions it now offers.
>
> As you've remarked yourself, sometimes the 'community discussion' gets so
> convoluted and sidetracked it's impossible to make out where the proposal
> is at, and whether all objections have been addressed. That's the point at
> which IMO the proposal 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.
> _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-
>> |  From: Glasgow-haskell-users > |  boun...@haskell.org> 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 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
>> |  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 datapoint, I found ghc-users and the café just fine for those
>> |  discussions.
>> |  Ghc-users seems to have very low traffic/is rather wasted currently.
>> |  And I believe a lot of people pre-discuss on reddit.
>> | 

Re: Open up the issues tracker on ghc-proposals

[Anthony Clayden]

On Wed, 2 May 2018 at 8:28 PM, Simon Peyton Jones <redir...@vodafone.co.nz>
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.
>

(I meant for David to post more widely the idea of using Github issues
tracker. Because I suspect the people who would most benefit from the
'community discussion' are not participants on ghc-devs.)


> The Right Thing is surely for the main GHC proposals pav[g]e
> https://github.com/ghc-proposals/ghc-proposals
> to describe how you can up a "pre-proposal".  That is, document
> the entire process in one, easy to find, place.
>
> Mind you, I'm unclear about the distinction between a pre-proposal
> and a proposal. ...


Thanks Simon,

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 language;
* maybe the proposer finds themself writing the same boilerplate
repeatedly, and wonders if that's a common idiom the language could capture;
* sometimes it starts as more of a 'how do I do this?' question; then you
get told you can't; then other people chip in with 'yes I'd like to do that
too'.
* sometimes it's more of a niggle: this really annoys me/is awkward/is
confusing every time I bump into it/even though I can work round it.


 Both are drafts that invite community discussion,
> prior to submitting to the committee for decision.
>

I'm guessing as to why David raised the question. I've noticed (a minority
of) proposals generate a huge amount of discussion, a lot of which is: you
can already do that, or nearly all of that, or there's good reasons why
ghc/Haskell shouldn't do that. Then maybe the difficulty that needs
tackling is that the submitter isn't really following the process/perhaps
the process document should be clearer about what threshold of readiness
the ideas should be in before formalising(?) I'll try to avoid specifics
here, but two proposals I can think of essentially amounted to: Language
XXX has YYY; language XXX is similar to Haskell; I think YYY is great;
please put YYY in Haskell; P.S. I don't really understand ghc and all the
extensions it now offers.

As you've remarked yourself, sometimes the 'community discussion' gets so
convoluted and sidetracked it's impossible to make out where the proposal
is at, and whether all objections have been addressed. That's the point at
which IMO the proposal 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.
_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-
> |  From: Glasgow-haskell-users  |  boun...@haskell.org> 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 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
> |  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 datapoint, I found ghc-users and the café just fine for those
> |  discussions.
> |  Ghc-users seems to have very low traffic/is rather wasted currently.
> |  And I believe a lot of people pre-discuss on reddit.
> |  For ideas that have been on the back burner for a long time, there's
> |  often wiki pages. (For example re Quantified
> |  Constraints.)
> |
> |  > I'd like to propose that we open up the GitHub issues
> |  tracker for ghc-proposals to serve as a place to discuss pre-proposal
> |  ideas. Once those discussions converge on one or a few specific plans,
> |  someone can write a proper proposal.
> |
> |  I'm not against that. There gets to be a lot of cruft on some
> |  discussions about proposals, so I'd expect we could archive it all
> |  once a proposal is more formalised.
> |
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: Open up the issues tracker on ghc-proposals

[Simon Peyton Jones via Glasgow-haskell-users]

|  > 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.

The Right Thing is surely for the main GHC proposals pave
https://github.com/ghc-proposals/ghc-proposals
to describe how you can up a "pre-proposal".  That is, document
the entire process in one, easy to find, place.

Mind you, I'm unclear about the distinction between a pre-proposal
and a proposal.  Both 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: 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 datapoint, I found ghc-users and the café just fine for those
|  discussions.
|  Ghc-users seems to have very low traffic/is rather wasted currently.
|  And I believe a lot of people pre-discuss on reddit.
|  For ideas that have been on the back burner for a long time, there's
|  often wiki pages. (For example re Quantified
|  Constraints.)
|  
|  > I'd like to propose that we open up the GitHub issues
|  tracker for ghc-proposals to serve as a place to discuss pre-proposal
|  ideas. Once those discussions converge on one or a few specific plans,
|  someone can write a proper proposal.
|  
|  I'm not against that. There gets to be a lot of cruft on some
|  discussions about proposals, so I'd expect we could archive it all
|  once a proposal is more formalised.
|  
|  AntC
|  
|  ___
|  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

Re: Open up the issues tracker on ghc-proposals

[Anthony Clayden]

> 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 datapoint, I found ghc-users and the café just fine
for those discussions. 
Ghc-users seems to have very low traffic/is rather wasted
currently.
And I believe a lot of people pre-discuss on reddit. 
For ideas that have been on the back burner for a long time,
there's often wiki pages. (For example re Quantified
Constraints.)

> I'd like to propose that we open up the GitHub issues
tracker for ghc-proposals to serve as a place to discuss
pre-proposal ideas. Once those discussions converge on one
or a few specific plans, someone can write a proper
proposal.

I'm not against that. There gets to be a lot of cruft on
some discussions about proposals, so I'd expect we could
archive it all once a proposal is more formalised.

AntC

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users