-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathTODO
67 lines (43 loc) · 3.23 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
* Update this TODO file to only include things that are actually still relevant
== ... ==
* Use pointless-fun instead of our own definitions.
* Maybe use lattice:Algebra.PartialOrd instead of our own.
* Combine the test suite into a single executable and then do:
$> darcs setpref test "runhaskell Tests.hs"
* Also, tell Setup.hs so that `cabal test` and `runhaskell Setup.hs
test` call the test suite.
* As of GHC-7: "The registerised via-C backend, and the -fvia-C flag, have been deprecated. The poor floating-point performance in the x86 native code generator has now been fixed, so we don't believe there is still any reason to use the via-C backend."
http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html
== Portability ==
* Cabal+Hugs: how to do the right thing re __HUGS__, cpphs,...?
* BUG ghc6.10.1 (not in 6.8; fixed in 6.10.2): Cannot mix -fvia-C with the FFI.
<http://hackage.haskell.org/trac/ghc/ticket/3117>
* Switch to -fasm for 6.10.1?
* Do benchmarking for whether we should use -fasm, -fllvm, etc for ghc6.12
* Windows+ghci issues with FFI(ccall vs stdcall??). ghc itself is fine.
* instance Storable LogFloat for Hugs (and nhc98/yhc, jhc/lhc)
* instance IArray UArray Logfloat for nhc98/yhc, jhc/lhc
* check whether IArray.numElements method exists in nhc98/yhc, jhc/lhc
* check the inlining behavior of the four LogFloat cons/destrucors (see the note in LogFloat.hs)
* If the cmath package ever adds log1p/expm1 then consider depending on it instead of rolling our own?
* Fink's latest Hugs (1998.200102-1017) package doesn't have ffihugs. It's also Feb2001 which is five years older than the latest (4-years-old) release! Need to bug the maintainer. Of course Feb2001 doesn't support hierarchical module names either, so the ffi is the least of our worries.
== Functionality ==
* Add a signed variant
* Add "safe" FFI version for multithreaded users?
* Find out if it actually affects performance. It'd only apply to uses of (+) and (-) which are already horribly slow...
* (?)Rename "Transfinite" to "Limited" in order to make it clearer that we're not dealing with infinite ordinals nor cardinals. Our infinities are limits on the underlying order.
* Move Data.Number.PartialOrd -> Data.Ord.Partial
* Replace OverlappingInstances with a newtype wrapper?
== Debugging ==
* The Nothing branch in the PartialOrd LogFloat instance should be unreachable. Once we get a test suite up and going to *verify* the never-NaN invariant, we should be able to eliminate the branch and the isNaN checks.
* Add some unit tests for regression checking
- but beware of the fuzz
- Make sure to test transfinite values everywhere in Hugs!
* Verify that the current instance is entirely strict
- verify that things unpack into registers (how?)
* Profile or look at Core to make sure we do not waste too much time constructing dictionaries. If so, reconsider the four smart constructors/destructors.
* Make sure rewrite rules really fire
-- To turn on optimizations and look at the optimization records, cf:
-- http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html
-- http://www.randomhacks.net/articles/2007/02/10/map-fusion-and-haskell-performance
-- {-# OPTIONS_GHC -ddump-rules -ddump-simpl-stats #-}