Simulate goto

A

Archos

I'm trying to simulate the goto statement but I get an error

===
function testGoto() {
var isFirst = true;

skipPoint:
alert("Using goto\n");

if (isFirst) {
isFirst = false;
continue skipPoint;
alert("This part is skipped");
}
}
===

SyntaxError: label not found
continue skipPoint;
 
A

Archos

I'm trying to simulate the goto statement but I get an error

===
function testGoto() {
        var isFirst = true;

        skipPoint:
        alert("Using goto\n");

        if (isFirst) {
                isFirst = false;
                continue skipPoint;
                alert("This part is skipped");
        }}

===

SyntaxError: label not found
continue skipPoint;

I just find the failure. In JS, it must have a statement after of the
label
 
A

Archos

I just find the failure. In JS, it must have a statement after of the
label

function testGoto() {
var isFirst = true;

skipPoint:
if (true) {
alert("Using goto\n");
}

if (isFirst) {
isFirst = false;
continue skipPoint;
alert("This part is skipped");
}
}
===
It follows with the same failure
 
E

Erwin Moller

function testGoto() {
var isFirst = true;

skipPoint:
if (true) {
alert("Using goto\n");
}

if (isFirst) {
isFirst = false;
continue skipPoint;
alert("This part is skipped");
}
}
===
It follows with the same failure


Yuk, labels...

My advice: Read the following link, and then conclude you should avoid
using labels.
That way you can stop worrying about the exact use of them. :)

https://developer.mozilla.org/en/JavaScript/Reference/Statements/label

Regards,
Erwin Moller
 
T

Tom de Neef

Archos said:
I'm trying to simulate the goto statement but I get an error

===
function testGoto() {
var isFirst = true;

skipPoint:
alert("Using goto\n");

if (isFirst) {
isFirst = false;
continue skipPoint;
alert("This part is skipped");
}
}
===

SyntaxError: label not found
continue skipPoint;

The error may have more to do with 'continue' than with the label.
Check where you can use a continue statement - I think it is restricted to
for- and while- loops.
Tom
 
J

John G Harris

I'm trying to simulate the goto statement but I get an error

===
function testGoto() {
var isFirst = true;

skipPoint:
alert("Using goto\n");

if (isFirst) {
isFirst = false;
continue skipPoint;
alert("This part is skipped");
}
}
===

SyntaxError: label not found
continue skipPoint;

The continue statement must be inside an iteration statement : do,
while, for.

John
 
D

Denis McMahon

I'm trying to simulate the goto statement but I get an error

Why, by all that's sacred why? What possible use is there for a goto
outside, perhaps, assembler?

Rgds

Denis McMahon
 
T

Thomas 'PointedEars' Lahn

Tom said:
The error may have more to do with 'continue' than with the label.
Check where you can use a continue statement - I think it is restricted to
for- and while- loops.

You are mistaken. The `continue' statement, like the Labelled Statement is
just another /Statement/, and it can be located anywhere in a /Program/:

,-[ES 5.1]
|
| 14 Program
|
| Syntax
|
| Program :
| SourceElements_opt
|
| SourceElements :
| SourceElement
| SourceElements SourceElement
|
| SourceElement :
| Statement
| FunctionDeclaration

,-[ibid.]
|
| 12 Statements
|
| Syntax
|
| Statement :
| Block
| VariableStatement
| EmptyStatement
| ExpressionStatement
| IfStatement
| IterationStatement
| ContinueStatement
| […]
| LabelledStatement
| […]
|
| 12.3 Empty Statement
|
| Syntax
| EmptyStatement :
| ;
|
| […]
| 12.7 The continue Statement
|
| Syntax
|
| ContinueStatement :
| continue ;
| continue [no LineTerminator here] Identifier;
|
| […]
| 12.12 Labelled Statements
|
| Syntax
|
| LabelledStatement :
| Identifier : Statement

`skipPoint' is an /Identifier/ and – through Automatic Semicolon Insertion
(ASI) – an /EmptyStatement/ is a /Statement/. One could try placing the
/ExpressionStatement/ – alert(…) – at the same line as the label, but that
should not be necessary in a conforming implementation (which implementation
has been tested with?).

That said, it is certainly not a good idea to "simulate the goto statement".

Please do not post attribution novels: <http://insideoe.com/>


PointedEars
--
If you get a bunch of authors […] that state the same "best practices"
in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
 
G

Gene Wirchenko

Why, by all that's sacred why? What possible use is there for a goto
outside, perhaps, assembler?

Some algorithms are more easily expressed with a goto. This is
not a usual case though.

Sincerely,

Gene Wirchenko
 
E

