Simulate goto

Discussion in 'Javascript' started by Archos, Dec 27, 2011.

  1. Archos

    Archos Guest

    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;
     
    Archos, Dec 27, 2011
    #1
    1. Advertising

  2. Archos

    Archos Guest

    On Dec 27, 9:19 am, 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;


    I just find the failure. In JS, it must have a statement after of the
    label
     
    Archos, Dec 27, 2011
    #2
    1. Advertising

  3. Archos

    Archos Guest

    On Dec 27, 9:50 am, Archos <> wrote:
    > On Dec 27, 9:19 am, 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;

    >
    > 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
     
    Archos, Dec 27, 2011
    #3
  4. Archos

    Erwin Moller Guest

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

    >>
    >> 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
     
    Erwin Moller, Dec 27, 2011
    #4
  5. Archos

    Tom de Neef Guest

    "Archos" <> schreef in bericht
    news:...
    > 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
     
    Tom de Neef, Dec 27, 2011
    #5
  6. 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
     
    John G Harris, Dec 27, 2011
    #6
  7. 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
     
    Denis McMahon, Dec 27, 2011
    #7
  8. Tom de Neef wrote:

    > "Archos" <> 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
     
    Thomas 'PointedEars' Lahn, Dec 27, 2011
    #8
  9. On 27 Dec 2011 15:32:33 GMT, Denis McMahon <>
    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
     
    Gene Wirchenko, Dec 27, 2011
    #9
  10. Archos

    Evertjan. Guest

    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)
     
    Evertjan., Dec 27, 2011
    #10
  11. 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
     
    Hans-Georg Michna, Dec 27, 2011
    #11
  12. 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,


    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?

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


    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
     
    Gene Wirchenko, Dec 27, 2011
    #12
  13. Archos

    Evertjan. Guest

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

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

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


    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.


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

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


    > Sincerely,
    >
    > Gene Wirchenko
    >




    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Dec 27, 2011
    #13
  14. Archos

    Tim Streater Guest

    In article <Xns9FC8EA64D857Feejj99@194.109.133.133>,
    "Evertjan." <> wrote:

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

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Dec 27, 2011
    #14
  15. On 27 Dec 2011 22:02:32 GMT, "Evertjan."
    <> wrote:

    >Gene Wirchenko wrote on 27 dec 2011 in comp.lang.javascript:
    >
    >> 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,

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


    Are you unable to counter this case?

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

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

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


    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 <expression> was very simple indeed: no boolean operators.

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

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

    >>
    >> Now, try proving your statement.

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

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


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


    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.

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


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


    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.

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


    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
     
    Gene Wirchenko, Dec 27, 2011
    #15
  16. 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
     
    Denis McMahon, Dec 27, 2011
    #16
  17. Archos

    Mike Duffy Guest

    Tim Streater <> wrote in
    news::

    > In article <Xns9FC8EA64D857Feejj99@194.109.133.133>,
    > "Evertjan." <> wrote:


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



    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?

    --
    http://pages.videotron.ca/duffym/index.htm
     
    Mike Duffy, Dec 28, 2011
    #17
  18. On Tue, 27 Dec 2011 at 21:49:38, in comp.lang.javascript, 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.


    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
    --
    John Harris
     
    John G Harris, Dec 28, 2011
    #18
  19. On Wed, 28 Dec 2011 at 00:23:28, in comp.lang.javascript, Mike Duffy
    wrote:
    >Tim Streater <> wrote in
    >news::
    >
    >> In article <Xns9FC8EA64D857Feejj99@194.109.133.133>,
    >> "Evertjan." <> wrote:

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

    >
    >
    >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
    --
    John Harris
     
    John G Harris, Dec 28, 2011
    #19
  20. 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
     
    John G Harris, Dec 28, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Amir Eshterayeh

    simulate virtual directory - I need it urgently

    Amir Eshterayeh, Feb 3, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    528
    caviar
    Feb 5, 2004
  2. Max

    I cannot simulate

    Max, Sep 12, 2003, in forum: VHDL
    Replies:
    1
    Views:
    570
  3. usao
    Replies:
    1
    Views:
    757
    Allan Herriman
    Apr 14, 2004
  4. abilash
    Replies:
    1
    Views:
    591
    Jim Lewis
    May 17, 2005
  5. Juan Carlos Allica
    Replies:
    0
    Views:
    1,116
    Juan Carlos Allica
    Jul 15, 2005
Loading...

Share This Page