GOTO in Javascript

[David Given]

I have a situation where I need to use GOTO in a Javascript program.

No, I can't use break or continue. Yes, I really do know what I'm doing.
What I've got is a huge mass of automatically generated code that
contains thousands of clauses like this:

label1:
...do something...
if (condition)
goto label3;
else
goto label9;

This situation is exactly what GOTO is the ideal tool for. Except that
Javascript doesn't have GOTO.

One alternative is to use tail calls, so that each block would turn into
a function like this:

function label1()
{
...do something...
if (condition)
return label3();
else
return label9();
}

Unfortunately, Javascript doesn't support tail calls either --- each
function call adds another entry to the stack which means I only get a
few thousand calls before everything grinds to a halt.

The only other thing I can think of is to use a switch statement like this:

while (true)
{
switch (label)
{
case 1:
...do something...
if (condition)
label = 3;
else
label = 9;
break;
}
}

However this is going to do horrible things to my performance due to
having to keep reading and writing the label variable; also, I'm very
dubious has to how well Javascript switch statements perform with very
big numbers of entries (thousands, remember).

Can anyone suggest anything else I could try?

--
┌─── ｄｇï¼*ｃï½�ｗｌï½�ｒｋ．ｃï½�ï½� ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Joost Diepenmaat]

David Given <[e-mail]:

I have a situation where I need to use GOTO in a Javascript program.

[ ... ]

Unfortunately, Javascript doesn't support tail calls either --- each
function call adds another entry to the stack which means I only get a
few thousand calls before everything grinds to a halt.

So, you're calling recursively? If not, there are plenty fairly simple
solutions.

The only other thing I can think of is to use a switch statement like this:

while (true)
{
switch (label)
{
case 1:
...do something...
if (condition)
label = 3;
else
label = 9;
break;
}
}

Actually, this doesn't look too bad at all.

However this is going to do horrible things to my performance due to
having to keep reading and writing the label variable; also, I'm very
dubious has to how well Javascript switch statements perform with very
big numbers of entries (thousands, remember).

You're only writing the label variable once per iteration, and
probably not reading it much more than once either. I haven't tried
it, but I would be completely astonished if a simple variable
assignment + read is going to make any appreciable slowdown.

Due to the way switch/case is defined in JS (it's defined in terms of
!==), I would guess it would perform fairly well regardless of the
number of cases. AFAICS it would be comparable to:

var label;
var myswitch = {
something: function() {
// stuff;
label = "somethingelse";
},
somethingelse: function() {
// stuff;
label = "something";
}
};
while (true) {
myswitch[label]();
}

Which can be pretty well optimized in theory at least (you can cache
the hash code for strings, and numbers can provide their own).

Can anyone suggest anything else I could try?

I suggest you run a few benchmarks first and profile some stuff before
you discount your current strategy. Also: firebug has a fairly useful
profiler, so check that out too; maybe the performance issues you're
seeing aren't really due to the switch statement.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Thomas 'PointedEars' Lahn]

David Given wrote:

I have a situation where I need to use GOTO in a Javascript program.

No, I can't use break or continue. Yes, I really do know what I'm doing.

^^^^^^^^^^^^^^^^
There is a "not" missing.

What I've got is a huge mass of automatically generated code that

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

contains thousands of clauses like this:

label1:
...do something...
if (condition)
goto label3;
else
goto label9;

See?

This situation is exactly what GOTO is the ideal tool for. Except that
Javascript doesn't have GOTO.

BASIC's GOTO nonsense stopped being implemented in higher-level programming
language which provide better ways to implement program logic. You are
well-advised to learn them.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[David Given]

Joost Diepenmaat wrote:
[...]

You're only writing the label variable once per iteration, and
probably not reading it much more than once either. I haven't tried
it, but I would be completely astonished if a simple variable
assignment + read is going to make any appreciable slowdown.

Due to the way switch/case is defined in JS (it's defined in terms of
!==), I would guess it would perform fairly well regardless of the
number of cases.

Do Javascript switches on simple integers turn into jump tables? I'd
really rather not have to to do a dictionary lookup on each state
change. In particular, given that most Javascript interpreters implement
variables as entries in a scope-specific dictionary, this means we're
theoretically getting *three* dictionary lookups per state change. I
realise that modern interpreters will optimise at least some of this,
but given the operation I'm trying to do is so utterly basic I still
resent having to waste cycles.

What I've got, you see, is a huge collection of states generated with
code; control flow transfers from state to state arbitrarily and
extremely frequently. Wasted cycles on state changes will directly
impact performance in a very big way. Despite the goto-is-evil nonsense
that you hear so much of (mostly from people who don't know what they're
talking about), it really is the best tool for the job here...

[...]

