Number Theory as Compiler OptimizationsOleg Kiselyov wrote a paper about generating optimal code.
I think this is the connection between number theory and compiler optimizations. The curry howard isomorphism says that proofs are programs, so number theory is then optimizations, right?
Oleg's paper sticks in my head. I believe that the future of compilers is a single-pass principled search that generates optimal code.
Being better than others is not a high aim, being better than yourself is. -- Shae Erisson
More info on the predecessor post, Free Algebras divide ordering and non-ordering monads?
<Cale> shapr: well, it's a lot like the explicit recursion of types construction
<Cale> newtype Mu f = In (f Mu f)
<Cale> newtype Mu f = In (f (Mu f))
<Cale> shapr: it's basically the same trick as y f = f (y f), but at the type level
<Cale> data N c = Z | S c
<Cale> type Nat = Mu N
<Cale> So here, we're not using plain Mu
<Cale> but something with a little more structure
<Cale> shapr: it appears not every monad is isomorphic to one which is free -- in particular, it doesn't seem possible to construct the list monad.
<shapr> Cale: Ok, how can I tell which ones are isomorphic, and which ones aren't?
<Cale> shapr: If you find that you need the type parameter to the monad when constructing your signature type, then it seems impossible
<Cale> shapr: Try creating the list monad in that framework and you should get it pretty quickly :) We'd kind of like 'a' to get passed to sig in Expr
<Cale> but this screws up all the kinds, so some rethinking is necessary :)
<Cale> *Main> (foldr mplus mzero . map return) [1,2,3,4,5] :: FreeMonad TreeSig Integer
<Cale> Expr (Branch (Return 1) (Expr (Branch (Return 2) (Expr (Branch (Return 3) (Expr (Branch (Return 4) (Expr (Branch (Return 5) (Expr Leaf))))))))))
<Cale> hehe, getting mplus to autobalance the tree would be harder :)
* Cale wonders about what kinds of functors naturally give rise to MonadPlus instances
Jim Apple asked me why I don't have a projects page on my blog or website. Since my only answer is that I just hadn't thought of it, I shall now include a list.
I've been the maintainer of the Haskell Wiki since the 16th of February 2004.
I've been the editor of The Monad Reader since it started, probably about February 2005.
I started the HaskellIrcChannel in April of 2001 and have maintained it since.
I started and sort of dropped haskell-libs, a sourceforge project to collect code for easy finding.
I'm working on Fermat's Last Margin, a distributed research paper annotation tool.
I started (and dropped) combinatorrent, a bittorrent implementation in Haskell. jlouis picked up the idea with conjure.
I worked on Yi for a bit, I'd still like to use it instead of emacs.
I maintained and extended lambdabot for years. Don Stewart became maintainer some time ago.
I wonder if I've missed anything?
How to fit concurrency ideas from Erlang, Nesl, and Sisal into a single proposal for Haskell prime?
I've discovered that I want concurrency as part of Haskell. I'd really like a single concept that integrates both multicpu parallelism and across the network distribution.
So my current theory is a thunk is the basic unit of distribution, and each thunk should include E style permissions. The language should not rely on a thunk returning, thus representing network or component failure.
I had an idea when reading the SMP GHC paper... could there be multiple equal thunks to eval at once?
For example, (1 + (2 + 3)) could also be ((1 + 2) + 3). If so, turn 'equal thunks' into orElse with STM?