From juhpetersen at gmail.com Tue May 1 06:48:21 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 1 May 2018 15:48:21 +0900 Subject: [ANNOUNCE] GHC 8.4.2 released In-Reply-To: <87in8md9v9.fsf@smart-cactus.org> References: <87in8md9v9.fsf@smart-cactus.org> Message-ID: I have built ghc-8.4.2 for Fedora and EPEL7 in https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.2/ Thanks, Jens From anthony_clayden at clear.net.nz Wed May 2 01:33:44 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 02 May 2018 13:33:44 +1200 Subject: Open up the issues tracker on ghc-proposals Message-ID: <5ae91578.299.6bed.19608@clear.net.nz> > 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 From simonpj at microsoft.com Wed May 2 08:12:41 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 2 May 2018 08:12:41 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: <5ae91578.299.6bed.19608@clear.net.nz> References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: | > 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 at haskell.org; ghc-devs at 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 at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From anthony_clayden at clear.net.nz Wed May 2 09:53:38 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 02 May 2018 09:53:38 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: On Wed, 2 May 2018 at 8:28 PM, Simon Peyton Jones 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 | bounces at haskell.org> On Behalf Of Anthony Clayden > | Sent: 02 May 2018 02:34 > | To: glasgow-haskell-users at haskell.org; ghc-devs at 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. > | > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed May 2 13:23:03 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 02 May 2018 13:23:03 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: 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 wrote: > > On Wed, 2 May 2018 at 8:28 PM, Simon Peyton Jones > 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 > | bounces at haskell.org> On Behalf Of Anthony Clayden >> | Sent: 02 May 2018 02:34 >> | To: glasgow-haskell-users at haskell.org; ghc-devs at 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed May 2 13:53:44 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 02 May 2018 09:53:44 -0400 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: <3c23db55dcf82c0255bd91b93995c47f8be2c1b4.camel@joachim-breitner.de> Hi, Am Mittwoch, den 02.05.2018, 09:53 +0000 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 mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From anthony_clayden at clear.net.nz Wed May 2 23:17:18 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 02 May 2018 23:17:18 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 3 07:45:18 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 3 May 2018 07:45:18 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: 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 On Behalf Of Anthony Clayden Sent: 03 May 2018 00:17 To: GHC users Cc: Joachim Breitner 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu May 3 12:44:08 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 03 May 2018 12:44:08 +0000 Subject: Scoped type variables Re: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sat May 5 02:34:38 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 05 May 2018 02:34:38 +0000 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sat May 5 06:42:36 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 05 May 2018 06:42:36 +0000 Subject: Open up the issues tracker on ghc-proposals In-Reply-To: References: <5ae91578.299.6bed.19608@clear.net.nz> Message-ID: > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheater00 at gmail.com Wed May 9 03:01:59 2018 From: cheater00 at gmail.com (cheater00 cheater00) Date: Wed, 09 May 2018 03:01:59 +0000 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat May 12 20:41:29 2018 From: gershomb at gmail.com (Gershom B) Date: Sat, 12 May 2018 16:41:29 -0400 Subject: PSA for Cabal 2.2 new-* users regarding .ghc.environment files Message-ID: There is an important change in the cabal new- commands for 2.2 that the release docs should have highlighted more significantly. Cabal new-* commands now produce a .ghc.environment file by default. These files [1] are picked up by ghc and ghci automatically (since 8.0.1), and allow them to operate directly with the same package environment used by the new-* commands. This lets you, for example, run `ghci` in a project where you are using `new-build` and get the proper dependencies in scope. Herbert has written an experimental tool to make it easier to create and manipulate these environments [2]. However: there is a drawback (on which some discussion at [3] and [4]. In particular, there is not good information provided by ghc about when these files are picked up and used. So if you are admixing new-* commands and other commands for the time being, jumping between the two, or admixing ghc and ghcjs, etc., then you may run into unexpected behavior! [5] The simplest solution for now is to delete the local .ghc.environment file in those cases (i.e. where you're mixing commands and get unexpected behavior). A particular gotcha is that these files are picked up not just in the current directory but also in any parent directory. Cheers, Gershom [1] documented at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-environments [2] https://github.com/hvr/cabal-env [3] https://github.com/haskell/cabal/issues/4542 [4] https://ghc.haskell.org/trac/ghc/ticket/13753 [5] Error messages may be like ".cabal/store/ghc-8.0.2/package.db/package.cache: openBinaryFile: does not exist (No such file or directory)" or complaints about missing inplace dependencies. From hvriedel at gmail.com Sat May 12 22:10:56 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 13 May 2018 00:10:56 +0200 Subject: PSA for Cabal 2.2 new-* users regarding .ghc.environment files In-Reply-To: References: Message-ID: On Sat, May 12, 2018 at 10:41 PM, Gershom B wrote: > In particular, there is not good information provided by ghc about > when these files are picked up and used. Fwiw, there's already an overdue patch up for that at https://phabricator.haskell.org/D4689 If there's enough demand, this could in theory even make it into a future GHC 8.4.3 From carter.schonwald at gmail.com Sun May 13 23:39:47 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 13 May 2018 19:39:47 -0400 Subject: PSA for Cabal 2.2 new-* users regarding .ghc.environment files In-Reply-To: References: Message-ID: Seems like that’d be a worthwhile cleanup / fix up release so this can be more visible / less silent. :) On Sat, May 12, 2018 at 6:11 PM Herbert Valerio Riedel wrote: > On Sat, May 12, 2018 at 10:41 PM, Gershom B wrote: > > In particular, there is not good information provided by ghc about > > when these files are picked up and used. > > Fwiw, there's already an overdue patch up for that at > https://phabricator.haskell.org/D4689 > > If there's enough demand, this could in theory even make it into a > future GHC 8.4.3 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sat May 19 11:32:51 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 19 May 2018 23:32:51 +1200 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat May 19 18:56:40 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 19 May 2018 14:56:40 -0400 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden < anthony_clayden at 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 allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun May 20 23:22:32 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 20 May 2018 19:22:32 -0400 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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_clayden at 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 > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon May 21 00:03:12 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 21 May 2018 12:03:12 +1200 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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_clayden at 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 >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon May 21 00:21:49 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 20 May 2018 20:21:49 -0400 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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_clayden at 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_clayden at 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 >>> allbery.b at gmail.com >>> ballbery at sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >>> >> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon May 21 00:22:26 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 20 May 2018 20:22:26 -0400 Subject: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals] In-Reply-To: References: Message-ID: 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_clayden at clear.net.nz> wrote: > >> On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald < >> redirect at 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_clayden at 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 >>>> allbery.b at gmail.com >>>> ballbery at sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed May 23 23:38:47 2018 From: conal at conal.net (Conal Elliott) Date: Wed, 23 May 2018 16:38:47 -0700 Subject: Natural number comparisons with evidence Message-ID: When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > data CompareEv u v > = (u < v) => CompareLT > | (u ~ v) => CompareEQ > | (u > v) => CompareGT Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v With `compareEv`, we can bring evidence into scope in `case` expressions. I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > LT -> CompareLT > EQ -> CompareEQ > GT -> CompareGT Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu May 24 00:44:54 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 23 May 2018 20:44:54 -0400 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: I think the usual approach for defining these sorts of primitive operations is to use unsafeCoerce. On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: > When programming with GHC's type-level natural numbers and `KnownNat` > constraints, how can one construct *evidence* of the result of comparisons > to be used in further computations? For instance, we might define a type > for augmenting the results of `compare` with evidence: > > > data CompareEv u v > > = (u < v) => CompareLT > > | (u ~ v) => CompareEQ > > | (u > v) => CompareGT > > Then I'd like to define a comparison operation (to be used with > `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy > arguments): > > > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v > > With `compareEv`, we can bring evidence into scope in `case` expressions. > > I don't know how to implement `compareEv`. The following attempt fails to > type-check, since `compare` doesn't produce evidence (which is the > motivation for `compareEv` over `compare`): > > > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > > LT -> CompareLT > > EQ -> CompareEQ > > GT -> CompareGT > > Can `compareEv` be implemented in GHC Haskell? Is there already an > implementation of something similar? Any other advice? > > Thanks, -- Conal > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu May 24 17:03:17 2018 From: conal at conal.net (Conal Elliott) Date: Thu, 24 May 2018 10:03:17 -0700 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: Thanks for this suggestion, David. It seems to work out well, though I haven't tried running yet. > unsafeDict :: Dict c > unsafeDict = unsafeCoerce (Dict @ ()) > > unsafeSatisfy :: forall c a. (c => a) -> a > unsafeSatisfy z | Dict <- unsafeDict @ c = z Now we can define `compareEv`: > compareEv :: forall u v. KnownNat2 u v => CompareEv u v > compareEv = case natValAt @ u `compare` natValAt @ v of > LT -> unsafeSatisfy @ (u < v) CompareLT > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ > GT -> unsafeSatisfy @ (u > v) CompareGT If anyone has other techniques to suggest, I'd love to hear. -- Conal On Wed, May 23, 2018 at 5:44 PM, David Feuer wrote: > I think the usual approach for defining these sorts of primitive > operations is to use unsafeCoerce. > > On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: > >> When programming with GHC's type-level natural numbers and `KnownNat` >> constraints, how can one construct *evidence* of the result of comparisons >> to be used in further computations? For instance, we might define a type >> for augmenting the results of `compare` with evidence: >> >> > data CompareEv u v >> > = (u < v) => CompareLT >> > | (u ~ v) => CompareEQ >> > | (u > v) => CompareGT >> >> Then I'd like to define a comparison operation (to be used with >> `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy >> arguments): >> >> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >> >> With `compareEv`, we can bring evidence into scope in `case` expressions. >> >> I don't know how to implement `compareEv`. The following attempt fails to >> type-check, since `compare` doesn't produce evidence (which is the >> motivation for `compareEv` over `compare`): >> >> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >> > LT -> CompareLT >> > EQ -> CompareEQ >> > GT -> CompareGT >> >> Can `compareEv` be implemented in GHC Haskell? Is there already an >> implementation of something similar? Any other advice? >> >> Thanks, -- Conal >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu May 24 17:10:54 2018 From: conal at conal.net (Conal Elliott) Date: Thu, 24 May 2018 10:10:54 -0700 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: where `Dict` is from Ed Kmett's constraints library ( https://hackage.haskell.org/package/constraints). On Thu, May 24, 2018 at 10:03 AM, Conal Elliott wrote: > Thanks for this suggestion, David. It seems to work out well, though I > haven't tried running yet. > > > unsafeDict :: Dict c > > unsafeDict = unsafeCoerce (Dict @ ()) > > > > unsafeSatisfy :: forall c a. (c => a) -> a > > unsafeSatisfy z | Dict <- unsafeDict @ c = z > > Now we can define `compareEv`: > > > compareEv :: forall u v. KnownNat2 u v => CompareEv u v > > compareEv = case natValAt @ u `compare` natValAt @ v of > > LT -> unsafeSatisfy @ (u < v) CompareLT > > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ > > GT -> unsafeSatisfy @ (u > v) CompareGT > > If anyone has other techniques to suggest, I'd love to hear. > > -- Conal > > > On Wed, May 23, 2018 at 5:44 PM, David Feuer > wrote: > >> I think the usual approach for defining these sorts of primitive >> operations is to use unsafeCoerce. >> >> On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: >> >>> When programming with GHC's type-level natural numbers and `KnownNat` >>> constraints, how can one construct *evidence* of the result of comparisons >>> to be used in further computations? For instance, we might define a type >>> for augmenting the results of `compare` with evidence: >>> >>> > data CompareEv u v >>> > = (u < v) => CompareLT >>> > | (u ~ v) => CompareEQ >>> > | (u > v) => CompareGT >>> >>> Then I'd like to define a comparison operation (to be used with >>> `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy >>> arguments): >>> >>> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >>> >>> With `compareEv`, we can bring evidence into scope in `case` expressions. >>> >>> I don't know how to implement `compareEv`. The following attempt fails >>> to type-check, since `compare` doesn't produce evidence (which is the >>> motivation for `compareEv` over `compare`): >>> >>> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >>> > LT -> CompareLT >>> > EQ -> CompareEQ >>> > GT -> CompareGT >>> >>> Can `compareEv` be implemented in GHC Haskell? Is there already an >>> implementation of something similar? Any other advice? >>> >>> Thanks, -- Conal >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu May 24 17:43:31 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 24 May 2018 13:43:31 -0400 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: On Thu, May 24, 2018, 1:03 PM Conal Elliott wrote: > Thanks for this suggestion, David. It seems to work out well, though I > haven't tried running yet. > > > unsafeDict :: Dict c > > unsafeDict = unsafeCoerce (Dict @ ()) > > > > unsafeSatisfy :: forall c a. (c => a) -> a > > unsafeSatisfy z | Dict <- unsafeDict @ c = z > This doesn't really smell right to me, no. Dict @() is actually a rather different value than you seek. In general, these look like they do way more than they ever can. I would suggest you look through those comparison *constraints* to the underlying type equalities involving the primitive CmpNat type family. -- Better, because there's only one Refl unsafeEqual :: forall a b. a :~: b unsafeEqual :: unsafeCoerce Refl unsafeWithEqual :: forall a b r. (a ~ b => r) -> r unsafeWithEqual r | Refl <- unsafeEqual @a @b = r compareEv = case .... of LT -> unsafeWithEqual @(CmpNat u v) @LT CompareLT ... > Now we can define `compareEv`: > > > compareEv :: forall u v. KnownNat2 u v => CompareEv u v > > compareEv = case natValAt @ u `compare` natValAt @ v of > > LT -> unsafeSatisfy @ (u < v) CompareLT > > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ > > GT -> unsafeSatisfy @ (u > v) CompareGT > > If anyone has other techniques to suggest, I'd love to hear. > > -- Conal > > > On Wed, May 23, 2018 at 5:44 PM, David Feuer > wrote: > >> I think the usual approach for defining these sorts of primitive >> operations is to use unsafeCoerce. >> >> On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: >> >>> When programming with GHC's type-level natural numbers and `KnownNat` >>> constraints, how can one construct *evidence* of the result of comparisons >>> to be used in further computations? For instance, we might define a type >>> for augmenting the results of `compare` with evidence: >>> >>> > data CompareEv u v >>> > = (u < v) => CompareLT >>> > | (u ~ v) => CompareEQ >>> > | (u > v) => CompareGT >>> >>> Then I'd like to define a comparison operation (to be used with >>> `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy >>> arguments): >>> >>> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >>> >>> With `compareEv`, we can bring evidence into scope in `case` expressions. >>> >>> I don't know how to implement `compareEv`. The following attempt fails >>> to type-check, since `compare` doesn't produce evidence (which is the >>> motivation for `compareEv` over `compare`): >>> >>> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >>> > LT -> CompareLT >>> > EQ -> CompareEQ >>> > GT -> CompareGT >>> >>> Can `compareEv` be implemented in GHC Haskell? Is there already an >>> implementation of something similar? Any other advice? >>> >>> Thanks, -- Conal >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu May 24 19:54:58 2018 From: conal at conal.net (Conal Elliott) Date: Thu, 24 May 2018 12:54:58 -0700 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: Great! Thanks for the suggestion to use type equality and coerced `Refl`. - Conal On Thu, May 24, 2018 at 10:43 AM, David Feuer wrote: > On Thu, May 24, 2018, 1:03 PM Conal Elliott wrote: > >> Thanks for this suggestion, David. It seems to work out well, though I >> haven't tried running yet. >> >> > unsafeDict :: Dict c >> > unsafeDict = unsafeCoerce (Dict @ ()) >> > >> > unsafeSatisfy :: forall c a. (c => a) -> a >> > unsafeSatisfy z | Dict <- unsafeDict @ c = z >> > > This doesn't really smell right to me, no. Dict @() is actually a rather > different value than you seek. In general, these look like they do way more > than they ever can. I would suggest you look through those comparison > *constraints* to the underlying type equalities involving the primitive > CmpNat type family. > > -- Better, because there's only one Refl > unsafeEqual :: forall a b. a :~: b > unsafeEqual :: unsafeCoerce Refl > > unsafeWithEqual :: forall a b r. (a ~ b => r) -> r > unsafeWithEqual r > | Refl <- unsafeEqual @a @b = r > > compareEv = case .... of > LT -> unsafeWithEqual @(CmpNat u v) @LT CompareLT > ... > > >> Now we can define `compareEv`: >> >> > compareEv :: forall u v. KnownNat2 u v => CompareEv u v >> > compareEv = case natValAt @ u `compare` natValAt @ v of >> > LT -> unsafeSatisfy @ (u < v) CompareLT >> > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ >> > GT -> unsafeSatisfy @ (u > v) CompareGT >> >> If anyone has other techniques to suggest, I'd love to hear. >> >> -- Conal >> >> >> On Wed, May 23, 2018 at 5:44 PM, David Feuer >> wrote: >> >>> I think the usual approach for defining these sorts of primitive >>> operations is to use unsafeCoerce. >>> >>> On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: >>> >>>> When programming with GHC's type-level natural numbers and `KnownNat` >>>> constraints, how can one construct *evidence* of the result of comparisons >>>> to be used in further computations? For instance, we might define a type >>>> for augmenting the results of `compare` with evidence: >>>> >>>> > data CompareEv u v >>>> > = (u < v) => CompareLT >>>> > | (u ~ v) => CompareEQ >>>> > | (u > v) => CompareGT >>>> >>>> Then I'd like to define a comparison operation (to be used with >>>> `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy >>>> arguments): >>>> >>>> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >>>> >>>> With `compareEv`, we can bring evidence into scope in `case` >>>> expressions. >>>> >>>> I don't know how to implement `compareEv`. The following attempt fails >>>> to type-check, since `compare` doesn't produce evidence (which is the >>>> motivation for `compareEv` over `compare`): >>>> >>>> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >>>> > LT -> CompareLT >>>> > EQ -> CompareEQ >>>> > GT -> CompareGT >>>> >>>> Can `compareEv` be implemented in GHC Haskell? Is there already an >>>> implementation of something similar? Any other advice? >>>> >>>> Thanks, -- Conal >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Thu May 24 20:05:32 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 24 May 2018 16:05:32 -0400 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: <7A3EE93E-BA30-47E9-B130-2371768A50E3@cs.brynmawr.edu> Just to add my 2 cents: I've played in this playground and used the same structures as David. I second his suggestions. Richard > On May 24, 2018, at 3:54 PM, Conal Elliott wrote: > > Great! Thanks for the suggestion to use type equality and coerced `Refl`. - Conal > > On Thu, May 24, 2018 at 10:43 AM, David Feuer > wrote: > On Thu, May 24, 2018, 1:03 PM Conal Elliott > wrote: > Thanks for this suggestion, David. It seems to work out well, though I haven't tried running yet. > > > unsafeDict :: Dict c > > unsafeDict = unsafeCoerce (Dict @ ()) > > > > unsafeSatisfy :: forall c a. (c => a) -> a > > unsafeSatisfy z | Dict <- unsafeDict @ c = z > > This doesn't really smell right to me, no. Dict @() is actually a rather different value than you seek. In general, these look like they do way more than they ever can. I would suggest you look through those comparison *constraints* to the underlying type equalities involving the primitive CmpNat type family. > > -- Better, because there's only one Refl > unsafeEqual :: forall a b. a :~: b > unsafeEqual :: unsafeCoerce Refl > > unsafeWithEqual :: forall a b r. (a ~ b => r) -> r > unsafeWithEqual r > | Refl <- unsafeEqual @a @b = r > > compareEv = case .... of > LT -> unsafeWithEqual @(CmpNat u v) @LT CompareLT > ... > > > Now we can define `compareEv`: > > > compareEv :: forall u v. KnownNat2 u v => CompareEv u v > > compareEv = case natValAt @ u `compare` natValAt @ v of > > LT -> unsafeSatisfy @ (u < v) CompareLT > > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ > > GT -> unsafeSatisfy @ (u > v) CompareGT > > If anyone has other techniques to suggest, I'd love to hear. > > -- Conal > > > On Wed, May 23, 2018 at 5:44 PM, David Feuer > wrote: > I think the usual approach for defining these sorts of primitive operations is to use unsafeCoerce. > > On Wed, May 23, 2018, 7:39 PM Conal Elliott > wrote: > When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > > > data CompareEv u v > > = (u < v) => CompareLT > > | (u ~ v) => CompareEQ > > | (u > v) => CompareGT > > Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > > > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v > > With `compareEv`, we can bring evidence into scope in `case` expressions. > > I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > > > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > > LT -> CompareLT > > EQ -> CompareEQ > > GT -> CompareGT > > Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? > > Thanks, -- Conal > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu May 24 20:07:36 2018 From: conal at conal.net (Conal Elliott) Date: Thu, 24 May 2018 13:07:36 -0700 Subject: Natural number comparisons with evidence In-Reply-To: <7A3EE93E-BA30-47E9-B130-2371768A50E3@cs.brynmawr.edu> References: <7A3EE93E-BA30-47E9-B130-2371768A50E3@cs.brynmawr.edu> Message-ID: I'm glad to know. Thanks for the endorsement, Richard. On Thu, May 24, 2018 at 1:05 PM, Richard Eisenberg wrote: > Just to add my 2 cents: I've played in this playground and used the same > structures as David. I second his suggestions. > > Richard > > > On May 24, 2018, at 3:54 PM, Conal Elliott wrote: > > Great! Thanks for the suggestion to use type equality and coerced `Refl`. > - Conal > > On Thu, May 24, 2018 at 10:43 AM, David Feuer > wrote: > >> On Thu, May 24, 2018, 1:03 PM Conal Elliott wrote: >> >>> Thanks for this suggestion, David. It seems to work out well, though I >>> haven't tried running yet. >>> >>> > unsafeDict :: Dict c >>> > unsafeDict = unsafeCoerce (Dict @ ()) >>> > >>> > unsafeSatisfy :: forall c a. (c => a) -> a >>> > unsafeSatisfy z | Dict <- unsafeDict @ c = z >>> >> >> This doesn't really smell right to me, no. Dict @() is actually a rather >> different value than you seek. In general, these look like they do way more >> than they ever can. I would suggest you look through those comparison >> *constraints* to the underlying type equalities involving the primitive >> CmpNat type family. >> >> -- Better, because there's only one Refl >> unsafeEqual :: forall a b. a :~: b >> unsafeEqual :: unsafeCoerce Refl >> >> unsafeWithEqual :: forall a b r. (a ~ b => r) -> r >> unsafeWithEqual r >> | Refl <- unsafeEqual @a @b = r >> >> compareEv = case .... of >> LT -> unsafeWithEqual @(CmpNat u v) @LT CompareLT >> ... >> >> >>> Now we can define `compareEv`: >>> >>> > compareEv :: forall u v. KnownNat2 u v => CompareEv u v >>> > compareEv = case natValAt @ u `compare` natValAt @ v of >>> > LT -> unsafeSatisfy @ (u < v) CompareLT >>> > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ >>> > GT -> unsafeSatisfy @ (u > v) CompareGT >>> >>> If anyone has other techniques to suggest, I'd love to hear. >>> >>> -- Conal >>> >>> >>> On Wed, May 23, 2018 at 5:44 PM, David Feuer >>> wrote: >>> >>>> I think the usual approach for defining these sorts of primitive >>>> operations is to use unsafeCoerce. >>>> >>>> On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: >>>> >>>>> When programming with GHC's type-level natural numbers and `KnownNat` >>>>> constraints, how can one construct *evidence* of the result of comparisons >>>>> to be used in further computations? For instance, we might define a type >>>>> for augmenting the results of `compare` with evidence: >>>>> >>>>> > data CompareEv u v >>>>> > = (u < v) => CompareLT >>>>> > | (u ~ v) => CompareEQ >>>>> > | (u > v) => CompareGT >>>>> >>>>> Then I'd like to define a comparison operation (to be used with >>>>> `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy >>>>> arguments): >>>>> >>>>> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >>>>> >>>>> With `compareEv`, we can bring evidence into scope in `case` >>>>> expressions. >>>>> >>>>> I don't know how to implement `compareEv`. The following attempt fails >>>>> to type-check, since `compare` doesn't produce evidence (which is the >>>>> motivation for `compareEv` over `compare`): >>>>> >>>>> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >>>>> > LT -> CompareLT >>>>> > EQ -> CompareEQ >>>>> > GT -> CompareGT >>>>> >>>>> Can `compareEv` be implemented in GHC Haskell? Is there already an >>>>> implementation of something similar? Any other advice? >>>>> >>>>> Thanks, -- Conal >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 24 21:30:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 May 2018 21:30:47 +0000 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: I see this in GHC.TypeNats sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b) sameNat x y | natVal x == natVal y = Just (unsafeCoerce Refl) | otherwise = Nothing The unsafeCoerce says that sameNat is part of the trusted code base. And indeed, it’s only because SNat is a private newtype (i.e its data constructor is private to GHC.TypeNats) that you can’t bogusly say (SNat 7 :: SNat 8) You want exactly the same thing, but for a comparison oriented data CompareEv, rather than its equality counterpart :~:. So the same approach seems legitimate. I always want code with unsafeCoerce to be clear about (a) why it’s necessary and (b) why it’s sound. Simon From: Glasgow-haskell-users On Behalf Of Conal Elliott Sent: 24 May 2018 00:39 To: glasgow-haskell-users at haskell.org Subject: Natural number comparisons with evidence When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > data CompareEv u v > = (u < v) => CompareLT > | (u ~ v) => CompareEQ > | (u > v) => CompareGT Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v With `compareEv`, we can bring evidence into scope in `case` expressions. I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > LT -> CompareLT > EQ -> CompareEQ > GT -> CompareGT Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu May 24 22:53:34 2018 From: conal at conal.net (Conal Elliott) Date: Thu, 24 May 2018 15:53:34 -0700 Subject: Natural number comparisons with evidence In-Reply-To: References: Message-ID: Oh, yes---`sameNat` is indeed quite similar to my `compareEv`. I hadn't noticed. Thanks, Simon. On Thu, May 24, 2018 at 2:30 PM, Simon Peyton Jones wrote: > I see this in GHC.TypeNats > > *sameNat ::* *(KnownNat a, KnownNat b) =>* > > * Proxy a -> Proxy b -> Maybe (a :~: b)* > > *sameNat x y* > > * | natVal x == natVal y = Just (unsafeCoerce Refl)* > > * | otherwise = Nothing* > > > > The unsafeCoerce says that sameNat is part of the trusted code base. And > indeed, it’s only because SNat is a private newtype (i.e its data > constructor is private to GHC.TypeNats) that you can’t bogusly say (SNat > 7 :: SNat 8) > > > > You want exactly the same thing, but for a comparison oriented data > CompareEv, rather than its equality counterpart :~:. So the same approach > seems legitimate. > > > > I always want code with unsafeCoerce to be clear about (a) why it’s > necessary and (b) why it’s sound. > > > > Simon > > > > > > *From:* Glasgow-haskell-users *On > Behalf Of *Conal Elliott > *Sent:* 24 May 2018 00:39 > *To:* glasgow-haskell-users at haskell.org > *Subject:* Natural number comparisons with evidence > > > > When programming with GHC's type-level natural numbers and `KnownNat` > constraints, how can one construct *evidence* of the result of comparisons > to be used in further computations? For instance, we might define a type > for augmenting the results of `compare` with evidence: > > > > > data CompareEv u v > > > = (u < v) => CompareLT > > > | (u ~ v) => CompareEQ > > > | (u > v) => CompareGT > > > > Then I'd like to define a comparison operation (to be used with > `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy > arguments): > > > > > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v > > > > With `compareEv`, we can bring evidence into scope in `case` expressions. > > > > I don't know how to implement `compareEv`. The following attempt fails to > type-check, since `compare` doesn't produce evidence (which is the > motivation for `compareEv` over `compare`): > > > > > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > > > LT -> CompareLT > > > EQ -> CompareEQ > > > GT -> CompareGT > > > > Can `compareEv` be implemented in GHC Haskell? Is there already an > implementation of something similar? Any other advice? > > > > Thanks, -- Conal > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrix at galois.com Thu May 24 23:26:00 2018 From: jhendrix at galois.com (Joe Hendrix) Date: Thu, 24 May 2018 16:26:00 -0700 Subject: Natural number comparisons with evidence In-Reply-To: References: <7A3EE93E-BA30-47E9-B130-2371768A50E3@cs.brynmawr.edu> Message-ID: To throw out additional related work, I had a need for runtime values that capture type-level naturals. It’s used primarily for representing the widths in a type-safe bitvector formulas. The code is a few years old, but publicly available here: https://github.com/GaloisInc/parameterized-utils/blob/master/src/Data/Parameterized/NatRepr.hs I’d be interested in knowing if there are now any comprehensive libraries for doing this sort of runtime reflection of type-level naturals. Regards, Joe > On May 24, 2018, at 1:07 PM, Conal Elliott wrote: > > I'm glad to know. Thanks for the endorsement, Richard. > > On Thu, May 24, 2018 at 1:05 PM, Richard Eisenberg wrote: > Just to add my 2 cents: I've played in this playground and used the same structures as David. I second his suggestions. > > Richard > > >> On May 24, 2018, at 3:54 PM, Conal Elliott wrote: >> >> Great! Thanks for the suggestion to use type equality and coerced `Refl`. - Conal >> >> On Thu, May 24, 2018 at 10:43 AM, David Feuer wrote: >> On Thu, May 24, 2018, 1:03 PM Conal Elliott wrote: >> Thanks for this suggestion, David. It seems to work out well, though I haven't tried running yet. >> >> > unsafeDict :: Dict c >> > unsafeDict = unsafeCoerce (Dict @ ()) >> > >> > unsafeSatisfy :: forall c a. (c => a) -> a >> > unsafeSatisfy z | Dict <- unsafeDict @ c = z >> >> This doesn't really smell right to me, no. Dict @() is actually a rather different value than you seek. In general, these look like they do way more than they ever can. I would suggest you look through those comparison *constraints* to the underlying type equalities involving the primitive CmpNat type family. >> >> -- Better, because there's only one Refl >> unsafeEqual :: forall a b. a :~: b >> unsafeEqual :: unsafeCoerce Refl >> >> unsafeWithEqual :: forall a b r. (a ~ b => r) -> r >> unsafeWithEqual r >> | Refl <- unsafeEqual @a @b = r >> >> compareEv = case .... of >> LT -> unsafeWithEqual @(CmpNat u v) @LT CompareLT >> ... >> >> >> Now we can define `compareEv`: >> >> > compareEv :: forall u v. KnownNat2 u v => CompareEv u v >> > compareEv = case natValAt @ u `compare` natValAt @ v of >> > LT -> unsafeSatisfy @ (u < v) CompareLT >> > EQ -> unsafeSatisfy @ (u ~ v) CompareEQ >> > GT -> unsafeSatisfy @ (u > v) CompareGT >> >> If anyone has other techniques to suggest, I'd love to hear. >> >> -- Conal >> >> >> On Wed, May 23, 2018 at 5:44 PM, David Feuer wrote: >> I think the usual approach for defining these sorts of primitive operations is to use unsafeCoerce. >> >> On Wed, May 23, 2018, 7:39 PM Conal Elliott wrote: >> When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: >> >> > data CompareEv u v >> > = (u < v) => CompareLT >> > | (u ~ v) => CompareEQ >> > | (u > v) => CompareGT >> >> Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): >> >> > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v >> >> With `compareEv`, we can bring evidence into scope in `case` expressions. >> >> I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): >> >> > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of >> > LT -> CompareLT >> > EQ -> CompareEQ >> > GT -> CompareGT >> >> Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? >> >> Thanks, -- Conal >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ben at well-typed.com Tue May 29 20:07:23 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 29 May 2018 16:07:23 -0400 Subject: [ANNOUNCE] GHC 8.4.3 released Message-ID: <87lgc2kyyx.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mle+hs at mega-nerd.com Wed May 30 00:09:14 2018 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 30 May 2018 10:09:14 +1000 Subject: The dreaded windows path length issue Message-ID: <20180530100914.44ba3854347bba58b7ce10ae@mega-nerd.com> Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From tamar at zhox.com Wed May 30 11:08:31 2018 From: tamar at zhox.com (Tamar Christina) Date: Wed, 30 May 2018 11:08:31 +0000 Subject: The dreaded windows path length issue In-Reply-To: <20180530100914.44ba3854347bba58b7ce10ae@mega-nerd.com> References: <20180530100914.44ba3854347bba58b7ce10ae@mega-nerd.com> Message-ID: <163b0bc2829.1015af7e517381.5145368537785630194@zhox.com> Hi Erik, With GHC 8.6 we removed the MAX_PATH limit for normal Haskell programs but GCC and binutils are still a problem so GHC itself isn't yet fully immune. This issue looks like it's your GHC installation that is on a very deep path. If you're using stack that would explain it since stack installs it's GHC's in your profile which is quite deeply nested already. You can confirm this by running ghc --info, and look at the path for the C compiler and add 4 to get the path length of realgcc. You could modify https://github.com/ghc/ghc/blob/master/driver/gcc/gcc.c#L25 and remove the "%s", that would get GCC working, (note you have to use the bundled gcc compiled with the toolchain for this so the CPP macros expand to the correct versions). I suspect though that you have libraries that are on a path too long for binutils now too. Alternatuvely, if you're using stack try installing the compiler manually on a short path and tell it to use the system compiler. If using cabal just move your system compiler to a shorter path. Unfortunately there are no easy solutions for GCC and Binutils. The changes that they would require to remove MAX_PATH are small (in fact the code for GHC can be re-used as is) but FSF copyright assignment issues prevent me from submitting them myself. Cheers, Tamar ---- On Wed, 30 May 2018 00:09:14 +0000 Erik de Castro Lopo <mle+hs at mega-nerd.com> wrote ---- Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sebastien.Hinderer at inria.fr Thu May 31 09:32:24 2018 From: Sebastien.Hinderer at inria.fr (=?utf-8?Q?S=C3=A9bastien?= Hinderer) Date: Thu, 31 May 2018 11:32:24 +0200 Subject: Testing that packages still compile Message-ID: <20180531093224.GA6992@prajna.paris.inria.fr> Dear all, I am part of the OCaml development team. As you may know, OCaml has a package manager a bit similar to cabal whose name is opam. One of my colleagues spends quite a lot of time trying to make sure that packages still compile with a new version of the compiler, when we release it. When a package does not compile any longer, it seems it is a highly non-trivial task to figure out what exactly is broken: is it the package itself which has been broken by a change in the compiler, or is it one of its dependencies. I am assuming the same kind of problems occur with Haskell and am wondering how they are handle. Has there been something published on this kind of problem? Any pointer, comment or contact appreciated. Best wishes, Sébastien. From davean at xkcd.com Thu May 31 15:50:42 2018 From: davean at xkcd.com (davean) Date: Thu, 31 May 2018 11:50:42 -0400 Subject: Testing that packages still compile In-Reply-To: <20180531093224.GA6992@prajna.paris.inria.fr> References: <20180531093224.GA6992@prajna.paris.inria.fr> Message-ID: My experience may not be representative, but I've done waves of updating packages for a new major GHC release a few times now. I believe for the AMP-containing update of GHC I submitted patches to over 40 packages. My experience is far from universal, but I extensive enough to be informative. In my experience, Haskell's types gave precise sources for the error. As the packages form a DAG, issues with dependency packages were sorted out before I got to packages using them since the types caught any issues at the point that package was compiled. By when the dependent package was compiled, the type signatures of the dependency package was decided, and any compilation issues represented a legitimate API change requiring a patch to the package failing to compile. GHC flagged these issues at the point of use. Only rarely did I have to look in more than one place, and in those cases, it was universally inside the same package. Most of these were caused by changes in the unifier and were from the use of moderately exotic type system extensions that were purposefully changed causing disagreement inside the package about how to resolve the types since the design depended on ambiguity. Other than this last case, fixing the packages has been almost entirely procedural. It might take some time and familiarization with the package to make sure the change made was of sufficient quality to warrant submitting a patch instead of merely being correct, but it was never any mystery where the problem lay. I'd be curious what sort of issues you're encountering that caused confusion about the origin point of the issue. Its been over a decade since I used an ML language though so I'm not sure how Ocaml's type level specifications interact across packages. OCaml has some features that seem like they may lead to less orderly resolution of such problems (module functors come to mind as potentially interfering with the orderly nature of package dependencies). -davean On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer < Sebastien.Hinderer at inria.fr> wrote: > Dear all, > > I am part of the OCaml development team. As you may know, OCaml has a > package manager a bit similar to cabal whose name is opam. > > One of my colleagues spends quite a lot of time trying to make sure that > packages still compile with a new version of the compiler, when we > release it. When a package does not compile any longer, it seems it is a > highly non-trivial task to figure out what exactly is broken: is it the > package itself which has been broken by a change in the compiler, or is > it one of its dependencies. > > I am assuming the same kind of problems occur with Haskell and am > wondering how they are handle. > > Has there been something published on this kind of problem? > > Any pointer, comment or contact appreciated. > > Best wishes, > > Sébastien. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Thu May 31 15:58:37 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 1 Jun 2018 00:58:37 +0900 Subject: [ANNOUNCE] GHC 8.4.3 released In-Reply-To: <87lgc2kyyx.fsf@smart-cactus.org> References: <87lgc2kyyx.fsf@smart-cactus.org> Message-ID: On 30 May 2018 at 05:07, Ben Gamari wrote: > https://downloads.haskell.org/~ghc/8.4.3 Thanks! I have built it for Fedora and EPEL 7 (RHEL/CentOS) in a Copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.3 Cheers, Jens From carter.schonwald at gmail.com Thu May 31 18:53:34 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 31 May 2018 14:53:34 -0400 Subject: Testing that packages still compile In-Reply-To: References: <20180531093224.GA6992@prajna.paris.inria.fr> Message-ID: It may be that there’s quite a bit of code that doesn’t have explicit top level type signatures? That’s legal in Haskell but considered bad style / bad practice for packages. I’m not sure if the norms in O’Caml reflect the same inclination. This may complicate localizing type errors On Thu, May 31, 2018 at 11:51 AM davean wrote: > My experience may not be representative, but I've done waves of updating > packages for a new major GHC release a few times now. I believe for the > AMP-containing update of GHC I submitted patches to over 40 packages. My > experience is far from universal, but I extensive enough to be informative. > > In my experience, Haskell's types gave precise sources for the error. As > the packages form a DAG, issues with dependency packages were sorted out > before I got to packages using them since the types caught any issues at > the point that package was compiled. By when the dependent package was > compiled, the type signatures of the dependency package was decided, and > any compilation issues represented a legitimate API change requiring a > patch to the package failing to compile. GHC flagged these issues at the > point of use. Only rarely did I have to look in more than one place, and in > those cases, it was universally inside the same package. Most of these were > caused by changes in the unifier and were from the use of moderately exotic > type system extensions that were purposefully changed causing disagreement > inside the package about how to resolve the types since the design depended > on ambiguity. > > Other than this last case, fixing the packages has been almost entirely > procedural. It might take some time and familiarization with the package to > make sure the change made was of sufficient quality to warrant submitting a > patch instead of merely being correct, but it was never any mystery where > the problem lay. I'd be curious what sort of issues you're encountering > that caused confusion about the origin point of the issue. Its been over a > decade since I used an ML language though so I'm not sure how Ocaml's type > level specifications interact across packages. OCaml has some features that > seem like they may lead to less orderly resolution of such problems (module > functors come to mind as potentially interfering with the orderly nature of > package dependencies). > > -davean > > On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer < > Sebastien.Hinderer at inria.fr> wrote: > >> Dear all, >> >> I am part of the OCaml development team. As you may know, OCaml has a >> package manager a bit similar to cabal whose name is opam. >> >> One of my colleagues spends quite a lot of time trying to make sure that >> packages still compile with a new version of the compiler, when we >> release it. When a package does not compile any longer, it seems it is a >> highly non-trivial task to figure out what exactly is broken: is it the >> package itself which has been broken by a change in the compiler, or is >> it one of its dependencies. >> >> I am assuming the same kind of problems occur with Haskell and am >> wondering how they are handle. >> >> Has there been something published on this kind of problem? >> >> Any pointer, comment or contact appreciated. >> >> Best wishes, >> >> Sébastien. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Thu May 31 20:38:44 2018 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Thu, 31 May 2018 22:38:44 +0200 Subject: Testing that packages still compile In-Reply-To: <20180531093224.GA6992@prajna.paris.inria.fr> References: <20180531093224.GA6992@prajna.paris.inria.fr> Message-ID: You may also be interested in the "Hackage Matrix CI" links on Hackage pages and the non-maintainer updates of packages performed as part of the service to the community. On Thu, May 31, 2018 at 11:32 AM, Sébastien Hinderer wrote: > Dear all, > > I am part of the OCaml development team. As you may know, OCaml has a > package manager a bit similar to cabal whose name is opam. > > One of my colleagues spends quite a lot of time trying to make sure that > packages still compile with a new version of the compiler, when we > release it. When a package does not compile any longer, it seems it is a > highly non-trivial task to figure out what exactly is broken: is it the > package itself which has been broken by a change in the compiler, or is > it one of its dependencies. > > I am assuming the same kind of problems occur with Haskell and am > wondering how they are handle. > > Has there been something published on this kind of problem? > > Any pointer, comment or contact appreciated. > > Best wishes, > > Sébastien. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users