Evertjan.

Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:
Some algorithms are more easily expressed with a goto.

I do not think so.

Goto makes havoc of a programme,
as programmse should be build from modular blocks,
whose entrees and exits should not be compromized bij wrong levels.

This was already apparent in the time
of Edsger Wybe Dijkstra (1930–2002)
<http://en.wikipedia.org/wiki/Edsger_W._Dijkstra>
who advocated "theoretical correctness" in programming:

Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful" (PDF).
Communications of the ACM 11 (3): 147–148.

and read Edsger's 1968 comment here:

Dijkstra used the word "nested" where we nowadays say "modular".

This is not a usual case though.

Could you elaborate?

I think you mean "this is usually not the case"?
Methinks it never, never is the case.
 
H

Hans-Georg Michna

Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:
I do not think so.

Goto makes havoc of a programme,
as programmse should be build from modular blocks,
whose entrees and exits should not be compromized bij wrong levels.

There are valid exceptions. One prime example is the state
machine, sometimes also called finite-state machine or syntax
machine. By far the fastest and easiest implementation is to go
from one state, implemented as a block of statements or simply a
label, to another with a goto.

I still suspect, like you, that most attempts to use a goto
statement in other contexts than breaking a loop are not very
sensible.

Hans-Georg
 
G

Gene Wirchenko

Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:


I do not think so.

Goto makes havoc of a programme,

No, it does not. It can. Very much use of it practically
guarantees it, but it is not a given. A well-placed goto can simplify
code immensely.
as programmse should be build from modular blocks,
whose entrees and exits should not be compromized bij wrong levels.

Why? I follow this myself, but I might make an exception in an
extreme case.
This was already apparent in the time
of Edsger Wybe Dijkstra (1930–2002)
<http://en.wikipedia.org/wiki/Edsger_W._Dijkstra>
who advocated "theoretical correctness" in programming:

Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful" (PDF).
Communications of the ACM 11 (3): 147–148.

and read Edsger's 1968 comment here:

Dijkstra used the word "nested" where we nowadays say "modular".

<http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1009.html>

Please do not try teaching your grandfather how to suck eggs. I
am quite aware of Dijkstra's opinion. The man was far too doctrinaire
for my taste. Another of his statements was "It is practically
impossible to teach good programming to students that have had a prior
exposure to BASIC: as potential programmers they are mentally
mutilated beyond hope of regeneration." Oh, really?
Could you elaborate?

I think you mean "this is usually not the case"?
Methinks it never, never is the case.

Now, try proving your statement.

One of the sort algorithms, I think quick-sort, has a symmetry
between the front and back pointers that is readily seen if it is
coded with a couple of goto statements, but that does not show so
cleanly when it is not.

Hans-Georg Michna also mentioned a state machine, and having
written a number of them, I concur. It is the best example that I am
aware of.

Exiting from nested loops can be done much more easily with a
goto. Ah, but you may say to use break. break statements, especially
those with a label target, are specialised goto statements. I tend to
avoid using them, but other do prefer them.

Lastly, there is the case when performance is absolutely
critical. In this case, one might well sacrifice clarity. I would
code a sructured version first and test that it really was too slow
before sacrificing, but were it indicated, I would proceed with the
sacrifice.

Sincerely,

Gene Wirchenko
 
E

Evertjan.

Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:
No, it does not. It can. Very much use of it practically
guarantees it, but it is not a given. A well-placed goto can simplify
code immensely.


Why? I follow this myself, but I might make an exception in an
extreme case.


Please do not try teaching your grandfather how to suck eggs. I
am quite aware of Dijkstra's opinion. The man was far too doctrinaire
for my taste.

Your taste about this man is not an issue here, the issue is his sound
explanation of his ideas.
Another of his statements was "It is practically
impossible to teach good programming to students that have had a prior
exposure to BASIC: as potential programmers they are mentally
mutilated beyond hope of regeneration." Oh, really?

Yes quite. BASIC should be understood as the BASIC of thatr time,
not the Visual Basic and its predessesors of young William Gates
that incorporated Dijkstra's ideas from Algol-60 etc.

Perhaps you do not know the level of BASIC at that time,
where only this existed:

IF boolean GOTO

and not yet:

IF boolean THEN

And that corrupted a generation of programmmers for the idea of
"nesting", what we now call modular programing.

Now, try proving your statement.

You first prove yours, I askesd first,
you talk about "Some algorithms are more easily expressed with a goto".

Why should I prove my rebuttal to this unsubstaniated sentence?
One of the sort algorithms, I think quick-sort, has a symmetry
between the front and back pointers that is readily seen if it is
coded with a couple of goto statements, but that does not show so
cleanly when it is not.

