- User Since
- Sep 5 2014, 5:38 PM (180 w, 1 d)
Fri, Feb 16
I'm a bit nervous about the known fragility of the test. I'm a bit more concerned about the fact that this depends on an ever-shifting external library—what does this test actually test?
Thu, Feb 15
If it passes validation, LGTM.
Wed, Feb 14
Tue, Feb 13
Fix parse error
Blast. I'll fix them tomorrow.
Mon, Feb 12
Use INLINABLE instead of INLINE, as mpickering requests. Doing both
that and the eqTypeRep/sameTypeRep split seem to get GHC to produce
a nice small unfolding for eqTypeRep. Doing either alone doesn't cut it.
Sun, Feb 11
In principle, we should probably be able to do slightly better by using 0# and 1# instead of True and False in the result of sameTypeRep. But I don't know if it's worth the mess.
Fri, Feb 9
Thu, Feb 8
Note in change logs
Mon, Feb 5
Sun, Feb 4
Wed, Jan 31
Where are the new things? Some other repo?
Tue, Jan 30
Could you rebase this please?
Sat, Jan 27
@bgamari, this is ready to go.
Fri, Jan 26
Rebase against last commit that builds
Update test results; rebase
Tue, Jan 23
Ah. I didn't even know there'd been churn; I just wanted to make sure there wouldn't be.
One question: how do you sort the results that are not comparable? Is that strong enough to avoid test case churn?
Mon, Jan 22
Two of the backpack test failures are from the containers version changing. I have no clue what the other one is about. Please advise.
I'll give it a go.
I doubt this matters in practice, but it's best to set a good example in base.
Sun, Jan 21
This needs further consideration to figure out to what extent (if any) it's a good idea.
Jan 17 2018
I'm going to work on this more today. Both trying to track down the numbers
Simon wants and trying to work out which are worth deriving. It's hard to
use hand-written examples with things large enough to measure.
Jan 16 2018
I mean probably shouldn't derive gmapQl. Just guessing anyway.
So far, I'm not getting good performance. I think simplification is faster but type checking is slower. I wonder if some methods are more helpful to derive than others. First guess: we probably should derive gmapQi, and probably shouldn't derive gmapQr. I wonder if gmapT should be defined in terms of gmapM.
Dec 27 2017
Dec 18 2017
Dec 14 2017
Dec 13 2017
Dec 12 2017
I'm not sure killing this off entirely is the right approach. Perhaps it would be better to rename and rephrase; I believe this is really about pattern bindings, not irrefutable patterns. Just killing this off leads to some messages that don't read very well. "Pattern Just p' failed to match in pattern binding" strikes me as better than "Non-exhaustive patterns in Just p'".
Update test results
Dec 11 2017
The slow validation failures @carlostome saw had nothing whatsoever to do with this patch. I
have started working on pinning down where they showed up, but I haven't gotten far yet.
- Add a couple comments
Oh, what fools we mortals be! @carlostome, your assertion failures seem only to happen
Dec 7 2017
That's quite a large test file! Would calculating it modulo a moderately large prime distinguish between the holy and the broken?
Must add test output.
Could the remaining assertion (about compacts) be changed to produce a clearer error message?
Dec 5 2017
The other option would be to encode the non-ASCII character in some fashion, however make prefers. But that seems less clear.
Dec 4 2017
Dec 1 2017
Update changelog; add note
If possible, it would be nice to commit the new tests before committing the real changes; that way the commit will clearly demonstrate what's changed.
Improve error message for redundant Con/Con'
Nov 29 2017
Add further documentation
Address comments; adjust test results; rebase
Nov 27 2017
- Make -fignore-...-changes the default for GHCi
Abandoned in favor of D4085.
Nov 23 2017
Nov 17 2017
Rebase; fix up test results
Nov 16 2017
Fix Constraint vs Type problem
Nov 15 2017
This runs into a Constraint vs. Type problem. Presumably isLiftedTypeKind is the wrong test? What's the right one?
Rebase; rename constructors
A silly question: why do we use lists for the KindRep and TrTyCon business rather than dealing exclusively with arrays? And why do we use Array for it rather than SmallArray#; that would seem slightly lighter, and we're not doing enough array manipulation to feel the pain of a low-level interface.