I suggest you run a few benchmarks first and profile some stuff before
you discount your current strategy. Also: firebug has a fairly useful
profiler, so check that out too; maybe the performance issues you're
seeing aren't really due to the switch statement.

I'll admit that I haven't actually tried running code yet --- this is
still speculative before I start work on the code generator (which is
currently designed to emit code for a language that actually does have a
GOTO).

--
┌─── ｄｇï¼*ｃï½�ｗｌï½�ｒｋ．ｃï½�ï½� ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Thomas 'PointedEars' Lahn]

David Given wrote:

Joost Diepenmaat wrote:
[...]

>You're only writing the label variable once per iteration, and
probably not reading it much more than once either. I haven't tried
it, but I would be completely astonished if a simple variable
assignment + read is going to make any appreciable slowdown.

Due to the way switch/case is defined in JS (it's defined in terms of
!==), I would guess it would perform fairly well regardless of the
number of cases.

Do Javascript switches on simple integers turn into jump tables?

I beg your pardon?

I'd really rather not have to to do a dictionary lookup on each state
change. In particular, given that most Javascript interpreters implement
variables as entries in a scope-specific dictionary, this means we're
theoretically getting *three* dictionary lookups per state change.

No, it does not. Expressions are evaluated first.

I realise that modern interpreters will optimise at least some of this,
but given the operation I'm trying to do is so utterly basic I still
resent having to waste cycles.

ISTM you don't know what you are talking about. To begin with, you are
repeating the usual half-wit nonsense about a single programming language
where there are in fact several different implementations of ECMAScript,
of which only one you could really know all this about.

What I've got, you see, is a huge collection of states generated with
code; control flow transfers from state to state arbitrarily and
extremely frequently. Wasted cycles on state changes will directly
impact performance in a very big way. Despite the goto-is-evil nonsense
that you hear so much of (mostly from people who don't know what they're
talking about), it really is the best tool for the job here...

Yeah, well, see above.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Joost Diepenmaat]

David Given <[e-mail]:

Do Javascript switches on simple integers turn into jump tables? I'd
really rather not have to to do a dictionary lookup on each state
change.

The difference between a jump table and a dictionary lookup isn't (or
shouldn't be) all that large, especially given that everything else in
JS is pretty slow anyway.

In particular, given that most Javascript interpreters implement
variables as entries in a scope-specific dictionary, this means we're
theoretically getting *three* dictionary lookups per state change.

Not if the state variable is in the top-most scope. Which it will be
in this case. Scopes chains are (probably) simple stacks.

All this depends on the implementation of course.

I realise that modern interpreters will optimise at least some of
this, but given the operation I'm trying to do is so utterly basic I
still resent having to waste cycles.

How much it matters is completely dependent on how much work you're
doing in between state changes. If the work being done is trivial,
then you may have to rethink your strategy.

What I've got, you see, is a huge collection of states generated with
code; control flow transfers from state to state arbitrarily and
extremely frequently. Wasted cycles on state changes will directly
impact performance in a very big way. Despite the goto-is-evil nonsense
that you hear so much of (mostly from people who don't know what they're
talking about), it really is the best tool for the job here...

But maybe javascript isn't. :-) Or maybe try to reduce the number of
state changes, IOW *increase* the number of states - while you're
generating code anyway.

[...]

>I suggest you run a few benchmarks first and profile some stuff before
you discount your current strategy. Also: firebug has a fairly useful
profiler, so check that out too; maybe the performance issues you're
seeing aren't really due to the switch statement.

I'll admit that I haven't actually tried running code yet --- this is
still speculative before I start work on the code generator (which is
currently designed to emit code for a language that actually does have a
GOTO).

Well, since you're automatically generating code, it shouldn't be too
hard to test a few different constructs at least.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[David Given]

Joost Diepenmaat wrote:
[...]

>In particular, given that most Javascript interpreters implement
variables as entries in a scope-specific dictionary, this means we're
theoretically getting *three* dictionary lookups per state change.

Not if the state variable is in the top-most scope. Which it will be
in this case. Scopes chains are (probably) simple stacks.

Ah, good, that'll save a fair bit of time. (The entire state machine
will live in a single large function --- although I will have multiple
state machines in different functions, they're all independent).

All this depends on the implementation of course.

Indeed.

[...]

How much it matters is completely dependent on how much work you're
doing in between state changes. If the work being done is trivial,
then you may have to rethink your strategy.

Unfortunately the work *is* like to be trivial. Alas, what work is done
and what states that are being emitted depend very much on the input
material to the code generator, which I don't have any control over.

[...]

Well, since you're automatically generating code, it shouldn't be too
hard to test a few different constructs at least.

Indeed. I'll give the switch method a try and see how that works out. As
you say, Javascript is fundamentally slow anyway...