What nonsense, recursive programming can just as well be done in a
modular way.

It seems you also are bitten by the goto-bug. Are you that old?

If so, it proves my point NOT to teach new programmers the idea of GOTO
in any language higher than chip microcode or assembler.
Hans-Georg Michna also mentioned a state machine, and having
written a number of them, I concur. It is the best example that I am
aware of.

It seems you to do not know what that means.

The computer is a state m-machine by itself,
governed by a central state stepping clock.

There is nore reason to duplicate that, except for teaching purposes.

Even then there is no necessary or even useful reason to use a goto
there.

But please if you must, show us an example where the goto statement is a
necessary or just usefull statement to use [INSIDE Javascript, this is a
JS NG]

Methinks your would-be pupils will just be set on the wrong foot,
and they won't like you for it if they screw up on modular thinking.
Exiting from nested loops can be done much more easily with a
goto.

No, no, no.
Than you loose the concept of modularity, corrupting inner return
ppoiners in the process. Modern compilers will revover from this, but
with time consuming internal correction code ...

... or hopefully by optimalisation, in fact throwing your GOTO out in an
attempt to restore modularity.
Ah, but you may say to use break. break statements, especially
those with a label target, are specialised goto statements. I tend to
avoid using them, but other do prefer them.

I might not. Break statements are just the means of goto-adepts to
suppress their goto-world-view to a pseudo-modular world.

The other day I expressed my disgust for switch statement,
and I remember you concurred.
Lastly, there is the case when performance is absolutely
critical. In this case, one might well sacrifice clarity. I would
code a sructured version first and test that it really was too slow
before sacrificing, but were it indicated, I would proceed with the
sacrifice.

Show me that case, if you can!

There is no such case in optimizing compilers,
but more to the point, there is not GOTO in javascript.

Implementing such GOTO, as was tried in this thread, will sacrifize any
even unfounded idea of speed gain.
 
T

Tim Streater

Evertjan. said:
But please if you must, show us an example where the goto statement is a
necessary or just usefull statement to use [INSIDE Javascript, this is a
JS NG]

I haven't used a GOTO since I stopped writing FORTRAN in 1978.
No, no, no.
Than you loose the concept of modularity, corrupting inner return
~~~~~

Lose. Please get this right, it is more irritating than anything that
Pointy-Head does.
 
G

Gene Wirchenko

Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:

Are you unable to counter this case?
Your taste about this man is not an issue here, the issue is his sound
explanation of his ideas.

I do not consider that insulting people as mentally mutilated as
he did in the quote following is sound.
Yes quite. BASIC should be understood as the BASIC of thatr time,
not the Visual Basic and its predessesors of young William Gates
that incorporated Dijkstra's ideas from Algol-60 etc.

Perhaps you do not know the level of BASIC at that time,
where only this existed:

And perhaps I know exactly what the BASICs of the time were like.
I do; I used them.
IF boolean GOTO

and not yet:

IF boolean THEN

Actually, quite often the syntax was
IF <expression> THEN <lineno>
where said:
And that corrupted a generation of programmmers for the idea of
"nesting", what we now call modular programing.

Oh, nonsense! When I then ran into other languages, I picked up
their features quickly enough.
You first prove yours, I askesd first,
you talk about "Some algorithms are more easily expressed with a goto".

I have already given an example. You are making the
extraordinary claim. How about you prove yours?
Why should I prove my rebuttal to this unsubstaniated sentence?

I have already given the relevant detail in the following
paragraph.
What nonsense, recursive programming can just as well be done in a
modular way.

I was not referring to the recursion, but to one level of
sorting. Quick sort has a pointer that starts from one end and
another that starts from the other. With the pair of goto statements,
the symmetry is readily apparent.
It seems you also are bitten by the goto-bug. Are you that old?

No, I am not bitten by it. I simply refuse to totally demonise
goto statements. I do not use goto statements but rarely, but
sometimes, they are acceptable.

At 51, probably.
If so, it proves my point NOT to teach new programmers the idea of GOTO
in any language higher than chip microcode or assembler.


It seems you to do not know what that means.

Since I have written a number of state machines, I do know what
it means.
The computer is a state m-machine by itself,
governed by a central state stepping clock.

Oh, I know, but Mr. Michna and I are referring to something else:
applications that have state machines.
There is nore reason to duplicate that, except for teaching purposes.

A compiler typically uses state machines. I use state machines
in certain validation routines for a client billing app I support.
There are plenty of other examples. Try writing a calculator program
without using a state machine.
Even then there is no necessary or even useful reason to use a goto
there.

I have found it useful.
But please if you must, show us an example where the goto statement is a
necessary or just usefull statement to use [INSIDE Javascript, this is a
JS NG]

