Humble message of support and concern from an interested newbie
Haowen Liu
lhw at lunacd.com
Wed Nov 10 04:26:07 UTC 2021
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 <cgibbard at 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
>> 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 <lhw at 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 at haskell.org <mailto: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 <mailto:Haskell-prime at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20211109/a92bf01b/attachment-0001.html>
More information about the Haskell-prime
mailing list