Practical application of "Bananas, Lenses, Envelopes, and Barbed Wire"?

Question

First of all, the goofy title is directly referencing this paper:

http://eprints.eemcs.utwente.nl/7281/01/db-utwente-40501F46.pdf

I understand the theoretical value of this, as it models most, if not all, programming semantics.

What problems are most efficiently and practically solved with a programming paradigm based on this? What problems are not?

Imagine entire programs written where 80% of all the logic involved these operators. I wonder if a language that forced the operators on the user could take advantage of their structure...

Answer 1

What this means is that solutions which can be modelled in one paradigm can also be modelled in the other, and that one can be programmatically converted into the other.

Now, certain problems are more easily solved in one paradigm than in the other. Also, it's easier to prove properties in one paradigm than in the other. So if you can show such equivalence, you open the door to solving certain problems in the easier, and then converting the solution into the desired paradigm.

This is similar to the monads thingy. The big deal with monads is not how do you write one. The big deal with them is that there is tons of theorems about monads which can be applied once you reduce your problem to a monad. The same principle applies here.

Answer 2

This paper is one in a long series of related theoretical explorations. The research area is what the functional programmers call generic programming (which confusingly is different from what C++ programmers call generic programming). The idea is that you write your functions in such a way that when you define a new data type, you automatically get new code to go with it. A classic problem people would like to solve this way is to write an image of the data to disk and later read back isomorphic data from the disk image.

If you want to get a feel for practical applications of these ideas, I recommend Ralf Hinze's excellent paper Generics for the Masses, which shows how you can try out all these wacky ideas in plain old Haskell. For example, I have used these techniques to implement capture-avoiding substitution for very complicated intermediate languages inside compilers.

Ralf has written a number of good papers on generic programming, as has Jeremy Gibbons. Their stuff is not quite as far out as bananas, lenses, and so on...