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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

AntC
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

AntC

On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <[hidden email]> 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 <[hidden email]> wrote:
On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <[hidden email]> 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 <[hidden email]> wrote:
On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> wrote:
On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <[hidden email]> 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 <[hidden email]> wrote:
On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users