Re:Monadic lifting in C++
by AnimalMuppet on Monday March 10, 2014 @01:41PM
(#7374412)
I'll give it a shot. (Disclaimer: I'm a non-Haskell programmer who's been trying to get his head around some of this stuff, but who may well have it wrong.)
You've got a function f that will do something to one or more values. That function already exists, and it works.
But f works on regular values. You also have some "special" values. chas described it as having a context; the way I've come to think about it is that the value is in some kind of jail. You can't just operate on it freely. (There are a number of different kinds of jails, but all of them mean that you can't just operate freely on the value.)
What we're talking about here, then, is a smuggling operation. It lets you get your function f to the values (or the values to the function, depending on your point of view) so that it can operate on the values. What's a bit neater is that it lets you separate f from the smuggling, so that f remains unchanged. And you can use the same smuggling scaffolding for any f.
How has this simplified code in the real world? I have no idea, but I think I can tell you one place where it doesn't. Haskell tries to be purely functional, but it can't quite pull it off in the area of I/O (kind of by definition - if you're going to have I/O, you can't be purely functional). So Haskell does I/O in a jail. You use this kind of stunt to get access to I/O values. (Does that make it any less a violation of pure functional programming? Not that I can see. Perhaps they're trying to contain the contamination?)
But in C++, you'd just drop out of functional programming for a line or two, and do stream I/O. You wouldn't have this problem at all, so you wouldn't need this solution.
As I said, I'm trying to understand this stuff, and I'm pretty sure I understand it imperfectly. Your mileage may vary...
You've got a function f that will do something to one or more values. That function already exists, and it works.
But f works on regular values. You also have some "special" values. chas described it as having a context; the way I've come to think about it is that the value is in some kind of jail. You can't just operate on it freely. (There are a number of different kinds of jails, but all of them mean that you can't just operate freely on the value.)
What we're talking about here, then, is a smuggling operation. It lets you get your function f to the values (or the values to the function, depending on your point of view) so that it can operate on the values. What's a bit neater is that it lets you separate f from the smuggling, so that f remains unchanged. And you can use the same smuggling scaffolding for any f.
How has this simplified code in the real world? I have no idea, but I think I can tell you one place where it doesn't. Haskell tries to be purely functional, but it can't quite pull it off in the area of I/O (kind of by definition - if you're going to have I/O, you can't be purely functional). So Haskell does I/O in a jail. You use this kind of stunt to get access to I/O values. (Does that make it any less a violation of pure functional programming? Not that I can see. Perhaps they're trying to contain the contamination?)
But in C++, you'd just drop out of functional programming for a line or two, and do stream I/O. You wouldn't have this problem at all, so you wouldn't need this solution.
As I said, I'm trying to understand this stuff, and I'm pretty sure I understand it imperfectly. Your mileage may vary...