- User Since
- Oct 7 2014, 12:13 AM (270 w, 5 d)
Dec 20 2015
- Add a test case for the modified IsString instance
- Add a note on the new IsString instance
Dec 19 2015
- Add @since for floating point expansion.
Dec 18 2015
Windows fixes are now in.
- Fix haddock formatting for log1p/mexp
- Fix building Floating expansion on Windows
Dec 17 2015
I don't know what a "note" is.
So, I've added documentation for the new methods. Unfortunately, I can't see what it looks like, because there appears to be a haddock bug in head that makes classes not have lists of the methods in them, and thus the documentation for those methods doesn't show up.
- Document new floating point functions.
Dec 12 2015
I don't. Making sure things built on Windows was also supposed to be someone else's job. I can't verify it myself.
I've added Float and Double implementations based on libm foreign imports.
- Implement libm-based Floating ops
Design is here, I'm just implementing it:
- Document Floating expansion in changelog
Dec 5 2015
10814 is the trac task. I thought I put that into arc, but it doesn't appear to show up anywhere here (except in the commit message).
Dec 4 2015
- Document IsString [Char] change in changelog.md
Nov 9 2015
Adding CLC acceptance (hopefully).
Aug 31 2015
Aug 29 2015
I think I agree with Richard. I can't think of a reason to use (unbound) variables other than for them to work as wildcards. But we have wildcards. So perhaps the current behavior is okay, or should be an error, rather than what I suggested.
Aug 28 2015
The examples involving type variables are odd. They should probably be generalized as part of the type ascribed to the function, and not as the argument. I.E. right now we have:
Jun 10 2015
The only thing that makes sense to me is that it doesn't make the decision on whether to inline (<*>) until ap is inlined, at which point it's too large. I'm not sure I knew it worked that way.
Jun 8 2015
Actually, now that I think about it, I think the allocation difference was that I implemented (<*>) for strict StateT instead of lazy. But it doesn't matter, because just inlining (<*>) = ap achieves parity.
Jun 6 2015
Okay. After further investigation, I have some results to report.
Now I'm not sure if my test case is demonstrating the same thing, because moving the mapM/traverse call out to a separate, noinline function in cryptarithm2 has no effect on the results.
Here's a simplified test case that may be relevant:
Oct 18 2014
Just wanted to make sure we considered the discrepancy.