Probably less necessary since JavaScript code is typically not
very long and not very time-sensitive.
Methinks your would-be pupils will just be set on the wrong foot,
and they won't like you for it if they screw up on modular thinking.

Actually, I have successfully taught people programming. I would
not make the mistake of telling them that goto statements are pure
evil. I would tell them why it is not a good idea, in general, to use
them and where they might, might use them to good advantage. I would
also note that it is probably less often than they think.
No, no, no.
Than you loose the concept of modularity, corrupting inner return
ppoiners in the process. Modern compilers will revover from this, but
with time consuming internal correction code ...

In many languages, those blocks are now out of scope and their
variables will be tossed.
.. or hopefully by optimalisation, in fact throwing your GOTO out in an
attempt to restore modularity.


I might not. Break statements are just the means of goto-adepts to
suppress their goto-world-view to a pseudo-modular world.

I do prefer the use of control variables. The client billing app
I just referred to has none -- I just checked -- but I do not consider
that my view rules over all.
The other day I expressed my disgust for switch statement,
and I remember you concurred.

I do not like switch because of bad syntax (just plain bad and
because it breeds errors) and semantic limitations.
Show me that case, if you can!

Do some reading on your own. When one is extremely constrained
in what one is programming, some of the usual practices get tossed. I
have read of programmers describing how they had to fit their code in
2048 bytes and no more. To do such things, they would load opcodes to
do arithmetic, because the particular opcode had the right value.

Yes, very unreadable code, but too long of code, in that case,
was so wrong that it would not run.
There is no such case in optimizing compilers,
but more to the point, there is not GOTO in javascript.

The goto statement in JavaScript is continue.
Implementing such GOTO, as was tried in this thread, will sacrifize any
even unfounded idea of speed gain.

Maybe. If it really mattered on the time issue, I would
benchmark it.

Sincerely,

Gene Wirchenko
 
D

Denis McMahon

There are valid exceptions. One prime example is the state machine,
sometimes also called finite-state machine or syntax machine. By far the
fastest and easiest implementation is to go from one state, implemented
as a block of statements or simply a label, to another with a goto.

I still suspect, like you, that most attempts to use a goto statement in
other contexts than breaking a loop are not very sensible.

If you want to break a loop, most languages have a "break" or similar
statement which gives control to the instruction following the loop -
this is normally where you would want to go when exiting the loop.

goto may in some cases still be in use to support old code (I understand
that in some market sectors code that is several decades old written in
the likes of algol, fortran and cobol is still in use), and of course in
assembler and at the machine code and microcode levels both conditional
and unconditional jumps tend to be pretty common, however I am unable to
conceive of any situation where a "simulated goto" might actually be
useful in javascript.

Rgds

Denis McMahon
 
M

Mike Duffy

Lose. Please get this right, it is more irritating than anything that
Pointy-Head does.


1. It seems like a minor error; possibly even a typo. The sense of what he
meant was abundantly clear. In fact, he may have been deliberately
deploying a pun.

2. Is PE our community-accepted standard for guaging the irritation level
of grammar and spelling errors?
 
J

John G Harris

There are valid exceptions. One prime example is the state
machine, sometimes also called finite-state machine or syntax
machine. By far the fastest and easiest implementation is to go
from one state, implemented as a block of statements or simply a
label, to another with a goto.

I still suspect, like you, that most attempts to use a goto
statement in other contexts than breaking a loop are not very
sensible.

Bjarne Stroustrup (the inventor of C++) wrote that goto is for code
generators where the program writing the code isn't going to get
confused. E.g A program that reads a syntax specification and writes a
parser for the language.

John
 
J

John G Harris

1. It seems like a minor error; possibly even a typo. The sense of what he
meant was abundantly clear. In fact, he may have been deliberately
deploying a pun.

It's a spelling error that's been popular for around 15 years. It's very
likely that it's been spread by the internet. Even teachers and
journalists make the mistake. And I also think it's very irritating.

It makes life very difficult for dictionary compilers :

loose (v)
(1) Obsolete spelling of lose, q.v.
(2) ...

lose (v)
(1) Obsolete spelling of loose, q.v.
(2) ...

And finally :
If 'lose' is now spelt with oo, is 'loosen' the plural of 'luser' ?

John
 
J

John G Harris

Tom de Neef wrote:


You are mistaken. The `continue' statement, like the Labelled Statement is
just another /Statement/, and it can be located anywhere in a /Program/:
<snip>

Now look at section 12.7 of ECMAScript 262, 5.1 Edition, at the text
following
"A program is considered syntactically incorrect if either of
the following is true:"
which disagrees with you.

John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top