- User Since
- Jun 9 2014, 9:34 AM (235 w, 4 d)
This is all a great improvement.
Wed, Dec 12
Looks good, thanks. I suggest a minor refactoring
Mon, Dec 10
Unfortunately, while do or let cannot be used in patterns, they can be used in commands, so we end up duplicating most of HsExpr constructors for the sake of HsCmd. If not for this, we'd be able to make ExpPatFrame smaller.
Thanks for doing this
The new datatype is entirely local to the parser. This is in contrast to the other GhcPasses which communicate between phases of the compiler.
Fri, Dec 7
I'm worried about these gigantic instance contexts. I don't understand your suggested solution yet, Vladislav; could you give a concrete example?
I expect each pass to be aware only of its input and output structures:
Thu, Dec 6
Does this sound reasonable?
Let's land this!
we would create a new stage GhcPrePs for it.
Generally looking good. A few suggestions.
Is this in-flight or do you consider it done? If the latter I will gladly have a look. Thanks!
Wed, Dec 5
Looks good to me. Please create a ticket, though, describe the idea, and put the perf-change data in it.
Then you can refer to the ticket from the one-line code change.
I think I'll just go with this and save the refactoring for the next time I'm on a transatlantic flight.
Tue, Dec 4
Examples would take up a lot of space. Would it be fine to insert about 2 pages of comments for this minor addition?
At least to be merged after the bugs listed in my first comment are fixed, and syntax is decided,
Mon, Dec 3
generally looks ok to me, thank you. (Although I have not checked every line.) Ben: merge this?
Sat, Dec 1
Fri, Nov 30
They can appear in the kinds of promoted data constructors, say from GADTs with hand-written equality constraints.
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.
Great! I had quite forgotten that bit of the monster-patch. I hope Richard agrees!?
Thu, Nov 29
Wed, Nov 28
Tue, Nov 27
Mon, Nov 26
Alan, could you write a Note or wiki page or something explaining
Yes, fine with me, thank you.
Sat, Nov 24
Fri, Nov 23
You are mistaken here
Good points Ryan.
Thanks for the help. Some rejoinders inline
I'm content to commit this. It's a significant piece of code, and I have not reviewed it in detail. But it's completely separable from everything else; it only runs with -O2.
Great. Looks good to me.
Tue, Nov 20
Gah! I wrote this response a day or two ago but forgot to press Submit!
Mon, Nov 19
Fri, Nov 16
Great. Aside from the changes I suggest in other comments, good to go.
I don't know about this dead-default-binder business. Don't we need dead-var info for _every_ variable? Case-binders are just a special case. Reason: after a case-expression, avoid loading the field from the constructor into a register.
Thu, Nov 15
Nov 14 2018
I'm not sure how it would be possible to get rid of the visibilities. Data family instance representation TyCons are, well, TyCons, and all TyCons have TyConBinders (which have visibilities). To me, this suggests that having visibilities is an essential property of being a data family instance representation TyCon. But perhaps I'm missing something.
Nov 13 2018
Had a better idea!
I'll vote for "do it in another patch", s
Great. Modulo a couple of suggestions.
Every individual FastString has a unique id in it
I also want to point out that CoreToStg isn't as simple as it could be: When trying to remove FreeVarInfos altogether, I realised that it still uses it at least for stuff like occurrence info
Nov 12 2018
Looks great -- but see my comment on annTopBindingsFreeVars
Nov 9 2018
Lovely thank you
I'm fine with this, thanks. Some comments above
Nov 7 2018
One more thing. I've come across your Note [Use TyVarTvs in kind-checking pass] in TcTyClsDecls. I have not changed anything to do with this.
Thanks! I've responded
I should add that this patch validates.
Nov 6 2018
Omer, is this good to go? If so, commit!
Nov 5 2018
Nov 1 2018
Oct 31 2018
OK, I'm content, thank you
Generally great, thank you. One puzzlement.
Edit: Now that I've read your comment on the ticket, it's clear you are talking about a note.
Oct 26 2018
I have not read the code in detail, but broadly it looks fine.