- User Since
- Jun 13 2014, 11:18 AM (235 w, 3 h)
Mon, Dec 10
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:
Sun, Dec 9
I'm late to this conversation, and I haven't looked at the code -- only the conversation. Here are my thoughts:
Mon, Dec 3
I do intend to take a close look at this, but it likely won't happen until after classes end, in about 2 weeks.
data T a = Eq a => MkT
Fri, Nov 30
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.
Sat, Nov 24
We might want to update this approach if/when Trac #12363 ever gets implemented.
Wed, Nov 21
Sharing comments for call Simon and I are having.
More from SPJ.
Mon, Nov 19
More updates from Simon.
Sun, Nov 18
Nov 14 2018
Nov 12 2018
More commits from Simon:
This looks like it works, but I think it can be refactored to be simpler. Thanks!
Nov 7 2018
Out of time now; more later. (Note to self: I read through files before TcHsType, kcImplicitTKBndrs but not kcLHsQTyVars; also read through TcMType)
Nov 5 2018
Not from me. Ship it!
Nov 2 2018
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.
Nov 1 2018
Oct 29 2018
Oct 28 2018
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.
Oct 27 2018
Oct 26 2018
Oct 22 2018
Oct 21 2018
Oct 19 2018
Oct 18 2018
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.
Oct 17 2018
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!
Oct 15 2018
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.
Oct 14 2018
You're worried about the haddock performance test? Don't be. I've seen that test failing for some time.
Oct 11 2018
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.
Oct 8 2018
Oct 7 2018
And I'll look into your comment about variable ordering. Thanks for pointing this out.
Oct 5 2018
I like this fix. Minor wibbles suggested below. Thanks!