Skip to content

Instantly share code, notes, and snippets.

@dherman
Created January 13, 2012 22:50
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dherman/1609202 to your computer and use it in GitHub Desktop.
Save dherman/1609202 to your computer and use it in GitHub Desktop.
using loop controls from within block lambdas
Mailbox.prototype.extractContents = function(contacts) {
let messages = this.messages;
loop:
for (let i = 0, n = messages.length; i < n; i++) {
messages[i].headers.forEach { |header|
if (header.isSpam())
continue loop; // the label is not strictly necessary here
let addresses = header.extractAddresses();
addresses.forEach { |addr|
contacts.add(addr.name, addr.email);
};
};
}
};
@isaacs
Copy link

isaacs commented Jan 16, 2012

I'm opposed to block-lambdas, but @dherman is right: the "this is a goto" argument is not a valid response to block-lambdas, and the "every control statement is a goto" is not the reason why. Every control statement is, in some way, a method for sending the execution to another point in the program (ie, a goto), but, with specific structured semantics. Gotos lack that structure, which is the source of their hazard. When people say "X is a goto", it derails the conversation into "But everything is a goto" vs "No it's not, because it has some structure", when really, we should be discussing whether the specific structure in this case is a) relevantly different from what already exists, and if so, b) whether the added power is worth the added conceptual complexity.

For me, the issue isn't that block lambdas are a goto, but rather that the structured semantics of block lambdas is hazardous. They are a goto that is passable (like a function), and which has access to the data in the scope where it's defined (like a function), but, also has control-flow effects in the context where it's defined (like a loop).

As I showed in this gist, it can lead very quickly to some very odd scenarios. If the goal is to provide breakable iteration constructs, then we can do that more safely with API today, which in my opinion obviates the need for doing that in syntax.

@dherman
Copy link
Author

dherman commented Jan 16, 2012

@isaacs: I agree that "X is a goto" is a bogus argument, but to be clear no one was arguing that block lambdas are goto. They were arguing that break-to-label is as bad as goto, because I pointed out that you could use your own labels to break out of a forEach.

Anyway I don't really understand your gist. How is it any more of an issue than a function that throws an exception?

@isaacs
Copy link

isaacs commented Jan 16, 2012

@dherman I've heard "block lambdas are a goto" as a nay argument before. (I agree with the "nay" bit of it, but not with the reasoning.) I'll respond to your comment about the other gist in the other gist's comments.

@bingomanatee
Copy link

bingomanatee commented Jan 16, 2012 via email

@grncdr
Copy link

grncdr commented Jan 17, 2012

I commented more verbosely on Isaac's gist, but in short: what about disallowing mixing of block lambda return and normal return in a single function?

@polotek
Copy link

polotek commented Jan 17, 2012

I just want to point out that this is what I mean about goto and FUD. Not that labels are true gotos, not that any form of goto is harmful. But that people will want to argue about it. We will be spending a lot of our time correcting people's misconceptions. And in the end, the consensus will be, "look just don't use labels, you don't need them if you know how to write good javascript". They are not a useful feature of javascript and they should be avoided. We've managed to do it for this long. Let's not falter now.

Yes I do realize that I'm the one that first mentioned goto. Call it a preliminary social experiment that served to fully support my hypothesis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment