- User Since
- Jun 9 2014, 9:34 AM (245 w, 4 d)
Wed, Feb 20
Sigh. There has to be a better way than this. Send mail to me personally at email@example.com and I will act as your personal mail forwarding agent and fwd it to ghc-devs
I'm not sure what the protocol is these days. Can you ask for help on ghc-devs?
Thanks! Go for it!
Accepting -- use your judgement in deciding how/whether to respond to my suggestions.
Lovely. Some minor suggestions.
Mon, Feb 18
Sorry not to be clear! I meant that I don't like a comment that says "I don't know why this code is right, but it's the same as that code over there, which also lacks any comment". Clearly the right thing is to add the missing comment which I have done in
I don't like having comments like this! We should fix the original problem.
The inline principle for @zipWith3M@ and @zipWith3M_@ is the same as for zipWithM' and 'zipWithM_' in "Control.Monad". No comment or explanation is given in that module as to why 'zipWith' has an @INLINE@ pragma, but it stands to reason that if it was added in the past and not removed or addressed in any way, it is overall useful (but still undocumented, which would be nice to address).
I'll push a patch and you can then change this one to refer to the new Notes in my patch
Wed, Jan 30
Mon, Jan 28
I have not been following the details here, since Richard has been On The Job. But it'd be good for me to do so before we finally pull the trigger.
Jan 22 2019
PS the commit is
commit 2257a86daa72db382eb927df12a718669d5491f8 Author: Simon Peyton Jones <firstname.lastname@example.org> Date: Wed Nov 28 16:06:15 2018 +0000
Jan 16 2019
I'm not sure how WARN gets handled by the compiler, but my suspicion is that the warning is silently discarded. So the question is, what's the right thing to do here?
Jan 10 2019
ok. There are some other comments you might want to address when you finalise
Jan 8 2019
Where are we on this work? I've gotten lost? If not complete, perhaps it would be helpful to summarise the state of play, with pointer to the key Notes, wiki pages, or whatever? Thansk!
Bother. I did type in a comment, but somehow it got lost. Anyway: go for it!
Jan 7 2019
Sorry to be so slow.
Jan 4 2019
Looking good! Richard's comments are spot on.
Dec 24 2018
I don't think we need CAF-info on non-top-level Ids. Here is why.
One suggestion. Somewhat a matter of taste I suppose.
Dec 21 2018
Looking good! Some small suggestions for Matthew
Since coerce inlines to coerce# in every phase,
But don't we still need to do that for imported Ids?
Why not just change vanillaCafInfo
I might be missing something, but how does that prevent us from accidentally using the CafInfo from the occurrence Id?
I don't think this works - for imported Ids we need to get the CafInfo from the Id and put it in the IdLabel.
So I think this is OK, but worth a comment somewhere.
Dec 20 2018
Why do we need CafInfos in a TypeEnv? I'd expect TypeEnv to be used for type checking, which shouldn't need CafInfos.
I think there may be more uses of idCafInfos. Simply searching in the source code shows that
PS: One other thing to check.
Hang on. updateStgCafInfos puts CAF info into the IdInfo of a binder. But who looks at that info? I guess:
Dec 18 2018
I will have to explore, thank you for this interesting thought. Maybe we'll end up with something small after all.
@simonpj Can we merge this, unless you have more questions/objections?
Dec 13 2018
This is all a great improvement.
Dec 12 2018
Looks good, thanks. I suggest a minor refactoring
Dec 10 2018
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.
Dec 7 2018
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:
Dec 6 2018
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!
Dec 5 2018
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.
Dec 4 2018
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,
Dec 3 2018
generally looks ok to me, thank you. (Although I have not checked every line.) Ben: merge this?
Dec 1 2018
Nov 30 2018
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!?
Nov 29 2018
Nov 28 2018
Nov 27 2018
Nov 26 2018
Alan, could you write a Note or wiki page or something explaining