Circular programming in Haskell for an imperative programmer

I’ve been learning up on arrows as a good framework to create my robot control software for Maya. I need the ability to manage a large amount of code and conciseness and modularity is paramount. Arrows seem very natural to model stream/dataflow operations and you can compose actions with any custom vocabulary.
While I was learning, I came across ArrowLoop typeclass, that extends looping in Arrows. This is how it is defined:
class Arrow a => ArrowLoop a whereloop :: a (b, d) (c, d) -> a b c
 Looking at the type signature of loop, it looks like it takes an arrow has inputs (bd) and outputs (c,d). So far so good. The output of this function seems to have no mention of d. The implementation of this function takes d from the output, and feeds it back into the input!
What does it mean to have the output fed back to a function as the input?
Searching for this led me to this page, which does a pretty good job of telling you what it does. Specifically, their example is a good place to start. Its simple and easy to follow:
data Tree a = Branch Tree Tree | Leaf a
trace :: (input -> feedback -> (output, feedback)) -> input -> output
trace f input = let (output, feedback) = f input feedback
in output
repmin :: Ord a => Tree a -> Tree a
repmin = trace repIImin
repIImin :: Ord a => Tree a -> a -> (Tree a, a)
repIImin (Leaf minval) rep = (Leaf rep, minval)
repIImin (Branch left right) rep = let
(left', min_left) = repIImin left rep
(right', min_right) = repIImin right rep
in (Branch left' right', min min_left min_right)
repmin takes a value of type Tree as input and outputs a Tree with the same structure as the input, but with the values of the leaves replaced with the min val of the leaves of the input tree. Note that trace is similar to loop(from ArrowLoop), in that the given function f is invoked with a variable from its output (feedback).
There is an explanation given for how repmin works with trace, but for some reason, the explanation left me unsatisfied. It told me how to think of the feedback variable (d), but didn’t explain how the computation actually occurred/how the program was actually executed. Coming from a imperative programming background, it is important to me to know how the program is executed. So here’s my explanation about how the program functions:
The important thing is to notice how a compiler/interpreter of Haskell will run the code in trace. It will notice that the variable in function application of f also appears on the output bindings. Haskell being a lazy language, feedback is a boxed value that will at any point in time either contain either an actual value, or a thunk (piece of code) that will compute the value. At the beginning of program execution,
thunk_feedback = snd thunk_f_app
thunk_f_app = f input thunk_feedback
where thunk_f_app is the thunk for the function application in trace (f input feedback). I left out thunks for input, f, snd for brevity. Now the program makes sense, as what you’re really doing is replacing the values in leaves with the feedback (i.e. they all now share a reference to the feedback thunk) and the top most Branch/Leaf in the input tree sets the value/thunk for feedback. A simple (possibly incorrect) way to think about this in an imperative context is to imagine setting the Leaf value as a pointer to feedback, whose value is being computed while the tree is traversed.
Lets run through a simple example. Here’s a tree with one branch and two leaves:
After we’ve repmin’ed it, here’s how the new tree looks like:
<feedback> is the feedback thunk, which when forced to evaluation, will evaluate to (min a b).
The trick to using trace here is that the code never looks into feedback, it merely uses it as a reference, until its value is actually set, which in repmin is just before the function returns. If we did look into feedback while in repmin, we would end up looping to infinity(non termination). There are cases when we can look into the value, provided we only look at parts that have been already calculated. Constructors can serve as evaluation barricades, letting you only evaluate/see parts you want and ignore others.

Num a ~ Integer / default instance in GHC

Making a library such as cadsim, one encounters the need to provide functions that accept numbers. For example, consider a function like this one:

-- |Moves pointer left, drawing a line
left :: (Convertible a Double) => a -> PathBuild ()
The logic being that I could perhaps take any input that would have an instance. This would let me create instances for say Int, Double, Float. But this would also let me create instances for newtype types that have an explicit unit.
For example:

newtype MM = MM Double
mm = MM

class Convertible a where
conv :: a -> Double

instance Convertible MM where
conv (MM n) = n

instance Convertible Int where
conv = realToFrac

left (mm 35) -- works
left 35 -- error!
The last entry wont work!

Ambiguous type variable `a0' in the constraints:
(Num a0) arising from the literal `1' at :0:6
(Conv a0) arising from a use of `left' at :0:1-4
Probable fix: add a type signature that fixes these type variable(s)
In the first argument of `left', namely `1'
In the expression: left 1
In an equation for `it': it = left 1
Why not? The message is quite explanatory, albeit cryptic.
To find out, lets fire up ghci and see what it thinks about the types of the last line.

GHCi, version 7.2.2: :? for help
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> :t left
left :: Conv a => a -> Double
*Main> :t 3
3 :: Num a => a
Aha! So ghc knows 3 is of type Num a, but cannot default to Int. That seems reasonable. We could have wildly different implementations of a typeclass for Int and Double (say for serializing them to a file) and when presented with a literal, ghc shouldn’t automagically choose some arbitrary type.
But it does exactly that today with Show!!

*Main> :t show
show :: Show a => a -> String
*Main> show 3
Whats going on! Looks like some typeclasses default to some instance, while others aren’t. The rules for the special defaulting in GHC can be found here.
Here’s a discussion about this topic on StackOverflow which explains why Show and Num play well together, but other “external” type classes don’t(i.e. they need the type to be explicitly specified).

Weaknesses of Bitcoin

This is going to be a long critique of Bitcoin.
Executive Summary:
1. Bitcoin has no law, no law enforcer, so trusting anyone online is stupid. Every single service that takes and stores your money (online wallets, exchanges, instant transaction processors) has incentive to steal. You might as well ask some random stranger to hold that money for you.
2. No inflation, only deflation. Result: Hoard it, no reason to spend it!
3. Bad structural issues. Pooled mining controls most nodes in the network, so to break the system, you need only a few bad apples.
4. Not easy to setup, own and transact for non-geeks. Wallet lost is money lost. Transaction time takes ~10-60mins!
I have a friend who’s really vested in Bitcoins. He was really excited about it, bought a few bitcoins and thought I’d share his enthusiasm, which I did initially. I mean, whats not to like?
Its a decentralized, pseudo-anonymous digital currency that uses elegant algorithms to make it all work. When I first found about it, I spent a couple of days reading all about the algorithms, how there really is no bitcoin per se, its the transactions that get recorded. How double spending is avoided by having to perform work (computation work) to confirm a transaction. How every node in the bitcoin network has all the transactions so far, so there’s no centralized authority making it all work. The algorithms are mathematically sound, as long as no one discovers any shortcuts for the hash inversion problem (this is what needs to be computed to confirm a transaction)
I’m thoroughly impressed with the technical aspect of Bitcoin. It really is remarkable, considering what its designed to do, create a currency out of thin air, on the interwebs. No Fed, no physical notes/coins, no change in money supply (total amount that will be generated it fixed, although the actual amount increases overtime to approach the limit). So naturally my next question was: should I invest in this?
Short answer: No.
Long answer: Hell No!
Extremely long answer: Theoretically, Bitcoin is perfect. Here’re a few major weaknesses of Bitcoin (the way I see it) in reality.
No law to back it up, so no trust incentive, no moral incentive
Governments have laws that prohibit cheating. These set of rules and consequences induce trust in transacting with people you’ve never met before/don’t know anything about. Basically you’re trusting the government to make rules prohibiting cheating and its ability to enforce it by punishing law breakers. Why would you trust the government to do this? This is a line of reasoning that can take a long time to explain, so I’ll just say that personally, I believe that the gov (at least the US gov) does catch most of the law breakers, and if it goes out of line, we the people will bring it back on track. In short, if a lot of folks are getting screwed over, we’ll make sure our voices are heard and changes are put in place to rectify that which is broken. Now sure, there are cases when people cheat peoplebrokers steal their clients money, when government doesn’t punish law breakers. Its not perfect, as can be clearly seen in the last few years. But it kinda works.
In bitcoin land, there are no rules, and absolutely no enforcers. If people cheat even when there are stiff penalties for them if caught, imagine what people would do if there are NO penalties for being caught except perhaps reputation being tarnished for some online identity. For example, take the case of one of the biggest currency exchanges likemtGox. It looks legit, works, with decent depth of book. However this exchange as no Terms of Service(TOS). It does not guarantee anything. In case they shut down tomorrow, they have no obligation to people to transfer back their money. Worse still, you could siphon client money to their own purposes all the while showing it on their site. When would they get caught? When everyone takes out their money at once. They could then just shut down and dissappear, or even worse, pretend to be hacked, that some clients money was stolen and “explain” the missing money. Well, that exchange did get hacked and money was lost! Who’s to say it wasn’t them stealing from their own clients money and blaming it on a “hacker”?
The other side of this issue: Market manipulation. With the pseudo anonymity, there could be 2-3 accounts in mtGox with the same user which trade back and forth and create fake transactions/prices. What happened in 1920’s in US in the stock markets can and surely ishappening here. This is the wild wild west.

No Inflation!
Situation: You have 2 dollars and an equivalent amount of gold (at current prices). Which would you like to spend to buy a loaf of bread?
Hint: its the currency that will reduce its value.
Three years from now, the amount of gold on earth will be steady, but dollars would be worth less, due to inflation. Knowing your money will be worth less tomorrow make you want to spend it now. Otherwise rational people end up hoarding it, expecting it to go up in value. Thus there is no real economy for bitcoins. Its only miners and buyers, both hoarding bitcoins, knowing that as the Difficulty rises, their value of bitcoins increases exponentially as more people join and mine bitcoins.

Bad Structure
All the elegant algorithms cannot avoid collusion between nodes with majority computational power. This is because pooled mining nodes control make up most of the bitcoin network’s CPU power. Since these pools are essentially running mining software thats propagated from a single user, they are essentially one giant botnet which is currently working on mining. This reduced the number of nodes that need to be controlled to control a majority of the computing power on the network, which in turn enables people to do just about anything. Sure, something obvious would get caught by other people and then they can spawn their own thread of transactions, ignoring the new blocks added from the others, but that assuming they don’t segregate the network and report transactions selectively.

Ease of Use
Working through a transaction in bitcoin is hard. You send your transaction and wait for 10-60 minutes for confirmations. There’s no surety your transaction is valid, because at any time, but the odds go down significantly with every new confirmation. Instant transactions require third-party services again requiring your trust.
All in all, very unstable, very risky.
That to me explains the insane recent volatility and the crazy returns.
And its the returns that suck people in. Its a temptation that will overwhelm logic. The explanation for getting caught up is: “Even if its a bubble, I can still make money by buying in now and cashing out at the top.” Sadly given that other’s will certainly do the same, timing the top is more a game of chance than skilled trading. Currently bitcoin is propped up by illegal activities, misguided believers, goldbugs, speculators and early adopters who’ve seen their investments soar and who now have massive interest in bringing in more people to realize gains.
In my opinion, unless at least the trust issues and inflation are changed in the current system, this is very likely going to fail, or inflate until it pops.