When I saw this, I was hoping for the impossible, and was predictably disappointed. This is not the GOTO you know (at least, it will never match up to C or to CL's TAGBODY), as it cannot jump forward to labels declared textually later in the code.
I've worked through various ways of trying to implement goto in Javascript via preprocessing for the parenscript CL library, and have always come away feeling unsatisfied. You can do it, but as far as I can tell, you have to use a trampoline.
A native goto statement in Javascript would go a long way into making JS an acceptable compilation target.
Rather than using nested while loops with labels, why not use one big while loop and a switch statement? This seems cleaner and would allow jumping ahead, rather than just behind.
Labels "[lbl] foo" would become "case 'foo':goto_label=false;" and gotos "goto foo;" would become "goto_label='foo'; continue goto_loop;".
Example:
var goto_label='top';
goto_loop: while(goto_label) {
switch(goto_label) {
case 'top': goto_label=false;
...
goto_label='foo'; continue goto_loop;
...
case 'foo': goto_label=false;
...
}}
Not perfect, but better.
edit: scratch that, labels within other control structures won't work, only top level ones.
A real GOTO in Javascript would be extremely welcome. Commenters bemoaning the idea are missing the point. The value is not in writing GOTOs by hand, but in a greatly expanded ability to add higher-level abstractions to the language. For example, we have a lot of JS with nested functions. There's no good way to say "return from the top-level function"; the return keyword only gets you out of the current level. If we had something like CL's return-from we could do more with JS. There are many such examples. (Edit: the while-loop hack that's used here might be useful for this. I had thought about implementing it with throw/catch but that seemed too heavyhanded.)
I like the joke, but I consider the reflexive anti-goto attitude harmful. Javascript would be a better language with a native goto statement. I think people forget the context of Dijkstra's paper. Scope-local gotos are qualitatively different than type of function-less code that Dijkstra was referring to at the time. The clearest way to express certain algorithms really does involve a (local) goto. And goto makes it much easier to implement higher-level language constructs in Javascript through preprocessing.
Without goto and TCO (goto by another name), you're left to transform your code to be run under a trampoline, which really makes the resulting JS unreadable.
What JS really, really, really, really needs isn't TCO (well that too), but rather call/cc.
Looking over a fairly large project here, a majority of the code is written in CPS because of callbacks to the server or delays for user interaction.
(So far, I've avoided the need to trampoline, since my call stack isn't getting too deep yet before it unwinds on it its own. But, then again, I haven't done any cross-browser testing at all yet.)
Sure, but then we're down to arguing whether a language should be designed to constrain bad programmers or empower good ones. And quite apart from the general arguments one can make (for example, that bad programmers will make a mess no matter what), it's clear that Javascript has become a major platform for modern applications. To constrain the growth of the entire class of web apps in order to allegedly limit the spaghetti produced by $programmer is a poor tradeoff, I'd say.
> The clearest way to express certain algorithms really does involve a (local) goto.
Java doesn't have goto, but it has labeled break and continue statements. Great for exiting nested loops. Exceptions are another kind of structured goto. Of all the criticisms of Java, I've never heard the lack of goto bemoaned.
One thing I love about the Java designers is their humility: they thought the above was enough to cover all the cases where a goto was really convenient, but still made goto a reserved word. Just in case.
I know, I know; I've read bad code too. But I've also read plenty of bad code in languages that don't have goto. Copy-and-paste coding and reckless abuse of globals are worse and more prevalent than goto abuse in my experience.
Besides, I object to bondage and discipline in a programming language. If people don't have guns, then they'll use....
...a baseball bat, which while possible of inflicting terminal injuries isn't quite as good at it, lowering the number of deaths.
The analogy still holds :-)
edit: I mean to say literally that GOTOs certainly are useful, but are far easier to create spaghetti code with than something much safer like functions. It's a cost/benefit analysis.
Your response's utter geekiness earned my vote! I couldn't have put it better.
I hope this one is a joke. Isn't goto looked down on because of its role in the Roman Inquisition? Seriously though, the project is just a cool technical hack not meant for public consumption, right? Right?
A funny hack. He uses "while" loops with "continue" to emulate backward jumps. Not sure how he does forward jumps (is it implemented at all? "break" could help, i suppose..)
Anyway, AFAICS, cross-function gotos are impossible with this implementation, so you can't write real spaghetti code with it. Awww :).
[btw, I suppose it [edit: cross-function gotos and whatnot] should be possible. It would probably take a full-blown continuation passing style transform, though]
The problem with break and continue is that they only apply to the inner most loop. Unless you change certain values, you're only going to reenter the same loop immediately. In that case - goto is actually a cleaner solution.
This thread was actually quite enlightening to hear the debate from both sides on the goto statement. Love HN for that. Nevertheless, it's always healthy to inject a little humor into the debate.
It just replaces labels with named while loops, and GOTO gets replaced with continue...
So it can only GOTO things that are nested correctly, and only jump back not forwards.
So not really a Goto in any real sense of the word.
Well I assumed, as did others, that this was implemented as a joke. Gotos aren't inherently evil but if your code is improved by using them then your code is bad.
I've worked through various ways of trying to implement goto in Javascript via preprocessing for the parenscript CL library, and have always come away feeling unsatisfied. You can do it, but as far as I can tell, you have to use a trampoline.
A native goto statement in Javascript would go a long way into making JS an acceptable compilation target.