From lhw at lunacd.com Mon Nov 8 22:54:36 2021 From: lhw at lunacd.com (Haowen Liu) Date: Mon, 8 Nov 2021 14:54:36 -0800 Subject: Humble message of support and concern from an interested newbie Message-ID: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> Hi, I hope this email finds you all well. I'm a newbie only starting with Haskell very recently, but I LOVE what I'm discovering with Haskell and its ecosystem. That's why I was shocked to see that the latest Haskell standard is still Haskell2010, and activities on this list has halted for 3 years. I skimmed through the Haskell2010 spec and understand deeply that the next Haskell standard will be an equally challenging enterprise. I, although yet to be sufficiently familiar with Haskell, want to let you all know that I'm hugely grateful for all the work you have done, and I'm more than willing to extend any kind of help moving forward with the next Haskell standard. If people are still interested in developing Haskell202X, and if people need some sort of secretary, editor, errand runner, or whatever, please let me know and I can help. Grateful, concerned, and eager to help, Haowen Liu From cgibbard at gmail.com Mon Nov 8 23:45:17 2021 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon, 8 Nov 2021 18:45:17 -0500 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> Message-ID: The tricky thing is that while a new document describing the language in detail would be welcomed, it's hard for people to justify doing all the work that's involved in producing a new document that's substantially more helpful than the Haskell 2010 or '98 Report. Right at the moment, there's essentially one practically-usable implementation of the language, GHC (unless maybe you count GHCJS, and that's sharing GHC's frontend regardless). So the demand for a document that says what needs to be shared between implementations of the language is low. Personally, I think producing a description of what GHC is meant to be implementing, with as complete coverage of all the extensions as can be managed, i.e. a report, is something that would be quite valuable. However, that's a very large task, and most of the people who would be well-suited to produce that document have other constraints on their time. I don't think there's a pressing need for a normative standards document at the moment though. Maybe if some Haskell-using company were to get large enough to devote a team to working on a new general purpose Haskell compiler for some reason, or there was a big open-source push for a second Haskell compiler, there would be cause for a normative standard. But for now, everyone's been more or less content with working together extending GHC rather than building something entirely new. (I would have a fair amount of sympathy for someone wanting to start fresh though. I have my own list of reasons for which I can imagine wanting to take a shot at reimplementing the language, but I don't really have the time or energy for it myself.) For the descriptive side of things, most people get by right now with the GHC User's Guide, and failing that, there are often papers that go into much greater detail about the individual extensions. If you want to really understand the finer details of how those extensions all interact with one another though, there's presently nothing apart from the compiler itself (and even then, how they *ought* to interact is a different question from how they *do* interact). Understanding that and describing it all in a precise way is a big and difficult task, and it's one whose cost sadly might outweigh its benefits, especially if the progress toward a new Haskell Report is any indication. Even more, I think most would be delighted to see a denotational semantics for all of Haskell again. But it's one of those things which is difficult to produce in the first place, and then unless a process were in place to have it track the implementation, it would almost immediately fall out of date. That said, I can imagine there will be a point where the process to write a new Report kicks back off, I just don't think it's been at the forefront of most people's minds lately. - Cale On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime < haskell-prime at haskell.org> wrote: > Hi, > > I hope this email finds you all well. I'm a newbie only starting with > Haskell very recently, but I LOVE what I'm discovering with Haskell and > its ecosystem. That's why I was shocked to see that the latest Haskell > standard is still Haskell2010, and activities on this list has halted > for 3 years. > > I skimmed through the Haskell2010 spec and understand deeply that the > next Haskell standard will be an equally challenging enterprise. I, > although yet to be sufficiently familiar with Haskell, want to let you > all know that I'm hugely grateful for all the work you have done, and > I'm more than willing to extend any kind of help moving forward with the > next Haskell standard. If people are still interested in developing > Haskell202X, and if people need some sort of secretary, editor, errand > runner, or whatever, please let me know and I can help. > > Grateful, concerned, and eager to help, > Haowen Liu > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Tue Nov 9 03:45:53 2021 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon, 8 Nov 2021 22:45:53 -0500 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <184b0975-c954-7328-b69e-902769164f85@lunacd.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> Message-ID: To some extent I can agree with the view that certain small things should possibly be folded in, but from another perspective, I actually like the way that major language features are modular, and I can tell a lot about what to expect by looking at the top of a file. There are also things that most people agree are a decent part of the language, but should also probably never stop being extensions, like FFI and Template Haskell. But while warning users about certain things being controversial or unstable and certain things being less so could be something that one could put in the Report, I wouldn't want any change to the language to start there. If you try to make changes to the language as it exists while also documenting it, you'll end up in a season of bikeshedding that will never end, and at the same time end up describing a creature that doesn't exist. See the ghc-proposals mailing list for a more appropriate place to begin with changes to the language at present. See also this proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst which has been implemented in the latest GHC 9.2 for defining a particular "GHC2021" agglomeration of some of the most commonly used extensions. There's also a table there containing some nice usage statistics that were collected from Hackage. >From the other side of things, I think the Report, if revived, should not shy away from trying to describe as many of the extensions as people have the energy to describe, controversial/unstable or not. The most important purpose for which I'd really like to have a Report at present would be to properly clarify the interactions between extensions. For example, how do you figure out what happens when you use functional dependencies and type equality constraints together? Exactly how does GHC know when to instantiate a quantified constraint, and how does that interact with type family expansion? Even the technical papers written about these features don't necessarily answer questions about these interactions, so if you start using them together, cases can arise where it can be difficult to determine what's going to happen. Often things will just work as you might hope, even if you're not entirely certain why. Once in a blue moon though, you might just get weird error messages that don't quite make sense, but seem to indicate that the compiler is very confused. Then perhaps you try a newer GHC, and find out that particular combination of things is now simply forbidden outright. So it would be nice to really get everything into a single framework of description, and there have been some rather large efforts in the direction of unifying large chunks of it, like the OutsideIn(X) paper (which is already perhaps too technical compared with the Report), but it's by no means easy. Also, typical users of the language eventually have to contend with most of the extensions, controversial or not, and it would be very nice to have a reference for what things are supposed to mean regardless of whether we'd rather they not be in the language at all. The Report would also be a great place to have a little bit of guidance and statistics on how stable/well-used these things are. - Cale On Mon, 8 Nov 2021 at 21:41, Haowen Liu wrote: > Hi Cale and others, > > Thank you Cale so so much for such a detailed explanation! > > I agree with you that an evolving standard is only useful as a > normalizing force if we have multiple compilers, like C/C++. Such is the > same for the standard as documentation since GHC documentation is really > what people should refer to. > > I realize I'm in no way qualified to make those points but in my meager > experience with Haskell, an evolving standard could serve as a very > valuable verdict of the merits of various GHC extensions. AFAIK, some > GHC extensions are very widely adopted and some are considered > misfeatures. The Haskell202X could simply incorporate a list of > agreeable extensions into the core language and those less agreeable > ones could stay as extensions or whatever the GHC community decides to > do with them. > > I think such kind of Haskell202X is advantageous in the following ways: > > 1. It is less time consuming than radical language changes. And the very > fact that the Haskell202X effort is halted proves that Haskell currently > demands no radical changes (at least not the ones that can't be > implemented as a GHC extension). > > 2. We no longer to enable a series of widely used plugins. Many of the > extensions integrate so nicely into the language that I don't think > programmers should be required to manually enable them to use them. > According to Sandy Maguire, "In GHC 8.6.5, there are 125 different > language extensions, and an analysis shows that 10% of Haskell files in > the wild enable 10 or more extensions." [1] > > 3. People are less likely to use those less agreeable extensions because > at that time enabling extensions would be a rare case of workaround (as > it should be, I believe) rather than a norm. > > 4. It gives people, especially newcomers, a sense that Haskell is still > very much alive. > > In addition to integrating extensions, in very rare cases, we could slip > in some feature removal or modifications in areas where people feel > strongly about. But even with those, I feel like this work is very much > doable. > > Best, > Haowen > On 11/8/2021 3:45 PM, Cale Gibbard wrote: > > The tricky thing is that while a new document describing the language in > > detail would be welcomed, it's hard for people to justify doing all the > > work that's involved in producing a new document that's substantially > > more helpful than the Haskell 2010 or '98 Report. Right at the moment, > > there's essentially one practically-usable implementation of the > > language, GHC (unless maybe you count GHCJS, and that's sharing GHC's > > frontend regardless). So the demand for a document that says what needs > > to be shared between implementations of the language is low. Personally, > > I think producing a description of what GHC is meant to be implementing, > > with as complete coverage of all the extensions as can be managed, i.e. > > a report, is something that would be quite valuable. However, that's a > > very large task, and most of the people who would be well-suited to > > produce that document have other constraints on their time. I don't > > think there's a pressing need for a normative standards document at the > > moment though. > > > > Maybe if some Haskell-using company were to get large enough to devote a > > team to working on a new general purpose Haskell compiler for some > > reason, or there was a big open-source push for a second Haskell > > compiler, there would be cause for a normative standard. But for now, > > everyone's been more or less content with working together extending GHC > > rather than building something entirely new. (I would have a fair amount > > of sympathy for someone wanting to start fresh though. I have my own > > list of reasons for which I can imagine wanting to take a shot at > > reimplementing the language, but I don't really have the time or energy > > for it myself.) > > > > For the descriptive side of things, most people get by right now with > > the GHC User's Guide, and failing that, there are often papers that go > > into much greater detail about the individual extensions. If you want to > > really understand the finer details of how those extensions all interact > > with one another though, there's presently nothing apart from the > > compiler itself (and even then, how they *ought* to interact is a > > different question from how they *do* interact). Understanding that and > > describing it all in a precise way is a big and difficult task, and it's > > one whose cost sadly might outweigh its benefits, especially if the > > progress toward a new Haskell Report is any indication. > > > > Even more, I think most would be delighted to see a denotational > > semantics for all of Haskell again. But it's one of those things which > > is difficult to produce in the first place, and then unless a process > > were in place to have it track the implementation, it would almost > > immediately fall out of date. > > > > That said, I can imagine there will be a point where the process to > > write a new Report kicks back off, I just don't think it's been at the > > forefront of most people's minds lately. > > > > - Cale > > > > On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime > > > wrote: > > > > Hi, > > > > I hope this email finds you all well. I'm a newbie only starting with > > Haskell very recently, but I LOVE what I'm discovering with Haskell > and > > its ecosystem. That's why I was shocked to see that the latest > Haskell > > standard is still Haskell2010, and activities on this list has halted > > for 3 years. > > > > I skimmed through the Haskell2010 spec and understand deeply that the > > next Haskell standard will be an equally challenging enterprise. I, > > although yet to be sufficiently familiar with Haskell, want to let > you > > all know that I'm hugely grateful for all the work you have done, and > > I'm more than willing to extend any kind of help moving forward with > > the > > next Haskell standard. If people are still interested in developing > > Haskell202X, and if people need some sort of secretary, editor, > errand > > runner, or whatever, please let me know and I can help. > > > > Grateful, concerned, and eager to help, > > Haowen Liu > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Nov 10 03:57:56 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 10 Nov 2021 03:57:56 +0000 Subject: Humble message of support and concern from an interested newbie In-Reply-To: References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> Message-ID: <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> I want to chime in with agreement that the GHC2021 push may meet many of the goals you may be after. I also want to bring in a further aspect of challenge in producing a new Report: we don't really understand Haskell well enough to do so. The two Reports do a very fine job of specifying the behavior of the language. However, for almost any extension that isn't in the Report, there are corner cases that are hard to describe and nail down. We could, of course, just write down GHC's algorithm and try to standardize it... but that feels like cheating. Instead, we would like to be able to describe Haskell's behavior declaratively. Yet, when the Haskell2020 team tried to identify an extension that was both stable enough to considered ready for inclusion in the Report and could be described declaratively, we failed. (Yes, even FlexibleContexts has dark corners.) The lesson learned here is not that writing a new Report would be impossible -- just that it would be very difficult: we would likely have to do fresh programming-language research just to be able to write down GHC's behavior accurately and declaratively. As much as I would love to receive a Haskell2020 Report as a birthday present, I personally do not think having it is worth the considerable expense. Thanks for your Haskell enthusiasm! If you do want to see evidence of continued growth of the language's main implementation, check out https://github.com/ghc-proposals/ghc-proposals/, quite an active space of language design. Richard > On Nov 8, 2021, at 10:45 PM, Cale Gibbard wrote: > > To some extent I can agree with the view that certain small things should possibly be folded in, but from another perspective, I actually like the way that major language features are modular, and I can tell a lot about what to expect by looking at the top of a file. There are also things that most people agree are a decent part of the language, but should also probably never stop being extensions, like FFI and Template Haskell. > > But while warning users about certain things being controversial or unstable and certain things being less so could be something that one could put in the Report, I wouldn't want any change to the language to start there. If you try to make changes to the language as it exists while also documenting it, you'll end up in a season of bikeshedding that will never end, and at the same time end up describing a creature that doesn't exist. See the ghc-proposals mailing list for a more appropriate place to begin with changes to the language at present. See also this proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst which has been implemented in the latest GHC 9.2 for defining a particular "GHC2021" agglomeration of some of the most commonly used extensions. There's also a table there containing some nice usage statistics that were collected from Hackage. > > From the other side of things, I think the Report, if revived, should not shy away from trying to describe as many of the extensions as people have the energy to describe, controversial/unstable or not. The most important purpose for which I'd really like to have a Report at present would be to properly clarify the interactions between extensions. For example, how do you figure out what happens when you use functional dependencies and type equality constraints together? Exactly how does GHC know when to instantiate a quantified constraint, and how does that interact with type family expansion? Even the technical papers written about these features don't necessarily answer questions about these interactions, so if you start using them together, cases can arise where it can be difficult to determine what's going to happen. Often things will just work as you might hope, even if you're not entirely certain why. Once in a blue moon though, you might just get weird error messages that don't quite make sense, but seem to indicate that the compiler is very confused. Then perhaps you try a newer GHC, and find out that particular combination of things is now simply forbidden outright. So it would be nice to really get everything into a single framework of description, and there have been some rather large efforts in the direction of unifying large chunks of it, like the OutsideIn(X) paper (which is already perhaps too technical compared with the Report), but it's by no means easy. > > Also, typical users of the language eventually have to contend with most of the extensions, controversial or not, and it would be very nice to have a reference for what things are supposed to mean regardless of whether we'd rather they not be in the language at all. The Report would also be a great place to have a little bit of guidance and statistics on how stable/well-used these things are. > > - Cale > > On Mon, 8 Nov 2021 at 21:41, Haowen Liu > wrote: > Hi Cale and others, > > Thank you Cale so so much for such a detailed explanation! > > I agree with you that an evolving standard is only useful as a > normalizing force if we have multiple compilers, like C/C++. Such is the > same for the standard as documentation since GHC documentation is really > what people should refer to. > > I realize I'm in no way qualified to make those points but in my meager > experience with Haskell, an evolving standard could serve as a very > valuable verdict of the merits of various GHC extensions. AFAIK, some > GHC extensions are very widely adopted and some are considered > misfeatures. The Haskell202X could simply incorporate a list of > agreeable extensions into the core language and those less agreeable > ones could stay as extensions or whatever the GHC community decides to > do with them. > > I think such kind of Haskell202X is advantageous in the following ways: > > 1. It is less time consuming than radical language changes. And the very > fact that the Haskell202X effort is halted proves that Haskell currently > demands no radical changes (at least not the ones that can't be > implemented as a GHC extension). > > 2. We no longer to enable a series of widely used plugins. Many of the > extensions integrate so nicely into the language that I don't think > programmers should be required to manually enable them to use them. > According to Sandy Maguire, "In GHC 8.6.5, there are 125 different > language extensions, and an analysis shows that 10% of Haskell files in > the wild enable 10 or more extensions." [1] > > 3. People are less likely to use those less agreeable extensions because > at that time enabling extensions would be a rare case of workaround (as > it should be, I believe) rather than a norm. > > 4. It gives people, especially newcomers, a sense that Haskell is still > very much alive. > > In addition to integrating extensions, in very rare cases, we could slip > in some feature removal or modifications in areas where people feel > strongly about. But even with those, I feel like this work is very much > doable. > > Best, > Haowen > On 11/8/2021 3:45 PM, Cale Gibbard wrote: > > The tricky thing is that while a new document describing the language in > > detail would be welcomed, it's hard for people to justify doing all the > > work that's involved in producing a new document that's substantially > > more helpful than the Haskell 2010 or '98 Report. Right at the moment, > > there's essentially one practically-usable implementation of the > > language, GHC (unless maybe you count GHCJS, and that's sharing GHC's > > frontend regardless). So the demand for a document that says what needs > > to be shared between implementations of the language is low. Personally, > > I think producing a description of what GHC is meant to be implementing, > > with as complete coverage of all the extensions as can be managed, i.e. > > a report, is something that would be quite valuable. However, that's a > > very large task, and most of the people who would be well-suited to > > produce that document have other constraints on their time. I don't > > think there's a pressing need for a normative standards document at the > > moment though. > > > > Maybe if some Haskell-using company were to get large enough to devote a > > team to working on a new general purpose Haskell compiler for some > > reason, or there was a big open-source push for a second Haskell > > compiler, there would be cause for a normative standard. But for now, > > everyone's been more or less content with working together extending GHC > > rather than building something entirely new. (I would have a fair amount > > of sympathy for someone wanting to start fresh though. I have my own > > list of reasons for which I can imagine wanting to take a shot at > > reimplementing the language, but I don't really have the time or energy > > for it myself.) > > > > For the descriptive side of things, most people get by right now with > > the GHC User's Guide, and failing that, there are often papers that go > > into much greater detail about the individual extensions. If you want to > > really understand the finer details of how those extensions all interact > > with one another though, there's presently nothing apart from the > > compiler itself (and even then, how they *ought* to interact is a > > different question from how they *do* interact). Understanding that and > > describing it all in a precise way is a big and difficult task, and it's > > one whose cost sadly might outweigh its benefits, especially if the > > progress toward a new Haskell Report is any indication. > > > > Even more, I think most would be delighted to see a denotational > > semantics for all of Haskell again. But it's one of those things which > > is difficult to produce in the first place, and then unless a process > > were in place to have it track the implementation, it would almost > > immediately fall out of date. > > > > That said, I can imagine there will be a point where the process to > > write a new Report kicks back off, I just don't think it's been at the > > forefront of most people's minds lately. > > > > - Cale > > > > On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime > > >> wrote: > > > > Hi, > > > > I hope this email finds you all well. I'm a newbie only starting with > > Haskell very recently, but I LOVE what I'm discovering with Haskell and > > its ecosystem. That's why I was shocked to see that the latest Haskell > > standard is still Haskell2010, and activities on this list has halted > > for 3 years. > > > > I skimmed through the Haskell2010 spec and understand deeply that the > > next Haskell standard will be an equally challenging enterprise. I, > > although yet to be sufficiently familiar with Haskell, want to let you > > all know that I'm hugely grateful for all the work you have done, and > > I'm more than willing to extend any kind of help moving forward with > > the > > next Haskell standard. If people are still interested in developing > > Haskell202X, and if people need some sort of secretary, editor, errand > > runner, or whatever, please let me know and I can help. > > > > Grateful, concerned, and eager to help, > > Haowen Liu > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhw at lunacd.com Wed Nov 10 04:26:07 2021 From: lhw at lunacd.com (Haowen Liu) Date: Tue, 9 Nov 2021 20:26:07 -0800 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, Thank you for chiming in! I think I now have a better idea what happened several years ago when the Haskell2020 effort died down... And thank you for that link!! I did not know it existed! (Why would they put it under a separate GitHub organization? That's why I didn't find it LOL) BTW I just realized that my previous responses to Cale is sent privately because I forgot to reply all... Sad... Best, Haowen On 11/9/2021 7:57 PM, Richard Eisenberg wrote: > I want to chime in with agreement that the GHC2021 push may meet many > of the goals you may be after. I also want to bring in a further > aspect of challenge in producing a new Report: we don't really > understand Haskell well enough to do so. > > The two Reports do a very fine job of specifying the behavior of the > language. However, for almost any extension that isn't in the Report, > there are corner cases that are hard to describe and nail down. We > could, of course, just write down GHC's algorithm and try to > standardize it... but that feels like cheating. Instead, we would like > to be able to describe Haskell's behavior declaratively. Yet, when the > Haskell2020 team tried to identify an extension that was both stable > enough to considered ready for inclusion in the Report and could be > described declaratively, we failed. (Yes, even FlexibleContexts has > dark corners.) The lesson learned here is not that writing a new > Report would be impossible -- just that it would be very difficult: we > would likely have to do fresh programming-language research just to be > able to write down GHC's behavior accurately and declaratively. As > much as I would love to receive a Haskell2020 Report as a birthday > present, I personally do not think having it is worth the considerable > expense. > > Thanks for your Haskell enthusiasm! If you do want to see evidence of > continued growth of the language's main implementation, check out > https://github.com/ghc-proposals/ghc-proposals/, quite an active space > of language design. > > Richard > >> On Nov 8, 2021, at 10:45 PM, Cale Gibbard wrote: >> >> To some extent I can agree with the view that certain small things >> should possibly be folded in, but from another perspective, I >> actually like the way that major language features are modular, and I >> can tell a lot about what to expect by looking at the top of a file. >> There are also things that most people agree are a decent part of the >> language, but should also probably never stop being extensions, like >> FFI and Template Haskell. >> >> But while warning users about certain things being controversial or >> unstable and certain things being less so could be something that one >> could put in the Report, I wouldn't want any change to the language >> to start there. If you try to make changes to the language as it >> exists while also documenting it, you'll end up in a season of >> bikeshedding that will never end, and at the same time end up >> describing a creature that doesn't exist. See the ghc-proposals >> mailing list for a more appropriate place to begin with changes to >> the language at present. See also this proposal: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst >> which has been implemented in the latest GHC 9.2 for defining a >> particular "GHC2021" agglomeration of some of the most commonly used >> extensions. There's also a table there containing some nice usage >> statistics that were collected from Hackage. >> >> From the other side of things, I think the Report, if revived, should >> not shy away from trying to describe as many of the extensions as >> people have the energy to describe, controversial/unstable or not. >> The most important purpose for which I'd really like to have a Report >> at present would be to properly clarify the interactions between >> extensions. For example, how do you figure out what happens when you >> use functional dependencies and type equality constraints together? >> Exactly how does GHC know when to instantiate a quantified >> constraint, and how does that interact with type family expansion? >> Even the technical papers written about these features don't >> necessarily answer questions about these interactions, so if you >> start using them together, cases can arise where it can be difficult >> to determine what's going to happen. Often things will just work as >> you might hope, even if you're not entirely certain why. Once in a >> blue moon though, you might just get weird error messages that don't >> quite make sense, but seem to indicate that the compiler is very >> confused. Then perhaps you try a newer GHC, and find out that >> particular combination of things is now simply forbidden outright. So >> it would be nice to really get everything into a single framework of >> description, and there have been some rather large efforts in the >> direction of unifying large chunks of it, like the OutsideIn(X) paper >> (which is already perhaps too technical compared with the Report), >> but it's by no means easy. >> >> Also, typical users of the language eventually have to contend with >> most of the extensions, controversial or not, and it would be very >> nice to have a reference for what things are supposed to mean >> regardless of whether we'd rather they not be in the language at all. >> The Report would also be a great place to have a little bit of >> guidance and statistics on how stable/well-used these things are. >> >>  - Cale >> >> On Mon, 8 Nov 2021 at 21:41, Haowen Liu wrote: >> >> Hi Cale and others, >> >> Thank you Cale so so much for such a detailed explanation! >> >> I agree with you that an evolving standard is only useful as a >> normalizing force if we have multiple compilers, like C/C++. Such >> is the >> same for the standard as documentation since GHC documentation is >> really >> what people should refer to. >> >> I realize I'm in no way qualified to make those points but in my >> meager >> experience with Haskell, an evolving standard could serve as a very >> valuable verdict of the merits of various GHC extensions. AFAIK, >> some >> GHC extensions are very widely adopted and some are considered >> misfeatures. The Haskell202X could simply incorporate a list of >> agreeable extensions into the core language and those less agreeable >> ones could stay as extensions or whatever the GHC community >> decides to >> do with them. >> >> I think such kind of Haskell202X is advantageous in the following >> ways: >> >> 1. It is less time consuming than radical language changes. And >> the very >> fact that the Haskell202X effort is halted proves that Haskell >> currently >> demands no radical changes (at least not the ones that can't be >> implemented as a GHC extension). >> >> 2. We no longer to enable a series of widely used plugins. Many >> of the >> extensions integrate so nicely into the language that I don't think >> programmers should be required to manually enable them to use them. >> According to Sandy Maguire, "In GHC 8.6.5, there are 125 different >> language extensions, and an analysis shows that 10% of Haskell >> files in >> the wild enable 10 or more extensions." [1] >> >> 3. People are less likely to use those less agreeable extensions >> because >> at that time enabling extensions would be a rare case of >> workaround (as >> it should be, I believe) rather than a norm. >> >> 4. It gives people, especially newcomers, a sense that Haskell is >> still >> very much alive. >> >> In addition to integrating extensions, in very rare cases, we >> could slip >> in some feature removal or modifications in areas where people feel >> strongly about. But even with those, I feel like this work is >> very much >> doable. >> >> Best, >> Haowen >> On 11/8/2021 3:45 PM, Cale Gibbard wrote: >> > The tricky thing is that while a new document describing the >> language in >> > detail would be welcomed, it's hard for people to justify doing >> all the >> > work that's involved in producing a new document that's >> substantially >> > more helpful than the Haskell 2010 or '98 Report. Right at the >> moment, >> > there's essentially one practically-usable implementation of the >> > language, GHC (unless maybe you count GHCJS, and that's sharing >> GHC's >> > frontend regardless). So the demand for a document that says >> what needs >> > to be shared between implementations of the language is low. >> Personally, >> > I think producing a description of what GHC is meant to be >> implementing, >> > with as complete coverage of all the extensions as can be >> managed, i.e. >> > a report, is something that would be quite valuable. However, >> that's a >> > very large task, and most of the people who would be >> well-suited to >> > produce that document have other constraints on their time. I >> don't >> > think there's a pressing need for a normative standards >> document at the >> > moment though. >> > >> > Maybe if some Haskell-using company were to get large enough to >> devote a >> > team to working on a new general purpose Haskell compiler for some >> > reason, or there was a big open-source push for a second Haskell >> > compiler, there would be cause for a normative standard. But >> for now, >> > everyone's been more or less content with working together >> extending GHC >> > rather than building something entirely new. (I would have a >> fair amount >> > of sympathy for someone wanting to start fresh though. I have >> my own >> > list of reasons for which I can imagine wanting to take a shot at >> > reimplementing the language, but I don't really have the time >> or energy >> > for it myself.) >> > >> > For the descriptive side of things, most people get by right >> now with >> > the GHC User's Guide, and failing that, there are often papers >> that go >> > into much greater detail about the individual extensions. If >> you want to >> > really understand the finer details of how those extensions all >> interact >> > with one another though, there's presently nothing apart from the >> > compiler itself (and even then, how they *ought* to interact is a >> > different question from how they *do* interact). Understanding >> that and >> > describing it all in a precise way is a big and difficult task, >> and it's >> > one whose cost sadly might outweigh its benefits, especially if >> the >> > progress toward a new Haskell Report is any indication. >> > >> > Even more, I think most would be delighted to see a denotational >> > semantics for all of Haskell again. But it's one of those >> things which >> > is difficult to produce in the first place, and then unless a >> process >> > were in place to have it track the implementation, it would almost >> > immediately fall out of date. >> > >> > That said, I can imagine there will be a point where the >> process to >> > write a new Report kicks back off, I just don't think it's been >> at the >> > forefront of most people's minds lately. >> > >> >   - Cale >> > >> > On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime >> > > >> wrote: >> > >> >     Hi, >> > >> >     I hope this email finds you all well. I'm a newbie only >> starting with >> >     Haskell very recently, but I LOVE what I'm discovering with >> Haskell and >> >     its ecosystem. That's why I was shocked to see that the >> latest Haskell >> >     standard is still Haskell2010, and activities on this list >> has halted >> >     for 3 years. >> > >> >     I skimmed through the Haskell2010 spec and understand >> deeply that the >> >     next Haskell standard will be an equally challenging >> enterprise. I, >> >     although yet to be sufficiently familiar with Haskell, want >> to let you >> >     all know that I'm hugely grateful for all the work you have >> done, and >> >     I'm more than willing to extend any kind of help moving >> forward with >> >     the >> >     next Haskell standard. If people are still interested in >> developing >> >     Haskell202X, and if people need some sort of secretary, >> editor, errand >> >     runner, or whatever, please let me know and I can help. >> > >> >     Grateful, concerned, and eager to help, >> >     Haowen Liu >> >  _______________________________________________ >> >     Haskell-prime mailing list >> > Haskell-prime at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> >    >>   >> > >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Nov 10 19:21:50 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 10 Nov 2021 19:21:50 +0000 Subject: Humble message of support and concern from an interested newbie In-Reply-To: References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> Message-ID: <010f017d0b4c9f4c-787c22bd-c4be-4e51-8ade-b37496d57cc8-000000@us-east-2.amazonses.com> > On Nov 9, 2021, at 11:26 PM, Haowen Liu wrote: > And thank you for that link!! I did not know it existed! (Why would they put it under a separate GitHub organization? That's why I didn't find it LOL) > > That's a good question. I think we did it because it's a GHC-specific process, not really about Haskell, per se. But it's also not in the GHC org... which maybe it should have been. Where do you think would be a good place to list this repo for other people like you to find it in the future? Thanks! Richard > BTW I just realized that my previous responses to Cale is sent privately because I forgot to reply all... Sad... > > Best, > Haowen > > On 11/9/2021 7:57 PM, Richard Eisenberg wrote: >> I want to chime in with agreement that the GHC2021 push may meet many of the goals you may be after. I also want to bring in a further aspect of challenge in producing a new Report: we don't really understand Haskell well enough to do so. >> >> The two Reports do a very fine job of specifying the behavior of the language. However, for almost any extension that isn't in the Report, there are corner cases that are hard to describe and nail down. We could, of course, just write down GHC's algorithm and try to standardize it... but that feels like cheating. Instead, we would like to be able to describe Haskell's behavior declaratively. Yet, when the Haskell2020 team tried to identify an extension that was both stable enough to considered ready for inclusion in the Report and could be described declaratively, we failed. (Yes, even FlexibleContexts has dark corners.) The lesson learned here is not that writing a new Report would be impossible -- just that it would be very difficult: we would likely have to do fresh programming-language research just to be able to write down GHC's behavior accurately and declaratively. As much as I would love to receive a Haskell2020 Report as a birthday present, I personally do not think having it is worth the considerable expense. >> >> Thanks for your Haskell enthusiasm! If you do want to see evidence of continued growth of the language's main implementation, check out https://github.com/ghc-proposals/ghc-proposals/ , quite an active space of language design. >> >> Richard >> >>> On Nov 8, 2021, at 10:45 PM, Cale Gibbard > wrote: >>> >>> To some extent I can agree with the view that certain small things should possibly be folded in, but from another perspective, I actually like the way that major language features are modular, and I can tell a lot about what to expect by looking at the top of a file. There are also things that most people agree are a decent part of the language, but should also probably never stop being extensions, like FFI and Template Haskell. >>> >>> But while warning users about certain things being controversial or unstable and certain things being less so could be something that one could put in the Report, I wouldn't want any change to the language to start there. If you try to make changes to the language as it exists while also documenting it, you'll end up in a season of bikeshedding that will never end, and at the same time end up describing a creature that doesn't exist. See the ghc-proposals mailing list for a more appropriate place to begin with changes to the language at present. See also this proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst which has been implemented in the latest GHC 9.2 for defining a particular "GHC2021" agglomeration of some of the most commonly used extensions. There's also a table there containing some nice usage statistics that were collected from Hackage. >>> >>> From the other side of things, I think the Report, if revived, should not shy away from trying to describe as many of the extensions as people have the energy to describe, controversial/unstable or not. The most important purpose for which I'd really like to have a Report at present would be to properly clarify the interactions between extensions. For example, how do you figure out what happens when you use functional dependencies and type equality constraints together? Exactly how does GHC know when to instantiate a quantified constraint, and how does that interact with type family expansion? Even the technical papers written about these features don't necessarily answer questions about these interactions, so if you start using them together, cases can arise where it can be difficult to determine what's going to happen. Often things will just work as you might hope, even if you're not entirely certain why. Once in a blue moon though, you might just get weird error messages that don't quite make sense, but seem to indicate that the compiler is very confused. Then perhaps you try a newer GHC, and find out that particular combination of things is now simply forbidden outright. So it would be nice to really get everything into a single framework of description, and there have been some rather large efforts in the direction of unifying large chunks of it, like the OutsideIn(X) paper (which is already perhaps too technical compared with the Report), but it's by no means easy. >>> >>> Also, typical users of the language eventually have to contend with most of the extensions, controversial or not, and it would be very nice to have a reference for what things are supposed to mean regardless of whether we'd rather they not be in the language at all. The Report would also be a great place to have a little bit of guidance and statistics on how stable/well-used these things are. >>> >>> - Cale >>> >>> On Mon, 8 Nov 2021 at 21:41, Haowen Liu > wrote: >>> Hi Cale and others, >>> >>> Thank you Cale so so much for such a detailed explanation! >>> >>> I agree with you that an evolving standard is only useful as a >>> normalizing force if we have multiple compilers, like C/C++. Such is the >>> same for the standard as documentation since GHC documentation is really >>> what people should refer to. >>> >>> I realize I'm in no way qualified to make those points but in my meager >>> experience with Haskell, an evolving standard could serve as a very >>> valuable verdict of the merits of various GHC extensions. AFAIK, some >>> GHC extensions are very widely adopted and some are considered >>> misfeatures. The Haskell202X could simply incorporate a list of >>> agreeable extensions into the core language and those less agreeable >>> ones could stay as extensions or whatever the GHC community decides to >>> do with them. >>> >>> I think such kind of Haskell202X is advantageous in the following ways: >>> >>> 1. It is less time consuming than radical language changes. And the very >>> fact that the Haskell202X effort is halted proves that Haskell currently >>> demands no radical changes (at least not the ones that can't be >>> implemented as a GHC extension). >>> >>> 2. We no longer to enable a series of widely used plugins. Many of the >>> extensions integrate so nicely into the language that I don't think >>> programmers should be required to manually enable them to use them. >>> According to Sandy Maguire, "In GHC 8.6.5, there are 125 different >>> language extensions, and an analysis shows that 10% of Haskell files in >>> the wild enable 10 or more extensions." [1] >>> >>> 3. People are less likely to use those less agreeable extensions because >>> at that time enabling extensions would be a rare case of workaround (as >>> it should be, I believe) rather than a norm. >>> >>> 4. It gives people, especially newcomers, a sense that Haskell is still >>> very much alive. >>> >>> In addition to integrating extensions, in very rare cases, we could slip >>> in some feature removal or modifications in areas where people feel >>> strongly about. But even with those, I feel like this work is very much >>> doable. >>> >>> Best, >>> Haowen >>> On 11/8/2021 3:45 PM, Cale Gibbard wrote: >>> > The tricky thing is that while a new document describing the language in >>> > detail would be welcomed, it's hard for people to justify doing all the >>> > work that's involved in producing a new document that's substantially >>> > more helpful than the Haskell 2010 or '98 Report. Right at the moment, >>> > there's essentially one practically-usable implementation of the >>> > language, GHC (unless maybe you count GHCJS, and that's sharing GHC's >>> > frontend regardless). So the demand for a document that says what needs >>> > to be shared between implementations of the language is low. Personally, >>> > I think producing a description of what GHC is meant to be implementing, >>> > with as complete coverage of all the extensions as can be managed, i.e. >>> > a report, is something that would be quite valuable. However, that's a >>> > very large task, and most of the people who would be well-suited to >>> > produce that document have other constraints on their time. I don't >>> > think there's a pressing need for a normative standards document at the >>> > moment though. >>> > >>> > Maybe if some Haskell-using company were to get large enough to devote a >>> > team to working on a new general purpose Haskell compiler for some >>> > reason, or there was a big open-source push for a second Haskell >>> > compiler, there would be cause for a normative standard. But for now, >>> > everyone's been more or less content with working together extending GHC >>> > rather than building something entirely new. (I would have a fair amount >>> > of sympathy for someone wanting to start fresh though. I have my own >>> > list of reasons for which I can imagine wanting to take a shot at >>> > reimplementing the language, but I don't really have the time or energy >>> > for it myself.) >>> > >>> > For the descriptive side of things, most people get by right now with >>> > the GHC User's Guide, and failing that, there are often papers that go >>> > into much greater detail about the individual extensions. If you want to >>> > really understand the finer details of how those extensions all interact >>> > with one another though, there's presently nothing apart from the >>> > compiler itself (and even then, how they *ought* to interact is a >>> > different question from how they *do* interact). Understanding that and >>> > describing it all in a precise way is a big and difficult task, and it's >>> > one whose cost sadly might outweigh its benefits, especially if the >>> > progress toward a new Haskell Report is any indication. >>> > >>> > Even more, I think most would be delighted to see a denotational >>> > semantics for all of Haskell again. But it's one of those things which >>> > is difficult to produce in the first place, and then unless a process >>> > were in place to have it track the implementation, it would almost >>> > immediately fall out of date. >>> > >>> > That said, I can imagine there will be a point where the process to >>> > write a new Report kicks back off, I just don't think it's been at the >>> > forefront of most people's minds lately. >>> > >>> > - Cale >>> > >>> > On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime >>> > >> wrote: >>> > >>> > Hi, >>> > >>> > I hope this email finds you all well. I'm a newbie only starting with >>> > Haskell very recently, but I LOVE what I'm discovering with Haskell and >>> > its ecosystem. That's why I was shocked to see that the latest Haskell >>> > standard is still Haskell2010, and activities on this list has halted >>> > for 3 years. >>> > >>> > I skimmed through the Haskell2010 spec and understand deeply that the >>> > next Haskell standard will be an equally challenging enterprise. I, >>> > although yet to be sufficiently familiar with Haskell, want to let you >>> > all know that I'm hugely grateful for all the work you have done, and >>> > I'm more than willing to extend any kind of help moving forward with >>> > the >>> > next Haskell standard. If people are still interested in developing >>> > Haskell202X, and if people need some sort of secretary, editor, errand >>> > runner, or whatever, please let me know and I can help. >>> > >>> > Grateful, concerned, and eager to help, >>> > Haowen Liu >>> > _______________________________________________ >>> > Haskell-prime mailing list >>> > Haskell-prime at haskell.org > >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>> > > >>> > >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhw at lunacd.com Wed Nov 10 19:59:50 2021 From: lhw at lunacd.com (Haowen Liu) Date: Wed, 10 Nov 2021 11:59:50 -0800 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <010f017d0b4c9f4c-787c22bd-c4be-4e51-8ade-b37496d57cc8-000000@us-east-2.amazonses.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> <010f017d0b4c9f4c-787c22bd-c4be-4e51-8ade-b37496d57cc8-000000@us-east-2.amazonses.com> Message-ID: <736e39ea-8a18-8be3-8d3e-36500e5d2c79@lunacd.com> On 11/10/2021 11:21 AM, Richard Eisenberg wrote: > >> On Nov 9, 2021, at 11:26 PM, Haowen Liu wrote: >> >> And thank you for that link!! I did not know it existed! (Why would >> they put it under a separate GitHub organization? That's why I didn't >> find it LOL) >> >> > > That's a good question. I think we did it because it's a GHC-specific > process, not really about Haskell, per se. But it's also not in the > GHC org... which maybe it should have been. Where do you think would > be a good place to list this repo for other people like you to find it > in the future? I'm not sure honestly, but during my search I looked at README in the ghc repo and skimmed through the ghc GitHub org: https://github.com/ghc. I feel like either would be a great place for people to discover. (Sorry for the duplicate, but the last one was rejected by the mailing list because it was too long.) Haowen From lists at richarde.dev Thu Nov 11 19:36:07 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 11 Nov 2021 19:36:07 +0000 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <736e39ea-8a18-8be3-8d3e-36500e5d2c79@lunacd.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> <010f017d0b4c9f4c-787c22bd-c4be-4e51-8ade-b37496d57cc8-000000@us-east-2.amazonses.com> <736e39ea-8a18-8be3-8d3e-36500e5d2c79@lunacd.com> Message-ID: <010f017d10800d71-9c4112e2-862b-4658-95bf-2bb6825ffa1e-000000@us-east-2.amazonses.com> Great idea to link from the README: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6974 Thanks! Richard > On Nov 10, 2021, at 2:59 PM, Haowen Liu via Haskell-prime wrote: > > On 11/10/2021 11:21 AM, Richard Eisenberg wrote: >> >>> On Nov 9, 2021, at 11:26 PM, Haowen Liu wrote: >>> >>> And thank you for that link!! I did not know it existed! (Why would they put it under a separate GitHub organization? That's why I didn't find it LOL) >>> >>> >> >> That's a good question. I think we did it because it's a GHC-specific process, not really about Haskell, per se. But it's also not in the GHC org... which maybe it should have been. Where do you think would be a good place to list this repo for other people like you to find it in the future? > > I'm not sure honestly, but during my search I looked at README in the ghc repo and skimmed through the ghc GitHub org: https://github.com/ghc. I feel like either would be a great place for people to discover. > > (Sorry for the duplicate, but the last one was rejected by the mailing list because it was too long.) > > Haowen > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From lhw at lunacd.com Fri Nov 12 16:57:35 2021 From: lhw at lunacd.com (Haowen Liu) Date: Fri, 12 Nov 2021 08:57:35 -0800 Subject: Humble message of support and concern from an interested newbie In-Reply-To: <010f017d10800d71-9c4112e2-862b-4658-95bf-2bb6825ffa1e-000000@us-east-2.amazonses.com> References: <01d6db12-e0ec-1d09-5761-77c87e319aec@lunacd.com> <184b0975-c954-7328-b69e-902769164f85@lunacd.com> <010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com> <010f017d0b4c9f4c-787c22bd-c4be-4e51-8ade-b37496d57cc8-000000@us-east-2.amazonses.com> <736e39ea-8a18-8be3-8d3e-36500e5d2c79@lunacd.com> <010f017d10800d71-9c4112e2-862b-4658-95bf-2bb6825ffa1e-000000@us-east-2.amazonses.com> Message-ID: <9b405f53-5701-27cd-db4e-48cd363ec0dc@lunacd.com> That's great! Thank you so much! Haowen On 11/11/2021 11:36 AM, Richard Eisenberg wrote: > Great idea to link from the README: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6974 > > Thanks! > Richard > >> On Nov 10, 2021, at 2:59 PM, Haowen Liu via Haskell-prime wrote: >> >> On 11/10/2021 11:21 AM, Richard Eisenberg wrote: >>>> On Nov 9, 2021, at 11:26 PM, Haowen Liu wrote: >>>> >>>> And thank you for that link!! I did not know it existed! (Why would they put it under a separate GitHub organization? That's why I didn't find it LOL) >>>> >>>> >>> That's a good question. I think we did it because it's a GHC-specific process, not really about Haskell, per se. But it's also not in the GHC org... which maybe it should have been. Where do you think would be a good place to list this repo for other people like you to find it in the future? >> I'm not sure honestly, but during my search I looked at README in the ghc repo and skimmed through the ghc GitHub org: https://github.com/ghc. I feel like either would be a great place for people to discover. >> >> (Sorry for the duplicate, but the last one was rejected by the mailing list because it was too long.) >> >> Haowen >> >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime