GOTO.js(web.archive.org)
web.archive.org
GOTO.js
https://web.archive.org/web/20160507105653/http://summerofgoto.com/js/goto.js
32 コメント
I really wish JavaScript had goto statements, because it would make it less of a hassle to make code generators that target it.
Before the new block scoping constructs (which I assume would make implementing goto more complicated), was there anything preventing JavaScript from having gotos, other than an authoritarian "we know better than you"?
At least JavaScript has labeled blocks that you can break out of!
Before the new block scoping constructs (which I assume would make implementing goto more complicated), was there anything preventing JavaScript from having gotos, other than an authoritarian "we know better than you"?
At least JavaScript has labeled blocks that you can break out of!
I wrote one of these in 2014 after my boss called goto a mistake.
Goto is a beautiful structured programming construct, the fundamental structure it represents is a skyscraper made of wet spaghetti.
Goto is a beautiful structured programming construct, the fundamental structure it represents is a skyscraper made of wet spaghetti.
Great advice: "If you are seriously considering using this script, please don't."
Goto can already be functionally achieved with labels, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Good hint! However, JavaScript labels via break/continue have subtle differences to classic GOTO statements.
From the MDN site examples:
In contrast "GOTO top" would re-initialize the loop ("i = 0") and effectively restart it from the very beginning.
From the MDN site examples:
var itemsPassed = 0;
var i, j;
top:
for (i = 0; i < items.length; i++) {
for (j = 0; j < tests.length; j++) {
if (!tests[j].pass(items[i])) {
continue top;
}
}
itemsPassed++;
}
In contrast "GOTO top" would re-initialize the loop ("i = 0") and effectively restart it from the very beginning.
Well sure, but you're just doing it wrong. Here's the goto equivalent.
var itemsPassed = 0;
var i, j;
top:
do {
for (i = 0; i < items.length; i++) {
for (j = 0; j < tests.length; j++) {
if (!tests[j].pass(items[i])) {
continue top;
}
}
itemsPassed++;
}
break;
} while(1);
You can just pass 0 to while, and ditch the break. ;- )
No you can't.
Try it if you don't believe me
Try it if you don't believe me
Oh, forgot the weird label behaviour in JS, you're right. Funny to have the label up top, but the branching condition somehow in its way.
You can use labels to jump backwards, but not forwards.
So they get you part of the way to GOTO, but not all the way!
So they get you part of the way to GOTO, but not all the way!
would also recommend https://github.com/contra/blink-polyfill
Related for Python: https://stackoverflow.com/questions/6959360/goto-in-python
There were some earlier discussions about this: https://news.ycombinator.com/item?id=10250770 https://news.ycombinator.com/item?id=3691472
There were some earlier discussions about this: https://news.ycombinator.com/item?id=10250770 https://news.ycombinator.com/item?id=3691472
While I fully agree that GOTO can lead to unmaintainable spaghetti (and is rather more likely to do so than other constructs), I wonder if it is actually more understandable than function calls for someone approaching programming for the very first time? I know I cut my teeth using GOTO before discovering GOSUB in BASIC.
Does anyone know of any research on whether some programming constructs are more easily approachable for beginnings and can serve as a tool to understand further concepts (scope, functions, etc.)?
Does anyone know of any research on whether some programming constructs are more easily approachable for beginnings and can serve as a tool to understand further concepts (scope, functions, etc.)?
You can do a lot of interesting stuff by parsing the code before running it. For example implementing ES6+ features in runtime's that only support ES5. The possibilities are limitless! It can be really fun when the parsed code itself gets parsed, like a dream within a dream.
I guess this is also what made Lisp and Smalltalk so powerful, right?
callCC is my favorite goto weirdness.
import Control.Monad.Cont
import Data.Function (fix)
main = for 0 (<3) (+1) $ \i -> do
liftIO (print i)
for z p s body = do
(jmp, i) <- label z
when (p i) $ do
body i
jmp (s i)
label start = callCC (\cont -> return (fix $ \jmp cur -> cont (jmp, cur), start))
BASIC is dope. Maybe hipsters will start using it to build WebApps in a few years, and it will dethrone JavaScript as the hipster language de jour.
No matter how inefficient, JS has made webdev available to order of magnitude more people than it was before.
We're not in 1995 anymore...
JavaScript can hardly be called the language de jour when has been pretty much the only serious frontend language in the (short) history of the web.
I was talking about server-side JavaScript.
Actually 30+ years is almost half of computer history...
How did you arrive at 30+ years?
The first web browser was released on 1990, so 27 years ago.
https://en.wikipedia.org/wiki/World_Wide_Web
[deleted]
Incidentally, I just released https://github.com/pygy/gosub for the cases where you want to use pkg.scripts and either npm or yarn as a task runner, but don't want to force your users to depend on one of these tools at the expense of the other.
`gosub` will run subtasks with the binary you've used to launch the main task.
What does it have over npm-run-all? It passes parameters to subtasks. That's all. It doesn't take any options and can't run tasks in parallel unlike npm-run-all.
`gosub` will run subtasks with the binary you've used to launch the main task.
What does it have over npm-run-all? It passes parameters to subtasks. That's all. It doesn't take any options and can't run tasks in parallel unlike npm-run-all.
will not behave as expected, because "goto foo;" is replaced by two separate statements, the second of which is outside the scope of the conditional and will always be called. Maybe they could fix this by tying the statements together with a comma instead of separating with semicolons? (EDIT: I don't think a comma will work, but adding brackets around the two statements should do the trick. JS doesn't seem to mind redundant blocks.)
Still funny though.