Leslie V. wrote:
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
[email protected] wrote:
To everyone else:
I’ll distract him, while y’all get a rope.
hehe. I recently noticed that C# still has a goto, although it seems
that you can’t have a label right at the end of a function since the
label must precede an actual statement. I found it to be useful in a
case where I was deep in nested loops, searching for a string and had
just found it, so I needed to jump out. It seemed so much clearer and
simpler to use the goto rather than have
if (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
L
Wow. I guess, way back when, my referring to GOTO really sparked a
conversation here. It’s not that I still write DOS scripts. I have used
it recently, though, in Windows cmd.exe scripts, which, no, are not DOS.
This is juicy stuff. Thanks, everybody. Catch and throw, exceptions, . .
., all good stuff.
-Peter
Peter B. wrote:
Leslie V. wrote:
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
[email protected] wrote:
To everyone else:
I’ll distract him, while y’all get a rope.
hehe. I recently noticed that C# still has a goto, although it seems
that you can’t have a label right at the end of a function since the
label must precede an actual statement. I found it to be useful in a
case where I was deep in nested loops, searching for a string and had
just found it, so I needed to jump out. It seemed so much clearer and
simpler to use the goto rather than have
if (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
L
Wow. I guess, way back when, my referring to GOTO really sparked a
conversation here. It’s not that I still write DOS scripts. I have used
it recently, though, in Windows cmd.exe scripts, which, no, are not DOS.
This is juicy stuff. Thanks, everybody. Catch and throw, exceptions, . .
., all good stuff.
-Peter
There’s also continuations. They’re not only for web frameworks, you
know. It’s fairly easy to write something goto-like with continuations.
I once did, for fun. You could do stuff like
label :loop
[code]
goto :loop
Easy to abuse, fun to write. Still, catch/throw should be sufficient
most of the time.
On 5/23/06, Simen [email protected] wrote:
There’s also continuations. They’re not only for web frameworks, you
know. It’s fairly easy to write something goto-like with continuations.
I once did, for fun. You could do stuff like
label :loop
[code]
goto :loop
As I understand it, continuations seem like blocks where all the local
(instance) variables are automatically “static” (to use C’s word). So
you can go back to execute that block again at any time from anywhere
and it’s previous state is intact. Is that right?
On 5/23/06, Kirk H. [email protected] wrote:
This is great! It’s exactly the way I was “abusing” exceptions, so I’m
going to change my code to use catch and throw instead.
Les
Leslie V. wrote:
On 5/23/06, Simen [email protected] wrote:
There’s also continuations. They’re not only for web frameworks, you
know. It’s fairly easy to write something goto-like with continuations.
I once did, for fun. You could do stuff like
label :loop
[code]
goto :loop
As I understand it, continuations seem like blocks where all the local
(instance) variables are automatically “static” (to use C’s word). So
you can go back to execute that block again at any time from anywhere
and it’s previous state is intact. Is that right?
Continuations represent “the rest of your program”, or the
continuation of a program from a point in code. So, when you do
callcc do |continuation|
continuation.call
end
puts “…”
All you’re gonna see is “…” because that’s the rest of the program.
It’s kinda like a superset of a closure: both the closure and the
instruction pointer in one. What’s happening in the code I posted is
that the label method stores the continuation in a hash in a constant
somewhere, and the goto method fetches the continuation and calls it.
Anyway, back to your regularly scheduled goto-bashing.
On 5/23/06, Simen [email protected] wrote:
most of the time.
This did sound fun, here is my quick and dirty implementation:
$labels = {}
def label(s)
callcc do |cont|
$labels[s] = cont
end
end
def goto(s)
cont = $labels[s]
cont.call if cont
end
def method1
puts “In method1, goto :start”
goto :start
end
if $0 == FILE
go = true
label :start
puts “Starting…”
if go
puts “Running loop…”
i = 0
label :loop
puts “i is #{i}”
i += 1
goto :loop if i < 5
go = false
method1
else
puts “Not running loop.”
end
end
END
I’m definitely using this in the next obfuscated Ruby contest. In
other words, this should not be used in real code.
Ryan
Leslie V. wrote:
As I understand it, continuations seem like blocks where all the local
(instance) variables are automatically “static” (to use C’s word). So
you can go back to execute that block again at any time from anywhere
and it’s previous state is intact. Is that right?
Almost. Neither the values of global variables nor local variables in
Ruby code are preserved. However, the values of local variable in any
C-implemented methods /are/ preserved (and I suspect this is an artifact
of implementation rather than a conscience design choice).
What a continuation actually preserves is the state of the “call stack”.
In other words, you can have A call B and create a continuation inside
of B. You can then return from B and from A, and then call the
continuation and you are back inside of B (as called from A) as if you
had never left. The state of the local variables are whatever they were
when you left them (i.e. they are not restored to the values they had
when the continuation was created).
Does that help?
– Jim W.
On 5/23/06, Ryan L. [email protected] wrote:
Easy to abuse, fun to write. Still, catch/throw should be sufficient
most of the time.
This did sound fun, here is my quick and dirty implementation:
I am so amazed by how versatile and expressive Ruby is. It’s almost as
if it was designed in a way that made a whole lot of things possible
even though the designer(s) didn’t think of them. Thanks Matz!
I don’t know if I’ll ever use continuations but it’s good to have the
tool in the shed.
Les