Simulate goto

[Tim Streater]

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.

All the more reason to stamp on it.

 

[Thomas 'PointedEars' Lahn]

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.

No, but it disagrees with the implications of my statement regarding this
problem. A `continue' statement *can* be located anywhere in a /Program/.
However, there are restrictions as to location of the label that may be
referred by the optional /Identifier/.

AIUI, it should be possible to use an enclosing /Statement/ (like a /Block/
statement) and a `break' statement here (section 12.8):

function testGoto()
{
var isFirst = true;
if (true)
{
skipPoint:
window.alert("Using goto\n");

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

However, Google V8 3.5.10.9+ in Chromium 15.0.874.121 (Developer Build
109964 Linux) considers that a syntax error as well (same error message:
"SyntaxError: Undefined label 'skipPoint'"). Is this a bug?


PointedEars

 

[Nomen Nescio]

I still suspect, like you, that most attempts to use a goto
Depends on the language. GOTO is idiomatic in many older (foundation)
languages while inappropriate in most newer ones. That has led the snot
nosed kids to believe GOTO is old outmoded bad etc. It is not. It has its
place but that place is not C or languages derived from C (although the
Linux kernel developers use it and will give you a good spanking if you
criticise them).

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.

That might be the case in C++ and he should know since he wrote it.

But GOTO is for mere humans when coding in F77, COBOL, BASIC, and many other
languages that were written before C.

 

[Mike Duffy]

All the more reason to stamp on it.

If it is a mistake being made by teachers and journalists, I agree. If it
is a mistake being made by someone who learned English as a second language
(like Evertjan / PE), then you should probably make some allowance.

 

[Gene Wirchenko]

If it is a mistake being made by teachers and journalists, I agree. If it
is a mistake being made by someone who learned English as a second language
(like Evertjan / PE), then you should probably make some allowance.

I often see better English on the Net from ESLers than native
speakers.

Sincerely,

Gene Wirchenko

 

[Evertjan.]

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

Well, unlike PE as I presume, English was! my first language, but when I
started learning to write, Dutch was my primary one.

I often see better English on the Net from ESLers than native
speakers.

Quite so, nativity induces naivity in language, especially in monoglots.

As soon as Tim's Dutch is better than mine, I would be inclined to listen
to him in this case.

Even more so, Netiquette says it is inappropriate co comment on spelling-
mistakes in NG that do not have that as a topic.

Methinks that is because it acts as a loose goto in a close-topiced tread.

loose [lOOs] adj [...]; (of bowels) inclined to diarrhoea;[...]

 

[Thomas 'PointedEars' Lahn]

No.
Why should it work?
I think there is slight confusion as to what it means for a statement to
be 'enclosing' another.

No, but there was a misconception on my part as to the definition of a label
set:

| 12 Statements
|
| Semantics
|
| A /Statement/ can be part of a /LabelledStatement/, which itself can be
| part of a /LabelledStatement/, and so on. The labels introduced this way
| are collectively referred to as the "current label set" when describing
| the semantics of individual statements. A /LabelledStatement/ has no
| semantic meaning other than the introduction of a label to a /label set/.
| The label set of an /IterationStatement/ or a /SwitchStatement/ initially
| contains the single element empty. The label set of any other statement is
| initially empty.
|
| […]
| 12.12 Labelled Statements
|
| The production /Identifier/ : /Statement/ is evaluated by adding
| /Identifier/ to the label set of /Statement/ and then evaluating
| /Statement/. If the /LabelledStatement/ itself has a non-empty label set,
| these labels are also added to the label set of /Statement/ before
| evaluating it. If the result of evaluating Statement is (break, V, L)
| where L is equal to /Identifier/, the production results in (normal, V,
| empty).
|
| Prior to the evaluation of a /LabelledStatement/, the contained
| /Statement/ is regarded as possessing an empty label set, unless it is an
| /IterationStatement/ or a /SwitchStatement/, in which case it is regarded
| as possessing a label set consisting of the single element, empty.

That is, the label set of a statement consists of the labels used for *that*
statement, _not_ the labels used *within* it. Therefore, the following is
syntactically correct and compiles in the named implementation without
error:

function testGoto()
{
var counter = 0;

skipPoint:
{
window.alert(counter);

if (counter === 0)
{
++counter;
break skipPoint;
window.alert("This part is skipped");
}
}
}

However, this does _not_ "simulate goto", i. e. the counter is only shown
once. That is – unless I am overlooking something – intended by the
Specification: The `break' statement with /Identifier/ merely ends the
evaluation of the so labelled statement prematurely:

| A /BreakStatement/ with an /Identifier/ is evaluated as follows:
|
| 1. Return (break, empty, /Identifier/).

See section 12.12 quoted above on how that result affects the evaluation of
the enclosing statement labelled with /Identifier/.


PointedEars

 

[John G Harris]

function testGoto()
{
var counter = 0;

skipPoint:
{
window.alert(counter);

if (counter === 0)
{
++counter;
break skipPoint;
window.alert("This part is skipped");
}
}
}

<snip>


There is no IterationStatement in the function.
'skipPoint' doesn't label an IterationStatement.
The break statement contains an Identifier.
The break statement is not contained in any IterationStatement.

When you test these facts with the horribly written text in
section 12.7 :
"The program contains a continue statement with the optional
Identifier, where Identifier does not appear in the label set of
an enclosing (but not crossing function boundaries)
IterationStatement"
then you can only conclude that the program fragment contains a syntax
error.

What the browser will do is not specified, unfortunately, but it would
be foolish to rely on all browsers doing the same thing.


For the proper use of the identifier it's easier to look at the Mozilla
online reference manual :

"The continue statement can include an optional label that allows the
program to jump to the next iteration of a labelled loop statement
instead of the current loop. In this case, the continue statement
needs to be nested within this labelled statement."

John

 

[Thomas 'PointedEars' Lahn]

<snip>


There is no IterationStatement in the function.

That is irrelevant as I am _not_ using the `continue' statement.

'skipPoint' doesn't label an IterationStatement.

Therefore, also irrelevant.

The break statement contains an Identifier.
Correct.

The break statement is not contained in any IterationStatement.

Irrelevant. If you read section 12.8 (instead of section 12.7), you will
observe that the labelled statement that can be used with the `break'
statement is governed by other rules than that for a `continue' statement:
A labelled /Statement/ suffices. The /Block/ statement (`{…}') is such a
/Statement/ (see the grammar productions posted before).

When you test these facts with the horribly written text in
section 12.7 :
"The program contains a continue statement with the optional
Identifier, where Identifier does not appear in the label set of
an enclosing (but not crossing function boundaries)
IterationStatement"
then you can only conclude that the program fragment contains a syntax
error.

No, because it does _not_ contain a `continue' statement, but a `break'
statement.

[snip further misconceptions]

Please learn to read. Google V8 parses the source code (as the function
above is declared) and evaluates the above /Program/ (as the function above
is called) to the letter of the standard here.


PointedEars

 

[John G Harris]

That is irrelevant as I am _not_ using the `continue' statement.

<snip>

Good heavens, I've subconsciously assumed that you hadn't changed the
thread topic in the middle of disagreeing with me. It must be the way
that you say it.

Yes, break can be used to jump to the end of an enclosing block. Of
course, your next (non-) problem is that Crockford will flag your block
labelled skipPoint as a syntax error.

The thing that will disappoint the OP is that neither continue nor break
can jump to a given label, nor can they jump backwards, so it's not
possible to use them to simulate a general goto.

John

 

[Thomas 'PointedEars' Lahn]

Yes, break can be used to jump to the end of an enclosing block.

That is not quite it.

Of course, your next (non-) problem is that Crockford will flag your block
labelled skipPoint as a syntax error.
Interesting.

The thing that will disappoint the OP is that neither continue nor break
can jump to a given label, nor can they jump backwards, so it's not
possible to use them to simulate a general goto.

AISB.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <6rgnf75echlnruev288nmmfpilgnecg3sa@4ax.

I often see better English on the Net from ESLers than native
speakers.

Most of the self-called "native English speakers" are native to your
Southern Neighbour. But, with the exception of a petrol-pump attendant
in s'H... ...h, the Dutch that I have had dealings with all speak and
write English so well that there is no reason not to drive them to
perfection.

 

[Tim Streater]

In comp.lang.javascript message <6rgnf75echlnruev288nmmfpilgnecg3sa@4ax.


Most of the self-called "native English speakers" are native to your
Southern Neighbour. But, with the exception of a petrol-pump attendant
in s'H... ...h, the Dutch that I have had dealings with all speak and
write English so well that there is no reason not to drive them to
perfection.

Indeed. I once had occasion to call someone at Unisource in, IIRC,
Amsterdam. I misdialled and ended up with a random person elsewhere in
the Netherlands. This individual responded perfectly well in English.

Even meerkats speak English. See:

<http://www.comparethemeerkat.com/>