--
┌─── ｄｇï¼*ｃï½�ｗｌï½�ｒｋ．ｃï½�ï½� ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

David Given wrote:

>I realise that modern interpreters will optimise at least some of this,
but given the operation I'm trying to do is so utterly basic I still
resent having to waste cycles.

ISTM you don't know what you are talking about. To begin with, you are
repeating the usual half-wit nonsense about a single programming language
where there are in fact several different implementations of ECMAScript,
of which only one you could really know all this about.

Rather three, KJS has always been and Apple JavaScriptCore went open source,
too. (Did I forget another one?)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Tom de Neef]

"David Given" <[e-mail] in bericht
news:48***********************@news.aaisp.net.uk.. .

>I have a situation where I need to use GOTO in a Javascript program.

No, I can't use break or continue. Yes, I really do know what I'm doing.
What I've got is a huge mass of automatically generated code that
contains thousands of clauses like this:

label1:
...do something...
if (condition)
goto label3;
else
goto label9;

Could you implement these code parts as functions and assign them to array
elements?
eg:

var codeparts = []
codeparts[1] = function ()
{ ...do something...
if (condition) return 3 else return 9
}

codeparts[2] = function ()
{ ...do something...
if (condition) return 7 else return 11
}

etc..

var state = 1
while (state) { state = codeparts[state] }

Tom

[The Magpie]

David Given wrote:

I have a situation where I need to use GOTO in a Javascript program.

I have been a professional programmer and analyst for more than thrity
years. So far, I have never yet found a single case where I *had* to
use a "goto". There are always alternatives.

[RoLo]

On Jul 7, 5:58 pm, David Given <[e-mail]:

I have a situation where I need to use GOTO in a Javascript program.

No, I can't use break or continue. Yes, I really do know what I'm doing.
What I've got is a huge mass of automatically generated code that
contains thousands of clauses like this:

label1:
...do something...
if (condition)
goto label3;
else
goto label9;

This situation is exactly what GOTO is the ideal tool for. Except that
Javascript doesn't have GOTO.

One alternative is to use tail calls, so that each block would turn into
a function like this:

function label1()
{
...do something...
if (condition)
return label3();
else
return label9();

}

Unfortunately, Javascript doesn't support tail calls either --- each
function call adds another entry to the stack which means I only get a
few thousand calls before everything grinds to a halt.

The only other thing I can think of is to use a switch statement like this:

while (true)
{
switch (label)
{
case 1:
...do something...
if (condition)
label = 3;
else
label = 9;
break;
}

}

However this is going to do horrible things to my performance due to
having to keep reading and writing the label variable; also, I'm very
dubious has to how well Javascript switch statements perform with very
big numbers of entries (thousands, remember).

Can anyone suggest anything else I could try?

