Label statement moveable
Clarify:
My previous post was not that clear. That post display what I would like to do in the language. Here is the actual code if I choose to do it as the language is now: var i = 0, n = 5; l2: do { i += 1; l3: do { if (i<n) continue l2; else break l3; } while (true); break l2; } while (true); //just log the value n+1: console.log('i:'+i);
loop through label l2 n amount of times before breaking.
This could be useful to escape function invocation cost, if it could be simply express: l2: { i += 1; } l3: { if (i<n) continue l2; }
The function way is to: function l2(){ i += 1; }
l3: do { if (i<n) l2(); else break l3; } while (true);
I did a <a href="jsperf.com/block-scope-vs-function-invocation">
jsprf </a>to further my argument for a sudo goto/function effect:
jsperf.com/block-scope-vs-function-invocation
JS4Lf
So you want to add goto to JavaScript?
I occasionally (quite rarely) use the following variant of the classical do/while(false) trick:
`` foo: do { // ... if (bar) continue foo // meaning: restart from foo // ... break } while (true) // not a real loop, just a hack
Maybe the following syntax could be used?
foo: { // ... if (bar) continue foo // (currently a SyntaxError) // ... }
WDYT?Just wanted to see what type of effect if we modify their behavior to where the continue statement is allow in ant type of block statement as continue to this name label statement, starting from the top of the label block scope. Combine this with the power to break from that block statement with the key word break(like it can now), but also modified to where if a name label does not follow it'll break back to the continue that(in a sense) goto to the statement we are breaking from and continue onward with the code...
In short, yes. I want to be able to continue/break from one block statement to another
JS4Lf
Yes:
foo: { // ... if (bar) continue foo // (currently a SyntaxError) // ... }
in my first attempt at posting this I did something similar:
function foo(v){
return v + 1; }
var i = 0;
baz:{ i += 1; }
continue baz;//same as foo(i);
console.log(i);
But not that I want restriction on where continue can be use; only in block scope. Rather that's in an if/else else if statement or a function statement.
And another important thing is I want label statement reachable from the scope they are define.
So my first attempt example would actually be rewritten to: var i; foo:{ if(typeof i!=='number') break; i+=1; } I =0; { if (i < 5); continue foo; }
console.log(i);//log 4
Again the true aim for this is to lower function calls.
JS4Lf
Please excuse me, I'm trying to move one email to another. Posting this to clear up confusion.
JS4Lf
On Wed, May 20, 2015 at 7:46 PM, Emanuel Allen <emanuelallen at hotmail.com>
wrote:
So my first attempt example would actually be rewritten to: var i; foo:{ if(typeof i!=='number') break; i+=1; } I =0; { if (i < 5); continue foo; }
console.log(i);//log 4
Again the true aim for this is to lower function calls.
And what about this, which is the exact equivalent of your code, without even a label:
var i = 0; do { if (typeof i !== 'number') break; i += 1; } while (i < 5); console.log(i);
(Btw, in this instance, the "typeof" test is not necessary at all. I left it there to better see the connection with the original code.)
You really don't need what you think you need. If you want to "lower functions", you can just as well inline them where they're supposed to be called, instead of above or at any arbitrary place, which nulls out the need for "goto" statements.
I also fail to see whether you're approaching this problem from the point of view of a) write this by hand, or b) the output of a compiler. Your text suggests a), but the code can obviously be written easily in the do..while form I wrote over there, in a much more readable way, so the write-by-hand hypothesis seems weird, which suggests b). Could you make this clearer?
Can we also get goto statements?
Also, if we going to do gotos, then please implement computed GOTO. FORTRAN has had that already for like 50 years.
Bob
---------- Forwarded message ----------
Bob Myers wrote:
Can we also get goto statements?
No, although an out-of-shipping-date Opera engine supported them.
Also, if we going to do gotos, then please implement computed GOTO. FORTRAN has had that already for like 50 years.
Sorry, JS is not Fortran. Goto considered harmful, Dijkstra said -- plus naive Java verifier complexity is O(n^4) without extra stack/typemaps, due to goto.
G-O-T-O in JS is spelled "Proper Tail Calls" and is in ES6.
Sorry, I forgot the smiley on my post. Bob
---------- Forwarded message ----------
I'm not sure if limited "goto" should be really considered harmful. Dijkstra has written his essay on unlimited goto, that could jump from any point in code to any other point in code. I don't see reason why limited "goto" that is semantically equivalent (or little more powerful) to x: do { continue x; } while(false);
should be considered harmful (anyway - it's useful almost only for implementing state machines).
2015-05-22 4:14 GMT+02:00 Bob Myers <rtm at gol.com>:
I'm not sure what you mean by limited goto, but your example works since ES3 in JS. Underused part of the design: break from labeled block or if, no need for do-while(0) nonsense.
Le 26 mai 2015 à 21:48, Brendan Eich <brendan at mozilla.org> a écrit :
I'm not sure what you mean by limited goto, but your example works since ES3 in JS. Underused part of the design: break from labeled block or if, no need for do-while(0) nonsense.
/be
I guess that his example misreferred to my case earlier in that thread:
foo: do {
// ...
if (bar)
continue foo
// ...
break
} while (true)
(It’s too easy to miss that continue applied to while(false) doesn't do what is meant.)
Anyway, for rare cases not covered by break label, as you noted, proper tail call is a satisfactory way to spell goto:
;(function foo() {
// ...
if (bar)
return foo()
// ...
})()
Claude Pache wrote:
Anyway, for rare cases not covered by
break label, as you noted, proper tail call is a satisfactory way to spellgoto:;(function foo() { // ... if (bar) return foo() // ... })()
+∞
Since we have block scope, and we have continue statement to which we can use in loops to jump back to the conduction statement part.
Than can we consider making label stamens moveable by its name.
I'll like to say that the side effect would be sudo(pseudo) function, example:
function foo(v){ return v + 1; }
var i = 0;
baz:{ i += 1; }
continue baz;//same as foo(i);
console.log(i);
Note that I said sudo function. Its mobility is what of value; depending on how JavaScript handle the continue statement in a loop to transport that effect out side a loop.
Stripping this privilege to black scope; where the continue statement is expanded to work only in block scope and nested block scope; to where it can only jump to the beginning of that block or any other block scope that is scoped to that outer block scope but not nested block scope with in the scope... Like function.
Continue and break statement could be of more power; where we can avoid some function call in "speed matter" application.
Excuse any grammar errors.
JS4Lf
Since we have block scope, and we have continue statement to which we can use in loops to jump back to the conduction statement part. Than can we consider making label stamens moveable by its name. I'll like to say that the side effect would be sudo(pseudo) function, example: function foo(v){ return v + 1; } var i = 0; baz:{ i += 1; } continue baz;//same as foo(i); console.log(i); Note that I said sudo function. Its mobility is what of value; depending on how JavaScript handle the continue statement in a loop to transport that effect out side a loop. Stripping this privilege to black scope; where the continue statement is expanded to work only in block scope and nested block scope; to where it can only jump to the beginning of that block or any other block scope that is scoped to that outer block scope but not nested block scope with in the scope... Like function. Continue and break statement could be of more power; where we can avoid some function call in "speed matter" application. Excuse any grammar errors. JS4Lf