ionfish
Joined 18 years ago
Joined 18 years ago
I'm not sure the author's explained this point quite as clearly as it could have been. One doesn't want to expose every type used in the program across all modules: there are many that are just used in internal representations within particular modules.
Here's an example from a project of mine, which is a command line program to produce truth tables. There's a Core module which contains the types shared across the whole program, and the most fundamental operations on them.
https://github.com/beastaugh/hatt/blob/1.5.0.3/src/Data/Logi...
Then there are other modules like Parser which just exposes a single function, but of course makes use of the core types.
https://github.com/beastaugh/hatt/blob/1.5.0.3/src/Data/Logi...
The command line program itself is defined as a Main module, which imports the pure library modules and does all the I/O. It has a few types of its own but these aren't shared across the program, because the library doesn't need to know about all this stuff.
http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/code-...
"[The LLVM backend] is an alternative backend that uses the LLVM compiler to produce executable code. It generally produces code as with performance as good as the native code generator but for some cases can produce much faster code. This is especially true for numeric, array heavy code using packages like vector. The penalty is a significant increase in compilation times."
As far as Tychonoff's theorem goes, you might find this paper interesting:
* Let X and Y be sets. Then either they have the same cardinality, or one is smaller than the other.
* Let X be an infinite set. Then there is a bijection between X and the cartesian product of X with itself, X × X.
* Tychonoff's theorem: every product of compact topological spaces is compact.
* * *
Offloading computation only works when you understand what the computations are and why we do them. That's something that must be learned, it's not knowledge that springs fully formed into our minds as soon as we step into a classroom.
Carrying out computations thus gives us explicit and implicit knowledge of how the things we may eventually automate actually work. But it's also valuable because it trains us to compute in a precise and effective manner—a capability that remains useful later on. For instance, in logic it's often important to be able to carry out syntactic manipulations (e.g. into normal forms) in one's head, or even tacitly.
I'm sure there are plenty of examples from other areas of mathematics where computation is important, it's just that we do it so automatically that we don't think about it. Often I've found that students have trouble following proofs that take logically and computationally innocent steps without saying what's going on. Here I don't mean things like applying AC in the background, but just simple tricks like de Morgan's laws or taking the contrapositive. They have difficulty because they haven't taken those steps often enough themselves to have internalised them.
http://en.wikipedia.org/wiki/Axiom_of_choice#Equivalents
Something I find pretty interesting is that some of these equivalences break down in weak systems.
http://www.math.uchicago.edu/~antonio/RM11/RM%20talks/mummer...
http://en.wikipedia.org/wiki/Cantor–Bernstein–Schroeder_theo...
That being said, although important in the theory of the order of the cardinal numbers, Cantor–Schröder–Bernstein doesn't show that the cardinals are totally ordered. That statement is actually equivalent to the Axiom of Choice, whereas as far as I'm aware Cantor–Schröder–Bernstein holds in ZF.
http://www.danzigercartoons.com/archive/cmp/2002/danziger141...