- User Since
- Jun 9 2014, 9:34 AM (286 w, 6 d)
Fri, Dec 6
Sat, Nov 9
Nov 1 2019
Oct 28 2019
Oct 12 2019
Sep 30 2019
Sep 21 2019
Sep 19 2019
Sep 17 2019
Sep 13 2019
Aug 6 2019
Aug 4 2019
Jul 30 2019
Jul 12 2019
Jul 9 2019
Jul 4 2019
Jun 19 2019
Jun 7 2019
Mar 26 2019
@RyanGlScott, @simonpj, @goldfire, what should we do with this differential? It looks like there are valuable review comments here that would be good to preserve until the patch is landed but it's not clear to me how close we are to being able to do so.
Mar 16 2019
Mar 15 2019
Mar 12 2019
Mar 10 2019
Mar 9 2019
Mar 7 2019
Mar 5 2019
Mar 4 2019
Feb 20 2019
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.
Feb 18 2019
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
Jan 30 2019
Jan 28 2019
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?