> On Nov 9, 2021, at 11:26 PM, Haowen Liu <l...@lunacd.com> 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/ >> <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 <cgibb...@gmail.com >>> <mailto:cgibb...@gmail.com>> 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 >>> >>> <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 <l...@lunacd.com >>> <mailto:l...@lunacd.com>> 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 >>> > <haskell-prime@haskell.org <mailto:haskell-prime@haskell.org> >>> > <mailto:haskell-prime@haskell.org <mailto:haskell-prime@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@haskell.org <mailto:Haskell-prime@haskell.org> >>> > <mailto:Haskell-prime@haskell.org <mailto:Haskell-prime@haskell.org>> >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime> >>> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime>> >>> > >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org <mailto:Haskell-prime@haskell.org> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime> >>
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
