This is a project I've been working on in my spare time for a while now and I've finally decided to throw it out there and get some feedback. Do you think the 'wait for' callback syntax is useful? What big features do you think are missing?
Kal – a clean JavaScript alternative without callbacks
101–110 of 130 posts
Re: Kal – a clean JavaScript alternative without callbacks
#102It'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…
If you are looking for a syntax closer to Haskell's, you can take a look at LiveScript ( http://livescript.net/ ) eg. getUserFriends = (userName) -> user Specifically, the section on "backcalls": http://livescript.net/#backcalls
Re: Kal – a clean JavaScript alternative without callbacks
#103Does 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?
Re: Kal – a clean JavaScript alternative without callbacks
#104Earlier quoted context omitted.
If you are looking for a syntax closer to Haskell's, you can take a look at LiveScript ( http://livescript.net/ ) eg. getUserFriends = (userName) -> user Specifically, the section on "backcalls": http://livescript.net/#backcalls
If you are looking for Haskell, you can take a look at Fay ( https://github.com/faylang/fay/wiki ).
Re: Kal – a clean JavaScript alternative without callbacks
#105Re: Kal – a clean JavaScript alternative without callbacks
#106Earlier quoted context omitted.
What do you mean by "actually fix?"
Stop nesting anonymous functions. Un-nest them, name them, and encapsulate the process in a 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 combinators/transformers, to do things like automatically wrap every step in your chain with exception handling. Using common JS promises libraries gives you error handling for free.
Re: Kal – a clean JavaScript alternative without callbacks
#107https://github.com/bjouhier/galaxy
Galaxy does not claim to get rid of callbacks, though... only to help make writing JS/es6 with async/await semantics easier. I've yet to try it out, but the instructions seem clear.
Re: Kal – a clean JavaScript alternative without callbacks
#108Re: Kal – a clean JavaScript alternative without callbacks
#109Re: Kal – a clean JavaScript alternative without callbacks
#110Excellent work. Especially useful since it appears to throw exceptions. That means it's a step up from Iced Coffeescript. The syntax is a little verbose and might be shortened to something like C#: `user = await db.users.findOne {name:userName}`. Would be a lot more clear to me.
As far as I can tell from reading the readme, it does NOT support throwing exceptions from within callbacks. Because, of course, there's no way to technically do that in anything that is JavaScript at its core -- at least as far as I'm aware of. Correct me if I'm wrong? It says "This includes error handling via callbacks." -- not error handling via exceptions. Elsewhere it says "Any errors reported by fs.readFile (re…
wait for data from fs.readfile 'test.txt'
print data.toString
and readFile calls back with an error (the first argument is non-null), the error will be thrown just before the print statement. So print will not execute and you'll get a stack trace. The cool thing is that you can do these async calls within try blocks: try
wait for data from fs.readfile 'test.txt'
print data.toString()
if data.length > 0
wait for data2 from fs.readfile 'test2.txt'
print data2.toString()
else
print 'too short'
catch e
print 'there was an error'
wait for resp from db.save()
Will do what you expect - abort after either wait for if it fails and run the catch clause. Think about how you'd do that in JS: var error = null;
var data, data2, resp;
fs.readFile('test.txt', function (err, data) {
if (err) return handleErr(err);
console.log(data.toString())
if (data.length > 0) {
return fs.readFile('test2.txt', function (err, data2) {
if (err) return handleErr(err);
console.log(data2.toString());
return closeout();
});
} else {
console.log('too short');
return closeout();
}
});
function handleErr(err) {
console.log('there was an error');
return closeout();
}
function closeout() {
return db.save(function (err, r) {
if (err) throw err;
resp = r;
});
}