As usual, I want to separate out the specification of a feature from the
implementation. So let's just focus on specification for now -- with the caveat
that there might be no possible implementation of these ideas.
The key innovation I see lurking here is the idea of an *exhaustive* function,
>
>* Upstream changes into Cabal to make your new compiler a first-class
> citizen. This is what GHCJS did.
Just a word of caution, please don't do this. It leads to non-negligible
maintainence burden on your and on the cabal side. Rather try as hard as
you can to make your compiler
Clinton Mead writes:
> Thanks again for the detailed reply Ben.
>
> I guess the other dream of mine is to give GHC a .NET backend. For my
> problem it would be the ideal solution, but it looks like other attempts in
> this regard (e.g. Eta, GHCJS etc) seem to have difficulty keeping up with
>
Hello everyone,
At this point the ghc-9.2 branch has officially branched off from master.
If there was anything you were holding back from `master`, feel free to
now send it off to Marge.
I'll be working on doing some release prep and pushing out an alpha in
the next few days. This alpha will
I haven't thought about how to implement such a thing. At the least, it would
probably require some annotation saying that we expect `\HNil -> ()` to be
exhaustive (as GHC won't, in general, make that assumption). Even with that,
could we get type inference to behave? Possibly.
As I wrote in
On Sun, Mar 28, 2021 at 11:00:56PM -0400, Carter Schonwald wrote:
> On Sun, Mar 28, 2021 at 10:19 PM Richard Eisenberg wrote:
>
> > I think this is the key part of Alexis's plea: that the type checker take
> > into account exhaustivity in choosing how to proceed.
> >
> > Another way to think
