On Nov 8, 2021, at 10:45 PM, Cale Gibbard <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
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> 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>>
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>
> 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
