<p>Haskell has been used as a quantum programming language for a while now. </p>

<p>The primary point of reference would be the Quipper DSL in Haskell.</p>

<ul>
<li><a href="http://arxiv.org/pdf/1304.5485v1.pdf">Quipper paper</a></li>
<li><a href="http://www.newscientist.com/article/dn23820-new-language-helps-quantum-coders-build-killer-apps.html">New Scientist article on Quipper</a></li>
</ul>

<p>And more fun stuff - <a href="http://www.kurzweilai.net/quipper-language-makes-quantum-computers-easier-to-program">http://www.kurzweilai.net/quipper-language-makes-quantum-computers-easier-to-program</a></p>
Is Haskell suitable for quantum computing?
<p>I have just read an article talking about quantum physics. One interesting thing is that in a Haskell programmer's view there are some similarities between these two fields.</p>

<p>First of all, measurement in the quantum world seems similar to lazy evaluation in Haskell: if you do not measure, you don't know whether the cat is living or dead. If you do not evaluate, you don't know whether the value is defined or <code>undefined</code>.</p>

<p>Second, in quantum we have the <a href="http://en.wikipedia.org/wiki/EPR_paradox" rel="noreferrer">EPR paradox</a>, which can be explained by interactions with speed higher than light, or equivalently, a time machine. In Haskell, as we have seen in <a href="http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf" rel="noreferrer">Assembly: Circular Programming with Recursive do -Monad.Reader issue 6</a>, we can access a value that came from the future by use of recursive <code>do</code>.</p>

<p>Finally, in quantum we have to distinguish the observable world in which entropy never decreases, and the "pure" quantum world in which time is equivalent in both directions. In Haskell we have the <code>IO()</code> world that describes what the program actually does, and the pure functional world that never has side effects, and the values never depend on evaluation order.</p>

<p>So I guess the above facts suggest there are some inter-connections between these two fields. Can this have more interesting consequences? For example, although I have talked about the EPR paradox, I don't know how to create a Haskell program to simulate this: a function creates two values, and later evaluation of one of them will affect the other (I think those values must have <code>IO()</code> types but I don't know how to put them together).</p>