Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kal – a clean JavaScript alternative without callbacks

rzimmerman.github.io

Post reply on HN
Print view View original

111–120 of 130 posts

Re: Kal – a clean JavaScript alternative without callbacks

#111

Post by wooter »

graue wrote: post #33
rzimmerman wrote: post #25

Earlier quoted context omitted.

Thanks for the feedback. It seems like a lot of people would prefer a more normal looking assignment. If you get a chance (and use TextMate or Sublime Text), please give syntax highlighting a try ( https://github.com/rzimmerman/kal.tmbundle )!

Unfortunately I don't use those editors — maybe you can write a Vim highlighter next? Might also be worth adding syntax highlighting to the website (even if you have to do it manually for now), if you're set on the current syntax and think highlighting will make that much of a difference.

Although I cannot agree more with you and csheid, you really should give sublimetext a try. I've been quite impressed.

Re: Kal – a clean JavaScript alternative without callbacks

#112

Post by iandanforth »

rzimmerman wrote: post #57
rybosome wrote: post #41

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…

Thanks! I had not thought to make the comparison to Haskell and monads. That's pretty interesting. A lot of people prefer symbols over keywords, and I think that's mainly a readability issue. I personally prefer more keywords with good syntax highlighting, so that's what I went with (and why I almost immediately made a .tmbundle).

Coming from a Python background I appreciate the verbosity. There are times when symbols and being concise may be necessary, but I find a non-expert human readable default to be very appealing.

Thanks for your hard work!

Re: Kal – a clean JavaScript alternative without callbacks

#113

Post by Serow225 »

rzimmerman wrote: post #25
graue wrote: post #22

Earlier quoted context omitted.

I also vote for 'await' here. The 'wait for friends from' construct looks too much like BASIC for my liking. It's not clear which terms are built into the language ('wait', 'for', 'from') and which are not ('friends'). Also, since the eventual result of that line is an assignment to 'friends', using the existing = operator makes the language more consistent.

Thanks for the feedback. It seems like a lot of people would prefer a more normal looking assignment. If you get a chance (and use TextMate or Sublime Text), please give syntax highlighting a try ( https://github.com/rzimmerman/kal.tmbundle )!

Would it be hard to support both syntaxes?

Re: Kal – a clean JavaScript alternative without callbacks

#114

Post by mistercow »

aufreak3 wrote: post #98

(Don't mean to divert this thread from Kal, but this is on the topic of "callbacks are bad" etc.) For some time now, I've been accumulating async patterns I've needed when writing JS code in my monadic IO.js library[1]. The aim of IO.js is to provide higher levels of thinking about sequences of actions without worrying about whether they are async, and with a rich set of error management tools (for ex, exceptions are…

>The "hell" rears its head when you need to coordinate multiple such sequences that are running concurrently.

This situation is why I wrote DelayedOp: https://github.com/osuushi/DelayedOp . Of all the little reusable code bits I've written, this one has ended up in more of my projects than any other.

Basically, a DelayedOp is a lightweight manager that runs a callback after its "wait" and "ok" calls have balanced. It ends up being equivalent to _.after(), but it's more natural to use than manually counting your concurrent operations, and it has some conveniences for debugging, so that if a callback never fires, you can find out why.

Re: Kal – a clean JavaScript alternative without callbacks

#115

Post by nbouscal »

TheZenPsycho wrote: post #106
TheZenPsycho wrote: post #95

Earlier quoted context omitted.

Stop nesting anonymous functions. Un-nest them, name them, and encapsulate the process in a monad.

monad* *jQuery or promises like API object, whereupon you place methods- some of which may be asynchronous. an asynchronous operation returns an object with a method that performs the next action and optionally takes a callback, passing in the results of the previous asynchronous operation as a value- thus flattening the callbacks out into a sequence instead of a nesting. Constructed properly, you can create monad co…

You do know that jQuery isn't a monad, right? That's the second time in this thread that you've called it one. Simplest demonstration that it isn't: try defining join.

Re: Kal – a clean JavaScript alternative without callbacks

#116

Post by pyalot2 »

jeswin wrote: post #91
pyalot2 wrote: post #89

Earlier quoted context omitted.

That's a faulty assertion. A generators working principle is that it can resume into the closure if the "caller" is looping over the generator. Let's assume a simple call stack, A -> B -> C. Now C would be a generator, so B has to loop over C instead of just calling C. But what about A? Well if B is now looping, and if yielding out of a loop is how you cooperatively multitask, then A now has to loop over B. So you ha…

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, D, E, F, G, H, J, K etc. Now at some point you decide, well, you don't like callbacks in C, so you'll convert it to something asynchronous. You'll now just have to refactor A, B, D, E, F, G, H, J, K, X, Y and Z to make all their calls to C a generator iteration, and you'll have to convert any code that depends on A, B, D, E, F, G, H, J, K, X, Y or Z to be aware of that, any any code which uses those, to be aware of that.

Re: Kal – a clean JavaScript alternative without callbacks

#117

Post by TheZenPsycho »

nbouscal wrote: post #115
TheZenPsycho wrote: post #106

Earlier quoted context omitted.

monad* *jQuery or promises like API object, whereupon you place methods- some of which may be asynchronous. an asynchronous operation returns an object with a method that performs the next action and optionally takes a callback, passing in the results of the previous asynchronous operation as a value- thus flattening the callbacks out into a sequence instead of a nesting. Constructed properly, you can create monad co…

You do know that jQuery isn't a monad, right? That's the second time in this thread that you've called it one. Simplest demonstration that it isn't: try defining join.

jquery-like. I never claimed that that jquery is a monad. I know it isn't. But also, I don't want to be one of those guys that throws around the word monad expecting everyone to understand what I'm talking about.

as for defining "join", help me understand. How is jquery "add" not essentially that? And why pick the fmap,join formulation instead of the bind,return formulation of a monad?

Re: Kal – a clean JavaScript alternative without callbacks

#118

Post by nbouscal »

TheZenPsycho wrote: post #117
nbouscal wrote: post #115

Earlier quoted context omitted.

You do know that jQuery isn't a monad, right? That's the second time in this thread that you've called it one. Simplest demonstration that it isn't: try defining join.

jquery-like. I never claimed that that jquery is a monad. I know it isn't. But also, I don't want to be one of those guys that throws around the word monad expecting everyone to understand what I'm talking about. as for defining "join", help me understand. How is jquery "add" not essentially that? And why pick the fmap,join formulation instead of the bind,return formulation of a monad?

jQuery's add function has a few different formulations depending on what argument you pass, but it's basically either M a -> a -> M a (if you pass it an html string, an element, or a selector) or M a -> M a -> M a (if you pass it another jQuery object) where here M refers to the jQuery wrapper and the first argument refers to `this` (obviously these type signatures are an approximation since JavaScript doesn't really work this way). join is M (M a) -> M a, which is very different.

The reason I picked join is because (in my view, anyway) it's the easiest demonstration of how jQuery is not a monad. There's no way to even get something of type M (M a) in jQuery, because the jQuery lifting operation is idempotent. The same exact problem exists with return, but I've found that people have a hard time seeing it with that example.

The problem I have with you referring to jQuery as a monad, even by analogy, is that jQuery really really isn't a monad. It's only very loosely analogous, and that analogy is more likely to teach people the wrong things about monads rather than the right ones.

Re: Kal – a clean JavaScript alternative without callbacks

#119

Post by TheZenPsycho »

nbouscal wrote: post #118
TheZenPsycho wrote: post #117

Earlier quoted context omitted.

jquery-like. I never claimed that that jquery is a monad. I know it isn't. But also, I don't want to be one of those guys that throws around the word monad expecting everyone to understand what I'm talking about. as for defining "join", help me understand. How is jquery "add" not essentially that? And why pick the fmap,join formulation instead of the bind,return formulation of a monad?

jQuery's add function has a few different formulations depending on what argument you pass, but it's basically either M a -> a -> M a (if you pass it an html string, an element, or a selector) or M a -> M a -> M a (if you pass it another jQuery object) where here M refers to the jQuery wrapper and the first argument refers to `this` (obviously these type signatures are an approximation since JavaScript doesn't really…

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 composed functions. Which is, pretty much what we want, right?

Re: Kal – a clean JavaScript alternative without callbacks

#120

Post by nbouscal »

TheZenPsycho wrote: post #119
nbouscal wrote: post #118

Earlier quoted context omitted.

jQuery's add function has a few different formulations depending on what argument you pass, but it's basically either M a -> a -> M a (if you pass it an html string, an element, or a selector) or M a -> M a -> M a (if you pass it another jQuery object) where here M refers to the jQuery wrapper and the first argument refers to `this` (obviously these type signatures are an approximation since JavaScript doesn't really…

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.

Post reply on HN