Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #9632 > unrolled thread

Simulate goto

Back to article view | Back to comp.lang.javascript

Contents

  Simulate goto Archos <raul.san@sent.com> - 2011-12-27 01:19 -0800
    Re: Simulate goto Archos <raul.san@sent.com> - 2011-12-27 01:50 -0800
      Re: Simulate goto Archos <raul.san@sent.com> - 2011-12-27 02:09 -0800
        Re: Simulate goto Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-12-27 11:31 +0100
    Re: Simulate goto "Tom de Neef" <tdeneef@qolor.nl> - 2011-12-27 12:12 +0100
      Re: Simulate goto Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-27 18:27 +0100
        Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-28 16:56 +0000
          Re: Simulate goto Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-28 19:10 +0100
            Re: Simulate goto Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-28 23:18 +0100
              Re: Simulate goto Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-29 12:18 +0100
                Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-29 16:31 +0000
                  Re: Simulate goto Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-29 17:47 +0100
                    Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-30 11:04 +0000
                      Re: Simulate goto Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-30 16:10 +0100
    Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-27 14:41 +0000
    Re: Simulate goto Denis McMahon <denismfmcmahon@gmail.com> - 2011-12-27 15:32 +0000
      Re: Simulate goto Gene Wirchenko <genew@ocis.net> - 2011-12-27 10:12 -0800
        Re: Simulate goto "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-27 19:55 +0000
          Re: Simulate goto Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-12-27 21:49 +0100
            Re: Simulate goto Denis McMahon <denismfmcmahon@gmail.com> - 2011-12-27 23:07 +0000
            Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-28 16:28 +0000
              Re: Simulate goto Nomen Nescio <nobody@dizum.com> - 2011-12-28 22:33 +0100
          Re: Simulate goto Gene Wirchenko <genew@ocis.net> - 2011-12-27 13:19 -0800
            Re: Simulate goto "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-27 22:02 +0000
              Re: Simulate goto Tim Streater <timstreater@greenbee.net> - 2011-12-27 22:18 +0000
                Re: Simulate goto Mike Duffy <Use_guestbook_page@website.in.sig> - 2011-12-28 00:23 +0000
                  Re: Simulate goto John G Harris <john@nospam.demon.co.uk> - 2011-12-28 16:37 +0000
                    Re: Simulate goto Tim Streater <timstreater@greenbee.net> - 2011-12-28 17:44 +0000
                      Re: Simulate goto Mike Duffy <Use_guestbook_page@website.in.sig> - 2011-12-29 01:16 +0000
                        Re: Simulate goto Gene Wirchenko <genew@ocis.net> - 2011-12-28 17:34 -0800
                          Re: Simulate goto "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-12-29 08:27 +0000
                          Re: Simulate goto Dr J R Stockton <reply1152@merlyn.demon.co.uk> - 2011-12-30 20:54 +0000
                            Re: Simulate goto Tim Streater <timstreater@greenbee.net> - 2011-12-31 11:55 +0000
              Re: Simulate goto Gene Wirchenko <genew@ocis.net> - 2011-12-27 14:50 -0800

Page 1 of 2  [1] 2  Next page →

#9632 — Simulate goto

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;

[toc] | [next] | [standalone]

#9633

On Dec 27, 9:19 am, Archos <raul....@sent.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#9634

On Dec 27, 9:50 am, Archos <raul....@sent.com> wrote:
> On Dec 27, 9:19 am, Archos <raul....@sent.com> wrote:
>
>
>
> > 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

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

[toc] | [prev] | [next] | [standalone]

#9635

On 12/27/2011 11:09 AM, Archos wrote:
> On Dec 27, 9:50 am, Archos<raul....@sent.com>  wrote:
>> On Dec 27, 9:19 am, Archos<raul....@sent.com>  wrote:
>>
>>
>>
>>> 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
>
> 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


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#9636

"Archos" <raul.san@sent.com> schreef in bericht 
news:ef9039a7-0cf7-4887-a98e-81c49968555b@p42g2000vbt.googlegroups.com...
> 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

[toc] | [prev] | [next] | [standalone]

#9677

Tom de Neef wrote:

> "Archos" <raul.san@sent.com> schreef […]
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#9729

On Tue, 27 Dec 2011 at 18:27:03, in comp.lang.javascript, Thomas 
'PointedEars' Lahn wrote:
>Tom de Neef wrote:

   <snip>
>> 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/:
   <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
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#9737

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tom de Neef wrote:
>>> 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/:
> 
> 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
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#9744

On 28.12.2011 19:10, Thomas 'PointedEars' Lahn wrote:
> John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Tom de Neef wrote:
>>>> 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/:
>>
>> 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?
>

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

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9759

Jake Jarvis wrote:

> On 28.12.2011 19:10, Thomas 'PointedEars' Lahn wrote:
>> 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?
> 
> 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
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#9768

On Thu, 29 Dec 2011 at 12:18:00, in comp.lang.javascript, Thomas 
'PointedEars' Lahn wrote:

   <snip>
>  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
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#9769

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>>  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.

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
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#9779

On Thu, 29 Dec 2011 at 17:47:58, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>>  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.
>
>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
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#9782

John G Harris wrote:

> 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
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#9644

On Tue, 27 Dec 2011 at 01:19:21, in comp.lang.javascript, Archos wrote:
>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
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#9647

On Tue, 27 Dec 2011 01:19:21 -0800, Archos wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#9679

On 27 Dec 2011 15:32:33 GMT, Denis McMahon <denismfmcmahon@gmail.com>
wrote:

>On Tue, 27 Dec 2011 01:19:21 -0800, Archos wrote:
>
>> 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?

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

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9689

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".

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

>  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.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9692

On 27 Dec 2011 19:55:41 GMT, Evertjan. wrote:

>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.

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

[toc] | [prev] | [next] | [standalone]

#9697

On Tue, 27 Dec 2011 21:49:38 +0100, Hans-Georg Michna wrote:

> On 27 Dec 2011 19:55:41 GMT, Evertjan. wrote:
> 
>>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.
> 
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web