<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2021, at 11:26 PM, Haowen Liu <<a href="mailto:lhw@lunacd.com" class="">lhw@lunacd.com</a>> wrote:</div><div class=""><div class=""><p class="">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)</p><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>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?</div><div><br class=""></div><div>Thanks!</div><div>Richard<br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">BTW I just realized that my previous responses to Cale is sent
privately because I forgot to reply all... Sad...<br class="">
</p><p class="">Best,<br class="">
Haowen</p>
<div class="moz-cite-prefix">On 11/9/2021 7:57 PM, Richard Eisenberg
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:010f017d07fec246-7a517398-dc7a-487b-abce-0e017d3ceab4-000000@us-east-2.amazonses.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
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.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Thanks for your Haskell enthusiasm! If you do want
to see evidence of continued growth of the language's main
implementation, check out <a href="https://github.com/ghc-proposals/ghc-proposals/" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/ghc-proposals/ghc-proposals/</a>,
quite an active space of language design.</div>
<div class=""><br class="">
</div>
<div class="">Richard</div>
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 8, 2021, at 10:45 PM, Cale Gibbard <<a href="mailto:cgibbard@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">cgibbard@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">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.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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: <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst</a>
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.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class=""> - Cale</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 8 Nov 2021
at 21:41, Haowen Liu <<a href="mailto:lhw@lunacd.com" class="moz-txt-link-freetext" moz-do-not-send="true">lhw@lunacd.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi Cale and
others,<br class="">
<br class="">
Thank you Cale so so much for such a detailed
explanation!<br class="">
<br class="">
I agree with you that an evolving standard is only
useful as a <br class="">
normalizing force if we have multiple compilers,
like C/C++. Such is the <br class="">
same for the standard as documentation since GHC
documentation is really <br class="">
what people should refer to.<br class="">
<br class="">
I realize I'm in no way qualified to make those
points but in my meager <br class="">
experience with Haskell, an evolving standard could
serve as a very <br class="">
valuable verdict of the merits of various GHC
extensions. AFAIK, some <br class="">
GHC extensions are very widely adopted and some are
considered <br class="">
misfeatures. The Haskell202X could simply
incorporate a list of <br class="">
agreeable extensions into the core language and
those less agreeable <br class="">
ones could stay as extensions or whatever the GHC
community decides to <br class="">
do with them.<br class="">
<br class="">
I think such kind of Haskell202X is advantageous in
the following ways:<br class="">
<br class="">
1. It is less time consuming than radical language
changes. And the very <br class="">
fact that the Haskell202X effort is halted proves
that Haskell currently <br class="">
demands no radical changes (at least not the ones
that can't be <br class="">
implemented as a GHC extension).<br class="">
<br class="">
2. We no longer to enable a series of widely used
plugins. Many of the <br class="">
extensions integrate so nicely into the language
that I don't think <br class="">
programmers should be required to manually enable
them to use them. <br class="">
According to Sandy Maguire, "In GHC 8.6.5, there are
125 different <br class="">
language extensions, and an analysis shows that 10%
of Haskell files in <br class="">
the wild enable 10 or more extensions." [1]<br class="">
<br class="">
3. People are less likely to use those less
agreeable extensions because <br class="">
at that time enabling extensions would be a rare
case of workaround (as <br class="">
it should be, I believe) rather than a norm.<br class="">
<br class="">
4. It gives people, especially newcomers, a sense
that Haskell is still <br class="">
very much alive.<br class="">
<br class="">
In addition to integrating extensions, in very rare
cases, we could slip <br class="">
in some feature removal or modifications in areas
where people feel <br class="">
strongly about. But even with those, I feel like
this work is very much <br class="">
doable.<br class="">
<br class="">
Best,<br class="">
Haowen<br class="">
On 11/8/2021 3:45 PM, Cale Gibbard wrote:<br class="">
> The tricky thing is that while a new document
describing the language in <br class="">
> detail would be welcomed, it's hard for people
to justify doing all the <br class="">
> work that's involved in producing a new
document that's substantially <br class="">
> more helpful than the Haskell 2010 or '98
Report. Right at the moment, <br class="">
> there's essentially one practically-usable
implementation of the <br class="">
> language, GHC (unless maybe you count GHCJS,
and that's sharing GHC's <br class="">
> frontend regardless). So the demand for a
document that says what needs <br class="">
> to be shared between implementations of the
language is low. Personally, <br class="">
> I think producing a description of what GHC is
meant to be implementing, <br class="">
> with as complete coverage of all the extensions
as can be managed, i.e. <br class="">
> a report, is something that would be quite
valuable. However, that's a <br class="">
> very large task, and most of the people who
would be well-suited to <br class="">
> produce that document have other constraints on
their time. I don't <br class="">
> think there's a pressing need for a normative
standards document at the <br class="">
> moment though.<br class="">
> <br class="">
> Maybe if some Haskell-using company were to get
large enough to devote a <br class="">
> team to working on a new general purpose
Haskell compiler for some <br class="">
> reason, or there was a big open-source push for
a second Haskell <br class="">
> compiler, there would be cause for a normative
standard. But for now, <br class="">
> everyone's been more or less content with
working together extending GHC <br class="">
> rather than building something entirely new. (I
would have a fair amount <br class="">
> of sympathy for someone wanting to start fresh
though. I have my own <br class="">
> list of reasons for which I can imagine wanting
to take a shot at <br class="">
> reimplementing the language, but I don't really
have the time or energy <br class="">
> for it myself.)<br class="">
> <br class="">
> For the descriptive side of things, most people
get by right now with <br class="">
> the GHC User's Guide, and failing that, there
are often papers that go <br class="">
> into much greater detail about the individual
extensions. If you want to <br class="">
> really understand the finer details of how
those extensions all interact <br class="">
> with one another though, there's presently
nothing apart from the <br class="">
> compiler itself (and even then, how they
*ought* to interact is a <br class="">
> different question from how they *do*
interact). Understanding that and <br class="">
> describing it all in a precise way is a big and
difficult task, and it's <br class="">
> one whose cost sadly might outweigh its
benefits, especially if the <br class="">
> progress toward a new Haskell Report is any
indication.<br class="">
> <br class="">
> Even more, I think most would be delighted to
see a denotational <br class="">
> semantics for all of Haskell again. But it's
one of those things which <br class="">
> is difficult to produce in the first place, and
then unless a process <br class="">
> were in place to have it track the
implementation, it would almost <br class="">
> immediately fall out of date.<br class="">
> <br class="">
> That said, I can imagine there will be a point
where the process to <br class="">
> write a new Report kicks back off, I just don't
think it's been at the <br class="">
> forefront of most people's minds lately.<br class="">
> <br class="">
> - Cale<br class="">
> <br class="">
> On Mon, 8 Nov 2021 at 17:55, Haowen Liu via
Haskell-prime <br class="">
> <<a href="mailto:haskell-prime@haskell.org" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">haskell-prime@haskell.org</a>
<mailto:<a href="mailto:haskell-prime@haskell.org" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">haskell-prime@haskell.org</a>>>
wrote:<br class="">
> <br class="">
> Hi,<br class="">
> <br class="">
> I hope this email finds you all well. I'm a
newbie only starting with<br class="">
> Haskell very recently, but I LOVE what I'm
discovering with Haskell and<br class="">
> its ecosystem. That's why I was shocked to
see that the latest Haskell<br class="">
> standard is still Haskell2010, and
activities on this list has halted<br class="">
> for 3 years.<br class="">
> <br class="">
> I skimmed through the Haskell2010 spec and
understand deeply that the<br class="">
> next Haskell standard will be an equally
challenging enterprise. I,<br class="">
> although yet to be sufficiently familiar
with Haskell, want to let you<br class="">
> all know that I'm hugely grateful for all
the work you have done, and<br class="">
> I'm more than willing to extend any kind of
help moving forward with<br class="">
> the<br class="">
> next Haskell standard. If people are still
interested in developing<br class="">
> Haskell202X, and if people need some sort
of secretary, editor, errand<br class="">
> runner, or whatever, please let me know and
I can help.<br class="">
> <br class="">
> Grateful, concerned, and eager to help,<br class="">
> Haowen Liu<br class="">
>
_______________________________________________<br class="">
> Haskell-prime mailing list<br class="">
> <a href="mailto:Haskell-prime@haskell.org" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">Haskell-prime@haskell.org</a>
<mailto:<a href="mailto:Haskell-prime@haskell.org" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">Haskell-prime@haskell.org</a>><br class="">
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br class="">
> <<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a>><br class="">
> <br class="">
</blockquote>
</div>
</div>
_______________________________________________<br class="">
Haskell-prime mailing list<br class="">
<a href="mailto:Haskell-prime@haskell.org" class="moz-txt-link-freetext" moz-do-not-send="true">Haskell-prime@haskell.org</a><br class="">
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></body></html>