f = File.open(“…”)
begin
# …
ensure
f.close
end

Let’s say for example a coder were to mistype an if statement and forgot the parentheses. Now all of a sudden it becomes valid lambda block syntax? How would the JavaScript interpreter know what to do with such a cryptic block? This will make parsing JavaScript much harder and probably introduce loads of bugs along the way among the browsers that try to implement such a complex and confusing syntax. Not to mention the “overhead” that an interpreter would have to deal with when trying to make sense of the unreadable code. This means slower code execution simply because the interpreter wouldn’t know what kind of block its dealing with because the JavaScript engine would need to be re-designed and have to deal with extra syntax scenarios.

I’m in favor of having lambda-like blocks in JavaScript but I dislike the purposed syntax. I would have expected a lamba block to look like a switch block, while, or try/catch block in JavaScript: e.g. lamba{} or lamba(){}

I believe if a lamba-block-like feature were added to ECMAScript, it shouldn’t smell-up the language, as a drawback, with foreign syntax that would make a scripters run up the walls in confusion and frustration. In my experience, working with the GIMP, the “lambda” expression is available in the Lisp programming language as well as “let” identities. Is that what we are essentially doing here? Smelling up JavaScript with Lisp syntax?

I can see manys advantages and disadvantages to such a change. But I think the proposal should be revised a bit more before it goes mainstream so it can better fit-in and blend-in with the already existing JavaScript syntax.

-Ulti

However, I really don’t think that JS would benefit from this kind of behavior because of its asynchronous nature. The example you gave would be asynchronous in JavaScript and the outer function would return before the inner one (the callback) would even start being executed.

There are really very few cases where a block would be useful. I think that the only improvement would be the execution context shift as we would not have to create variables such as self = this.

Thanks for putting forward the case for block lambdas so eloquently. Your post made us implement block lambda support in Stratified JavaScript – https://groups.google.com/d/topic/oni-apollo/eb3gtiwTOD4/discussion

I’m used to callback chaining in javascript, i.e something like

function FileInfo(name) {
this.name = name;
}

FileInfo.prototype = {
mtime: function(cbk) {
//open file ‘fname’ and call ‘this.process’ scoped with ‘this’ and with arguments [cbk]
//the method File.process opens the file, calls the cbk and performs cleaning
File.process(fname, this.process, this, [cbk])
},
process: function(cbk, f) {
var mtime = f.mtime();
cbk(mtime);
}
}

And doing this is awkward when the language does not support NIO.

I would rather write :
var mtime = File.mtime(fname) and the language platform should automatically perform NIO if necessary !

using a new syntax to perform the exact same thing

This also confuses me: Consider a forEach function:
Array.prototype.forEach = function(block){
var i,l;
for(i=0,l=this.length;i<l;i++){
block(this[i]);
}
}
But then if you were to do the following, then the block would be called again when inactive:
function firstValue(){
[1,2,3].forEach { |x|
return x;
}
}

Right? To avoid this you would need to put a try {…} in the forEach which again makes it even more complicated. I'm new to blocks so maybe I'm missing something.

Also, you really ought to link to the block lambda proposal at the top of this post, along with a good concise summary of Ruby blocks (from a language design perspective, ideally). I don’t like blog posts littered with links, but this is necessary background reading for non-Rubyists.

OO is another whole can of worms, with “this” and “.call(this_value)” and so on in JS. The way other languages deal with OO is “interesting”. Python has the self-as-first-param kludge, which is simpler to implement but violates the correspondence principle to an irritating extent. Lua has it too, if my memory serves. C++ has classes and inheritance and all kinds of craziness, copied by other languages for no good reason. Go eschews inheritance as a Bad Idea… and I vaguely agree. Last I knew, there was a lively debate about the future of OO in Javascript… so, there are two lines of thought to pursue: (1) How would block lambdas fit into JS’s existing kludgy OO system? (2) How would they fit into the various proposals for brand-new OO systems? (And I’m not very interested in that discussion… I only use OO when it’s useful to me, which isn’t very often.)