On Wednesday, 13. July 2011 00:03:44 Ertugrul Soeylemez wrote:

...

I had some hopes that chaining functions monad-style would ease my pain. I might be on the wrong track though, feel free to tell me so.

You probably are, because the usefulness of monads depends a good deal on syntax. ECMA-based languages like JavaScript, ActionScript, Haxe, etc. have a terrible syntax for anonymous functions.

To give you an alternative, this really sounds like you're looking for a continuation-based solution. Continuation passing style could really solve your problem elegantly even in JavaScript.

Right. It did. It sometimes doens't work to define the callback *after* the function which needs the callback. It is not always easy to find out *when* things need to be defined in javascript. Luckily in Haskell there is no "when". Still in most cases it works and the code looks like regular procedural code, where control flows from top to bottom. And I could nicely write code where the callback makes another callback etc. Thanks. -- Martin

On 14 Jul 2011, at 09:03, Mats Rauhala wrote:

Could you give an example how CPS helped your situation? I'm trying to grok continuation passing style, but for now it just seems to complicate and/or slow down code (stack)

This obviously isn't Martin's example, but hopefully this should help. In a 3D game engine, the norm (in procedural land at least) is to have calls like someInWorldObject.animate(someAnimation). If you want to run that animation, and then another, the norm is to set a timer to fire when the animation is complete and to call another call like that. My engine by comparison uses CPS – whenever you ask the engine to run an animation of some kind you must specify either a) that it repeats indefinitely, or b) has a continuation to deal with what happens after that animation is complete. The result is that calling code doesn't have random timers floating around, and can define what happens at the completion of an animation in a closure, inline with creating that animation. Apple's CoreAnimation also uses continuation passing style for a similar purpose. Both of these examples use CPS because it allows things to happen asynchronously – an animation can disappear off and run, and then something come back to you once it's finished. I have also found CPS can clean up synchronous code too. Take a look at CPBrainfuck on hackage – I personally think it's one of the cleaner implementations of BF out there, though I will freely admit it's not the fastest. Thanks Tom Davie

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/07/11 19:01, Ertugrul Soeylemez wrote:

Also most of the libraries I upload to Hackage use continuations a lot. Do you have a few examples?

- -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4etLwACgkQmnpgrYe6r60BfgCeMHNVU+xZfZjqQmmbyFs0Ep0V 0sIAn1ssPQXqeVakyTU3xC2xynuOg9jg =mLjy -----END PGP SIGNATURE-----

On Thursday, 14. July 2011 10:03:23 Mats Rauhala wrote:

Could you give an example how CPS helped your situation? I'm trying to grok continuation passing style, but for now it just seems to complicate and/or slow down code (stack)

Well it turned out my problem was entirely syntax. If had understood, that an ajax call basically looks like this: // make two successive ajax calls callAsync (remoteFunction1, ["arguments"], function(ret,exc) { //do something with ret and exc var x = ret[1] callAsync(remoteFunction2, [x], function(ret,exc) { // do something else }} You make a remote call and specify what shall happen when the call returns by providing an anonymous callback function. The callAsync itself immediately returns. My only problem was the ugly nesting when I want to place multiple ajax calls which need to be executed in a precise order as in the example above. I cannot simply make the first call and return to make the second call. I would have no idea where exceution would commence after the return. That chain of function calls builds its own little world and you never "return" from this world. This reminded me of haskell Monads which can also create their own little worlds, where e.g. state is passed around . This is why I asked here. But it turned out it had little to do with Monads. Still it is a functional issue. I believe the code above is already CPS, but very ugly. For some reason I hadn't seen, that there is no need to define the callbacks inline, but I might as well assign them to a variables. Then the above code looks like: callAsync (remoteFunction1, ["arguments"], callback1); var callback1 = function(ret,exc) { //do something with ret and exc var x = ret[1] callAsync(remoteFunction2, [x], callback2) } var callback2 = function(ret,exc) { // do something else } This is more gentle to my eyes. The only difficulty is that callback1 and callback2 need to be defined at the time callAsync is called. Usually this is the case. I could of course reverse the order, which would make things safer, but then control will flow bottom- up, whereas all the regular code executes top-down. -- Martin

Martin,

z' = [1,2,3] >>= (\y1->[y1+1] >>= (\y2->return (y1*y2)))

I'm not a Haskell expert, but I think the idea here is that the second lambda is defined *inside* the first one. I think that's the only way that it can access the first lambda's argument. I don't know much Javascript, but here is a small Perl snippet that (kinda) implements the list monad and your example: use strict ; use Data::Dumper ; sub bindM { my $xs = shift ; my $fx2ys = shift ; # maps and concats in one shot my @ys = map {@{$fx2ys->($_)}} @{$xs} ; return \@ys ; } sub returnM { my $x = shift ; return [$x] ; } sub z { my $arg = [1,2,3] ; bindM($arg, sub { my $y1 = shift ; bindM([$y1 + 1], sub { my $y2 = shift ; returnM($y1 * $y2) ; }) ; }) ; } print Dumper(z()), "\n" ; Since $y1 is local to te first lambda, you have to define the second one inside. Patrick

works again, which misled me to believe that (>>=) associates to the right.

In javascript a lambda would look like this

f = function(y1) {return [y1+1]}

I cannot see how I could possible write a function (>>=) which chains such lambdas such that I can still access the arguments outside the function bodies. It is like there are always parentheses around the lambdas. Well there actually are braces in javascript, but it can't be just the syntax.

So what is javascript missing? Is it because in haskell a lambda is just an expression wheras in javascript it is something special?

-- Martin

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- ===================== Patrick LeBoutillier Rosemère, Québec, Canada