In its current form, does it validate? If so, let's merge it. 8.8 is nigh, and it's best to get this out the door. However, even after merging, we should continue to press forward with some of the tweaks suggested in this thread. My and I will discuss in person later this week. In the meantime, My, report if it validates; when it does, let's just pull the trigger.

We can get a precise answer by looking at the intersection of what checkPattern and checkExpr accept.

With commands, we need to look at the intersection of what checkPattern, checkExpr, and checkCommand accept. And when I get to unifying term/type parsers, also checkType (not currently defined).

👍

OK. I've exhausted my time budget for this today, but I'll keep this in my queue. Sad to say, but I likely won't get to it for a few days.

I've taken my pass, but I skipped the following:

• TH (Thanks, @RyanGlScott)
• Parser (Thanks, @int-index)
• Test output in partial-sigs, thinking that my suggested change to addTypeCtxt will take care of it.

I'm late to this conversation, and I haven't looked at the code -- only the conversation. Here are my thoughts:

I do intend to take a close look at this, but it likely won't happen until after classes end, in about 2 weeks.

They can appear in the kinds of promoted data constructors, say from GADTs with hand-written equality constraints.

Looking at the relevant bits of the Monster Patch, it looks like these constraints are eliminated simply in the validity checker. That is, equality constraints in kinds still work, but now the user can't write them. By "work", I mean that tcInstTyBinders does the right thing. It looks like this from the code, but I'm just double-checking my understanding.

We might want to update this approach if/when Trac #12363 ever gets implemented.

Sharing comments for call Simon and I are having.

More from SPJ.

More later!

More updates from Simon.

LGTM.

In D5282#146871, @simonpj wrote:

make all binders in a representation TyCon into Specified, at birth

More commits from Simon:

This looks like it works, but I think it can be refactored to be simpler. Thanks!

Out of time now; more later. (Note to self: I read through files before TcHsType, kcImplicitTKBndrs but not kcLHsQTyVars; also read through TcMType)

LGTM.

Not from me. Ship it!

Yes!

I've commented on the ticket, as that seems a better place than here.

I have a hunch that this might also fix Trac #15852.

Committed: 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3

Committed: 4427315a65b25db22e1754d41b43dd4b782b022f

Thanks for the quick action here!

I may not get a chance to cycle back to this one. If it validates, please merge. Thanks.

Get quantification right, for once.

Thanks!

In D5229#144555, @Iceland_jack wrote:

I discovered a potential bug, minimized by Ryan

In D5229#144558, @Iceland_jack wrote:

Is using kind application in data declarations; data El @k ..., wanted. Currently rejected

In D5229#144499, @RyanGlScott wrote:

I thought so too... but it turns out that the [renamer turns the [] HsVar into an ExplicitList](http://git.haskell.org/ghc.git/blob/46f2906d1c6e1fb732a90882487479a2ebf19ca1:/compiler/rename

Just update a comment as my comment below, then feel free to push.

I still say that I'm unbothered by the examples Ryan writes.

In D5229#144361, @RyanGlScott wrote:

1. The following code produces a GHC panic:

For T13524, you can apply this diff:

Very nice work. Almost all of my comments are about style/commenting -- very few functional changes to make.

Ah. Much better. Thanks. See one comment below.

Just checking in here -- @mayac, you're planning on updating the behavior around warnings and then we'll be good to go?

Broadly looks good, but I would change the way that the traversal function works to just return a Bool (as commented below). Thanks!

• Wibbles suggested by Simon

Well, that was easy.

This is still under active work. I understand parts of Trac #14880 have been merged and will deal with that in due course.

In D5206#143964, @mniip wrote:

Well then, any further comments on the patch?

LGTM. Thanks!

You're worried about the haddock performance test? Don't be. I've seen that test failing for some time.

I haven't thought deeply about the technical change here, but it all seems very plausible, Ryan seems confident, and I trust Ningning's analysis of this. So all that adds up to a +1 from me.

A little more bugfixing.

And I'll look into your comment about variable ordering. Thanks for pointing this out.

I like this fix. Minor wibbles suggested below. Thanks!