Finally... Goto in Javascript(summerofgoto.com)
summerofgoto.com
Finally... Goto in Javascript
http://www.summerofgoto.com/
16 comments
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:
edit: scratch that, labels within other control structures won't work, only top level ones.
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;
...
}}
edit: scratch that, labels within other control structures won't work, only top level ones.
> A native goto statement in Javascript would go a long way into making JS an acceptable compilation target.
Much agreement here. I alternate between wishing for a goto in JS, and wishing for a lower level bytecode to be exposed from the browser.
goto does seem more likely though.
Much agreement here. I alternate between wishing for a goto in JS, and wishing for a lower level bytecode to be exposed from the browser.
goto does seem more likely though.
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.)
Goto floor(10);
Open window;
Jump();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.
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.)
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.)
Actually I can only second that. Goto's are useful. For instance in the Linux Kernel it is used instead of exceptions in the function scope.
Unfortunately great power (goto) comes with great responsibility (don't produce spagetti). Most $programmers don't get that right.
Unfortunately great power (goto) comes with great responsibility (don't produce spagetti). Most $programmers don't get that right.
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.
Interesting jargon. Is a $programmer a PHP (etc) programmer?
> 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.
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.
!reflexive, I promise you. Based not on Dijkstra's paper, but my own horror stories.
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....
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.
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.
I can code perfectly fine (and mind-blowing) spaghetti code with call/cc, too.
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?
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]
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]
We also need ALTER operator: http://home.swbell.net/mck9/cobol/style/alter.html
the fifth note is quite telling:
"NOTE: Seriously. Never use this."
"NOTE: Seriously. Never use this."
Javascript already has labels and break and continue. That ought to be enough for everyone.
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.
That's what labels are for. I think you can do
loop: for(i=0;i<10;i++){ for(...) { break loop; } }
loop: for(i=0;i<10;i++){ for(...) { break loop; } }
[deleted]
Shame the site wasn’t a little more subtle about the joke, at least until the fold.
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.
http://xkcd.com/292/
http://xkcd.com/292/
[deleted]
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.
So not really a Goto in any real sense of the word.
I'm surprised that approach was taken. It's easier to rewrite the function as a state machine, where gotos just go to the proper state.
[deleted]
I would like to see just one example where a real goto is needed.
Just one...
Just one...
I guess you never looked?
There plenty of examples.
It's not usually needed but it often helps.
There plenty of examples.
It's not usually needed but it often helps.
Oh dear god.
Yes?
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.