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.
Funny script, though I can't help but point out a flaw: it doesn't play well with unbracketed conditionals. For example:
if (num > 5) goto foo;
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.)
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!
Good hint! However, JavaScript labels via break/continue have subtle differences to classic GOTO statements.
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++;
}
The statement "continue top" does not really jump to top, because it only increases "i" and rechecks the loop condition.
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 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.
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))
Guess you could do this in javascript via trampolining?
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.)?
reply