Using backtracking to undo transactions in Haskell
fpcomplete.com
Using backtracking to undo transactions in Haskell
1–10 of 11 posts
Re: Using backtracking to undo transactions in Haskell
#2For me, this is the money quote:
The monad instance defines what each kind of computation has to do with these continuations.
A bind has two parameters: a closure and a continuation.
x >>=(f1>>=(f2 >>=f3))
Re: Using backtracking to undo transactions in Haskell
#3 function bind(a,f) { return f(a) }
bind(1, function(a) {
bind(2, function(b) {
console.log(a + b)
})})
var a = 1;
var b = 2;
console.log(a + b)
/end cynicism
Re: Using backtracking to undo transactions in Haskell
#4For me, this is the money quote: The monad instance defines what each kind of computation has to do with these continuations. A bind has two parameters: a closure and a continuation. x >>=(f1>>=(f2 >>=f3)) Serious light-bulb moment. I'm very used to thinking about and leveraging closures in imperative languages, but the above finally connected the idea that I can deliberately build abstractions/DSLs like this in Hask…
Many in the Haskell community don't like the "do" syntax because it obscures the fact that you're actually generating a closure per More complexly, the STM implementation for monad also uses it for backtracking; should something fail it can simply roll back all the function calls it has made and restart. It's not magic, it's a huge, huge pile of closures that the implementing type can use to do all sorts of things.
This is also one of the major reasons why good implementations of the monad typeclass in other languages often end up very painful to use; without some sort of friendly syntax that makes it incredibly easy to generate a new closure, you get a lot of "line noise" as you keep typing function (...) { ... function (...) { ... function (...) { ... function (...) {...
I'm still in the "I use it" camp personally, but I am sympathetic to the idea that you should start by manually writing out the bind calls on manually-written closures, and only go to the "do" syntax when you understand it thoroughly.
Oh, and to set your mind at ease: }}}}.
Re: Using backtracking to undo transactions in Haskell
#5For me, this is the money quote: The monad instance defines what each kind of computation has to do with these continuations. A bind has two parameters: a closure and a continuation. x >>=(f1>>=(f2 >>=f3)) Serious light-bulb moment. I'm very used to thinking about and leveraging closures in imperative languages, but the above finally connected the idea that I can deliberately build abstractions/DSLs like this in Hask…
Many in the Haskell community don't like the "do" syntax because it obscures the fact that you're actually generating a closure per More complexly, the STM implementation for monad also uses it for backtracking; should something fail it can simply roll back all the function calls it has made and restart. It's not magic, it's a huge, huge pile of closures that the implementing type can use to do all sorts of things. T…
Many Haskell books and tutorials tell what the "do" really does. People should read more.
Re: Using backtracking to undo transactions in Haskell
#6For me, this is the money quote: The monad instance defines what each kind of computation has to do with these continuations. A bind has two parameters: a closure and a continuation. x >>=(f1>>=(f2 >>=f3)) Serious light-bulb moment. I'm very used to thinking about and leveraging closures in imperative languages, but the above finally connected the idea that I can deliberately build abstractions/DSLs like this in Hask…
Many in the Haskell community don't like the "do" syntax because it obscures the fact that you're actually generating a closure per More complexly, the STM implementation for monad also uses it for backtracking; should something fail it can simply roll back all the function calls it has made and restart. It's not magic, it's a huge, huge pile of closures that the implementing type can use to do all sorts of things. T…
In STM the backtracking is a bit different. It has a single backtracking point and usually it is implemented by killing the thread and restarting it anew. That is because doing IO actions is really unsafe under STM. Really it is not implemented in Haskell but in C, at least the last time that I looked at it).
This backtracking is different since it permits different backtracking points. It is possible to implement a more "civilized" version of the STM semantics this way, with more respect for IO actions.
Re: Using backtracking to undo transactions in Haskell
#7For me, this is the money quote: The monad instance defines what each kind of computation has to do with these continuations. A bind has two parameters: a closure and a continuation. x >>=(f1>>=(f2 >>=f3)) Serious light-bulb moment. I'm very used to thinking about and leveraging closures in imperative languages, but the above finally connected the idea that I can deliberately build abstractions/DSLs like this in Hask…
Very glad that you appreciate it. I think that there is a gold mine of applications under this simple realization.
Re: Using backtracking to undo transactions in Haskell
#8For me, this is the money quote: The monad instance defines what each kind of computation has to do with these continuations. A bind has two parameters: a closure and a continuation. x >>=(f1>>=(f2 >>=f3)) Serious light-bulb moment. I'm very used to thinking about and leveraging closures in imperative languages, but the above finally connected the idea that I can deliberately build abstractions/DSLs like this in Hask…
Very glad that you appreciate it. I think that there is a gold mine of applications under this simple realization.
Actually, the gold mine is monad transformer. There aren't many things you can do with monads (and the OP's one is nothing new). The real power is in the combination of monads.
Re: Using backtracking to undo transactions in Haskell
#9Earlier quoted context omitted.
Very glad that you appreciate it. I think that there is a gold mine of applications under this simple realization.
Actually, the gold mine is monad transformer. There aren't many things you can do with monads (and the OP's one is nothing new). The real power is in the combination of monads.
I added the backtracking effect in this article without stacking a new transformer. In a way somewhat similar in which a new interpreter can add a new effect to a free monad.
Re: Using backtracking to undo transactions in Haskell
#10Earlier quoted context omitted.
Very glad that you appreciate it. I think that there is a gold mine of applications under this simple realization.
Actually, the gold mine is monad transformer. There aren't many things you can do with monads (and the OP's one is nothing new). The real power is in the combination of monads.
Do you have seen the monad of the article before? I would like to know your reference, please.