Live data from Hacker News

Kal – a clean JavaScript alternative without callbacks

rzimmerman.github.io

121–130 of 130 posts

Re: Kal – a clean JavaScript alternative without callbacks

#121

Earlier quoted context omitted.

Well that is a fair enough concern, and I notice I used the word "Monadic" to describe jquery carelessly, to mean "Monad-like" though that isn't really what "Monadic" means. For the case in hand though, you can get to almost but not quite really technically a monad, and still cure most of the nested callback headaches. One way I think about monads is they are a strategy for turning nested functions into sequentially…

I just don't think it's useful to use the word monad to describe the strategy you're suggesting. I'm not criticizing your suggestion, I just don't think it has anything to do with monads. More to the point, I don't understand why we (HN and the JS community at large) keep having this discussion. Coroutines have been around since the 60s. This is a solved problem.

because you can't use coroutines in client-side javascript yet, without some backpiler, and people will disagree on what the proper reaction to that should be.

Re: Kal – a clean JavaScript alternative without callbacks

#122
post #91

Earlier quoted context omitted.

I am not sure if I followed entirely. But let me give you an example, again with Q.nfcall. MultiplyAndSquare = (a, b, cb) -> Multiply a, b, (err, product) -> Square product, (err, square) -> cb null, square #ignore errors for now. nonCallbackVersion = (a, b) -> Q.nfcall(MultiplyAndSquare, a, b) result = yield nonCallbackVersion(10, 20)

You see how the caller has to be aware of how what he's calling is a generator. You're dragging generators all the way trough the call chain as soon as anything deep down in the call chain is a generator, and you'd want to use generators to acomplish asynchronicity. Let's say you write some code A, which uses some other code B, which uses some other code C. C is also used by various other pieces of code like X, Y, Z,…

Sure, call sites of C will need to change, since C's signature changed. That's expected, since C doesn't even take a callback anymore. But callers of A,B,D,E etc don't need to change. A,B,D,E etc can still take a callback parameter and return C's result via the callback.

    MultiplyAndSquare = (a, b, cb) ->
        Multiply a, b, (err, product) ->
            Square product, (err, square) ->
                cb(null, square) #ignore errors for now.

    
    C = (a, b, cb) -> 
        MultiplyAndSquare(a, b, cb)
        
    
    ABDEXY = (a, b, cb) -> 
        #Calls C
        C(a, b, cb)
        
    
    callersOfABDEXY = (a, b) ->
        #Calls ABDEXY
        ABDEXY a, b, (err, result) ->
            Console.WriteLine(result)
        
    
    #Refactored C. Returns a promise instead.
    refactoredC = (a, b) -> 
        (Q.async -> 
            result = yield Q.nfcall(MultiplyAndSquare, a, b)
            return result)()
    
    #Refactored ABDEXY.
    refactoredABDEXY = (a, b, cb) -> 
        #Change needed here, since C now returns a promise
        refactoredC(a, b).then (result) ->
            cb(null, result)

    #No need to refactor callersOfABDEXY

Re: Kal – a clean JavaScript alternative without callbacks

#123
I am a big fan of languages trying to solve callback hell. I use a library in Haxe that allows for similar syntax: https://github.com/proletariatgames/haxe-continuation. Haxe compiles to Javascript and is great for node programming...but it has the added benefit of also compiling to c++, php, java, c#, etc., etc. ;)

Re: Kal – a clean JavaScript alternative without callbacks

#124

Beautiful work. The `for parallel` notation is a really interesting way of writing it. It seems like a number of folks in this thread have expressed interest in your process -- both of designing the feature set, and of gradually bootstrapping it away from CoffeeScript to become self-hosting. I'd love to hear more, if not here, then in a blog post, perhaps...

Thanks! I'm a big admirer of your work, so it means a lot to me to hear that. I wrote up a little bit about this if you are still interested: http://blog.rzimmerman.me/how-kal-compiles-itself/

Re: Kal – a clean JavaScript alternative without callbacks

#125
post #7

The title is kinda funny to the russian ear because kal means feces in Russian :)

That is really unfortunate... I chose it because it in Hebrew it roughly means something like easy/simple/BASIC. edit: More importantly, does that make you more or less likely to use it?

`kal` means `stay` in Turkish, quite fittingly :)

Re: Kal – a clean JavaScript alternative without callbacks

#126
post #47

Does anyone know if there is a JS dialect out there that adds support for callback-less async code without also adding a bunch of other coffeescripty syntax changes at the same time?

StratifiedJS allows you to write callback-less async code, including full support for exceptions thrown from async code (stacktraces and all):

http://onilabs.com/stratifiedjs (disclosure: I work at Oni Labs)

It does extend JS with some additional syntax as well (new concurrency constructs as well as some syntactic sugar), but it doesn't alter existing JS syntax.

Re: Kal – a clean JavaScript alternative without callbacks

#128
post #27
post #10

Yay, another JavaScript super-set language that solves one problem.

On the one hand, this comment has the kernel of a legitimate criticism in it, and gets across why I probably won't use this language in a real project. On the other hand, that's so rude! Not every project has to be the next CoffeeScript to be interesting and worthy of appreciation. If you don't like it, just click on a different story instead of cutting down someone who chose to make something cool and share it with…

You're right. I pretty much just blurted out the first thing that came to my mind when I read about it, and what I said was equivalent to garbage. It was completely uncalled for and I apologize to everybody in this forum for lowering the level of discourse, much less crapping over someone's hard work and pride.

Re: Kal – a clean JavaScript alternative without callbacks

#129

For the curious, the equivalent example from the OP using promises[1]: function getUserFriends(userName) { return db.users.findOne({ name: userName }).then(function (user) { return db.friends.find({ userId: user.id }); }); } [1]: http://promises-aplus.github.io/promises-spec/

Promises are a completely sufficient solution to handle asynchronous code in my opinion and there are already several great libraries for this in JavaScript. I don't get it why would I want to switch to a new language just because of that one feature.

Re: Kal – a clean JavaScript alternative without callbacks

#130

It's remarkable how similar this code looks to the monadic way of doing it. For this Kal code... task getUserFriends(userName) wait for user from db.users.findOne {name:userName} wait for friends from db.friends.find {userId:user.id} if user.type is 'power user' for parallel friend in friends wait for friendsOfFriend from db.friends.find friend for newFriend in friendsOfFriend friends.push newFriend unless newFriend…

And, of course, the Haskell do-notation gets de-sugared into tons of call-backs by the compiler.
Post reply on HN