> 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

Reply via email to