Reversible programming
stanford.edu
stanford.edu
Kurzweil talks about it in The Singularity Is Near, when he examines just how far Moore's Law can go. If we can figure out reversible computing, the upper bound is quite a bit further out, since heat dissipation issues go away. Ask a reversible computer a yes-no question that takes enormous computation, and it will consume no more energy than a rock, until at last you have to pay for your one bit of output.
Edit: I seemed to remember that IBM had done some work on it, and found this paper: http://www.research.ibm.com/people/b/bennetc/bennettc19734c5...
Then I remembered the name Fredkin, and found this: http://www.aicit.org/jdcta/ppl/18.%20JDCTA4-440054.pdf
Fredkin invented the Fredkin Gate: http://en.wikipedia.org/wiki/Fredkin_gate
http://en.wikipedia.org/wiki/Billiard-ball_computer
The punchline is that (idealized, friction free) billiard balls + billiard ball "mirrors" (for the balls to bounce off) are enough to do universal computation! To reverse the computation, just reverse all the billiard balls.
or tried to undo some other trap-door function. In cryptography, a trap door function has linear complexity in one direction, but in the other direction it is either exponential or NP, unless you know some additional information in which case it drops back down to linear.
read the source for p-divmod (one of the most useful functions in cryptography). You need to pass the original y to get back the original x in the reverse
http://lambda-the-ultimate.org/node/4191
One of the coolest papers I've seen recently.
I fiddled with a similar idea for XML a long time ago, but I lacked the skills to pull it off. Also it's harder in Python, several-years-more-experienced-me thinks you really want a combinator approach for this as JsonGrammar takes, and while that can be done in not-Haskell, it's certainly a lot easier in Haskell for a number of reasons.
It would seem that you would have to be explicit about the domain and codomain of a function to even be able to programmatically figure out an inverse function. Given the author's example of strings to integers, clearly the inverse function will be from integers to strings—but obviously the codomain can't be all strings, but rather ones that are string representations of integers. The validation logic for which strings represent integers (which is essentially the definition of the codomain of the integers->strings function) would certainly have to be explicit somewhere.
http://docs.factorcode.org/content/article-inverse%2Cintro.h...
Stuff like this always reinforces my thought that Lisp and strange thinking work well together.
/me 2c
* Qi and Loom are pretty nifty and IMO radical projects.
* Hot-patchable servers are trivially doable.
* There are some really trippy things over on Lambda the Ultimate done in Lisp (Schemes to be precise).
I don't try to canvass projects and figure out which ones are done in Lisp for net arguments.
Also, Lambda the Ultimate is a weblog for functional programming, not Lisp specifically.