--
$B(#(!(!(!(B $B#d#g!w#c#o#w#l#a#r#k!%#c#o#m(B $B(!(!(!(!(!(Bhttp://www.cowlark.com$B(!(!(!(!(!(B
$B("(B "I have always wished for my computer to be as easy to use as my
$B("(B telephone; my wish has come true because I can no longer figure out
$B("(B how to use my telephone." --- Bjarne Stroustrup

templates in javascript.

[Evertjan.]

The Magpie wrote on 08 jul 2008 in comp.lang.javascript:

David Given wrote:

>I have a situation where I need to use GOTO in a Javascript program.

I have been a professional programmer and analyst for more than thrity
years. So far, I have never yet found a single case where I *had* to
use a "goto". There are always alternatives.

I am programming for 40 years now and remember it came as a blow to me when
Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
in Byte [1968] declared "goto" in Basic the worst word in programming,
because it made thinking modular impossible.

The word "modular" was not part of his typewritten accusation, but I am
sure he mant that. I did not understand modular programming then, and even
now I do not use all it's benefits, I suppose.

A Case against the GO TO Statement typewritten original
<http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF>
html transcript:
<http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html>

Edsger Wybe Dijkstra
<http://en.wikipedia.org/wiki/Edsger_Dijkstra>

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

[Tom de Neef]

"Tom de Neef" <td*****@qolor.nlwrote

<snip>

>
var state = 1
while (state) { state = codeparts[state] }

should be
while (state) { state = codeparts[state]() }

Tom

[Bart Van der Donck]

Evertjan. wrote:

The Magpie wrote on 08 jul 2008 in comp.lang.javascript:

>I have been a professional programmer and analyst for more than thrity
years. So far, I have never yet found a single case where I *had* to
use a "goto". There are always alternatives.

I am programming for 40 years now and remember it came as a blow to me when
Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
in Byte [1968] declared "goto" in Basic the worst word in programming,
because it made thinking modular impossible.

I can only present 10 years of professional experience, but I think
this statement is too extreme. Modular thinking is still possible with
GOTO; it all depends on the mindset of the programmer and the way he
uses GOTO-commands. I also evolved from GOTO towards GOSUB (already
the seeds for the later OO-approach), which allowed to make software
programs much more complex, and still be able to maintain that
complexity.

And if you take into account the academic criteria to measure software
quality[*], I think the benefits of OO are even clearer. On the other
hand, I've always had the feeling that object oriented programming has
never been able to fully realize what it had promised (IMHO the same
for XML, javascript, XSL, ...). Procedurial code has its benefits too,
and I think that this will not change.

The word "modular" was not part of his typewritten accusation, but I am
sure he mant that. I did not understand modular programming then, and even
now I do not use all it's benefits, I suppose.

In my opinion, there is no such thing as fully modular programming.
The core flow of any program is still procedurial, no matter to which
extent object-oriented elements are present. IMHO every programming
language can be put on a scale between procedurial and OO; it's not
black or white, and, I think a lot depends of the programmer too.
[*] "MATURE": Maintainable, Adaptable, Transparent, User-friendly,
Reliable, Efficient.

--
Bart

[Thomas 'PointedEars' Lahn]

Tom de Neef wrote:

"Tom de Neef" <td*****@qolor.nlwrote
<snip>

>var state = 1
while (state) { state = codeparts[state] }

should be
while (state) { state = codeparts[state]() }

TypeError: 9 is not a function.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Tom de Neef]

"Thomas 'PointedEars' Lahn" <Po*********@web.dewrote:

>>var state = 1
while (state) { state = codeparts[state] }

should be
while (state) { state = codeparts[state]() }

TypeError: 9 is not a function.

This seerms to work as intended:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD><TITLE>ArrayTest</TITLE>
<script type="text/javascript">
var codeparts = [];
var arg = 1;
codeparts[1] = function() {return (arg>3)?0:arg+1}
codeparts[2] = function() {return 1+Math.floor(3*Math.random())}
codeparts[3] = function() {return 3-Math.floor(4*Math.random())}

function cycle()
{
var state = 1;
while (state) { state = codeparts[state](); alert(state) }
}
</script>
</head>
<body onload=cycle()</body>
</html>

Tom

[Thomas 'PointedEars' Lahn]

Tom de Neef wrote:

"Thomas 'PointedEars' Lahn" <Po*********@web.dewrote:

>>>var state = 1
while (state) { state = codeparts[state] }
should be
while (state) { state = codeparts[state]() }

TypeError: 9 is not a function.

This seerms to work as intended: [...]

It is not Valid markup, however I have misinterpreted your reusing `state'.

I think it is evil[tm], although it works.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Johannes Baagoe]

Evertjan. :

I am programming for 40 years now and remember it came as a blow to me
when Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
in Byte [1968] declared "goto" in Basic the worst word in programming,
because it made thinking modular impossible.

Hardly in BASIC, since it is unlikely that Dijkstra even knew about
Kemeny's and Kurtz's experiments in 1968. FORTRAN and COBOL are more to
the point.

And certainly not in BYTE, which started in 1975. Actually, Dijkstra's
article was published in the March 1968 Communications of the ACM.

--
Johannes

[Evertjan.]

Johannes Baagoe wrote on 09 jul 2008 in comp.lang.javascript:

Evertjan. :

>I am programming for 40 years now and remember it came as a blow to me
when Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
in Byte [1968] declared "goto" in Basic the worst word in programming,
because it made thinking modular impossible.

Hardly in BASIC, since it is unlikely that Dijkstra even knew about
Kemeny's and Kurtz's experiments in 1968. FORTRAN and COBOL are more to
the point.

And certainly not in BYTE, which started in 1975. Actually, Dijkstra's
article was published in the March 1968 Communications of the ACM.

You should be right, memory serves me well, but was expensive at that time.

Could it have been Scientific American,
I remember expensive glossyness reading the 1968? article?

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

[John W Kennedy]

Johannes Baagoe wrote:

Evertjan. :

>I am programming for 40 years now and remember it came as a blow to me
when Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
in Byte [1968] declared "goto" in Basic the worst word in programming,
because it made thinking modular impossible.

Hardly in BASIC, since it is unlikely that Dijkstra even knew about
Kemeny's and Kurtz's experiments in 1968. FORTRAN and COBOL are more to
the point.

And certainly not in BYTE, which started in 1975. Actually, Dijkstra's
article was published in the March 1968 Communications of the ACM.

And I was consciously avoiding GOTO in PL/I even before that. As soon as
ALGOL introduced structured IF statements, the advantage was fairly obvious.

I note, however, that the case under discussion is machine-generated
code, and in this context, it should be noted that Ada includes GOTO
with the specific justification that code generators might take
advantage of it. (After all, machine code on every architecture I know
of still uses Branch/Jump instructions.)
--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson