Forum: Ruby Re: How to "go to" in a RUBY script . . .

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3be45f6ce2674d66238e593dfa2edd15?d=identicon&s=25 DEBAUN, STEVE [AG-Contractor/2400] (Guest)
on 2006-05-18 18:15
(Received via mailing list)
To everyone else:
I'll distract him, while y'all get a rope.

;)

sd
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-18 22:46
(Received via mailing list)
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
<steve.debaun@seminis.com>
wrote:
> All e-mails and attachments sent and received are subject to monitoring,
> reading and archival by Seminis. The recipient of this e-mail is solely
> responsible for checking for the presence of "Viruses" or other "Malware".
> Seminis accepts no liability for any damage caused by any such code
> transmitted by or accompanying this e-mail or any attachment.
>
>

Should you accidentally encounter this e-mail, any e-mail that refers to
it,
or a reference to the fact that this e-mail may exist you are hereby
instructed to immediately demagnetize your hard drive, and burn any
removable media within 10 feet. All actions must be documented with
unedited
& timestamped non-digital video which you shall immediately delivery to
our
lawyers via bonded bike messenger at your own cost. By receiving this
e-mail
either intententionally or accidentally you hereby agree to not hold
Seminis
liable for anything, ever. Any data potentially lost due to the
demagnetization of hard drives, or burning of removable media, is the
sole
responsibility of you, your cat, your child's cat and any other sueable
parties other than Seminis.

The fact that we've been pussy-wipped by our lawyers and enforce the
resulting stupidity upon our employess shall in no way reflect poorly on
Seminis, it's CEO, CTO, President, VicePresident, their wives, and most
definitely not it's lawyers, their cats, their cousin's cats. Any bad
impression of our company derived from reading this agreement is a
direct
result of the nearest deportable contractor with no direct ties to
Seminis
who happens to be in our office at the moment.

Any mention of this agrrement will be denied in court unless we can use
it
to sue you.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-18 22:49
(Received via mailing list)
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
<steve.debaun@seminis.com> 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
E17ac15581d924c99fc803e86d8d70fb?d=identicon&s=25 Anatoly Karp (Guest)
on 2006-05-18 22:56
(Received via mailing list)
On 5/18/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:
>
> 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.

Indeed:

http://pplab.snu.ac.kr/courses/adv_pl05/papers/p26...

-A
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-18 23:49
(Received via mailing list)
On May 18, 2006, at 1:48 PM, Leslie Viljoen wrote:

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

This is what the return keyword is for.

> In Ruby I sometimes do similar things with Exceptions, since an
> Exception a rather glorified goto-with-parameters.

Yuck.  Just use return.

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

Abusing exceptions the way you describe sounds just as horrible.

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-19 10:51
(Received via mailing list)
On 5/18/06, Eric Hodel <drbrain@segment7.net> wrote:
> > 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.
>
> This is what the return keyword is for.

You are right, return works well there.

> > 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.
>
> Abusing exceptions the way you describe sounds just as horrible.

The code is long but I'll strip it down and let you have a look. Maybe
you can suggest a better way then.

Les
F4ae9e7822cb761275aff25a0341f443?d=identicon&s=25 Phil Jackson (Guest)
on 2006-05-19 14:23
(Received via mailing list)
Hi,

On Fri, May 19, 2006 at 05:48:40 +0900, Leslie Viljoen wrote:
> On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400] <steve.debaun@seminis.com>
> 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

[ snip ]

This is why named loops in Perl was handy.

Cheers,
Phil
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 Florian GroÃ? (Guest)
on 2006-05-19 15:59
(Received via mailing list)
Leslie Viljoen wrote:

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

The one cool thing about C#'s goto that can't be easily done in Ruby is
goto case 5 in switch-case IMHO.

> In Ruby I sometimes do similar things with Exceptions, since an
> Exception a rather glorified goto-with-parameters.

Please don't abuse exceptions for this. It's exactly what catch() and
throw() are there for.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-19 17:03
(Received via mailing list)
2006/5/18, Leslie Viljoen <leslieviljoen@gmail.com>:
>
> if (... & flag_variable)
>
> in every loop condition., even though I had to put silly nop
> statements at the end of the functions.

When refactoring properly this is often easily solved with a "return"
statement.

> In Ruby I sometimes do similar things with Exceptions, since an
> Exception a rather glorified goto-with-parameters.

The best idiom for this in Ruby is catch throw (as opposed to raise and
rescue).

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

I would have to look at the link you provided - I cannot remember when
I last used a GOTO (must have been in my ancient ZX Spectrum times)
and I definitively never missed it after that.  All modern languages
have decent program flow control elements that make GOTO really
superfluous IMHO.

Kind regards

robert


PS: Steve, you got the rope yet?
Ad4caa46eebe9347305177fc33468563?d=identicon&s=25 Mike Nelson (Guest)
on 2006-05-19 18:15
Leslie Viljoen wrote:
> 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.
>

I couldn't agree more.

I'd also add that not using goto structures doesn't help you from
writing spaghetti code that much. Even using well-structured functions
can become a complex mess.

The whole goto issue is sort of similar to the TDD problem in my mind.
The difference is there is a possible fix for the TDD problem in BDD.
It's not a code problem but a problem of how the we perceive the code.
We used Test Driven Design to help our development processes but we
missed the point of TDD so much that we have to come up with Behavior
Driven Design, which is the really same thing but is more explicit in
the terminology to help us get the point of what TDD was in the first
place.

Back then, with the goto problem, we found that we were writing a bunch
of messy and goto was the central construct that abused. So we decided
that it was better to use the function construct in most cases in order
to help this problem. But in our retreat of messy code we seemed to
place our fear of it wholly into the goto construct itself. My guess is
that this allows us to say that we can ignore a lot of that fear now as
long as we don't use goto statements, which is sort of ignoring the
central problem of messy code.

Because of all this, it now seems that we are left with a weird
superstition around the goto construct. Which is pretty odd to me
because it's still a fundamental construct used on the CPU, so why not
use it in the code when it helps?
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-19 18:26
(Received via mailing list)
2006/5/19, Mike Nelson <miken700@yahoo.com>:

> Back then, with the goto problem, we found that we were writing a bunch
> of messy and goto was the central construct that abused. So we decided
> that it was better to use the function construct in most cases in order
> to help this problem. But in our retreat of messy code we seemed to
> place our fear of it wholly into the goto construct itself. My guess is
> that this allows us to say that we can ignore a lot of that fear now as
> long as we don't use goto statements, which is sort of ignoring the
> central problem of messy code.

I see this differently: experience has shown that GOTO in most cases
leads to bad code. It's also formally proven that it's not needed,
i.e. the same semantic can be achieved without it (but using if -
else, loop constructs etc.).  Since these other constructs of course
*can* also be abused (like every feature a programming language
offers) but usually give better code remove the GOTO.  And that's what
they did.

> Because of all this, it now seems that we are left with a weird
> superstition around the goto construct. Which is pretty odd to me
> because it's still a fundamental construct used on the CPU, so why not
> use it in the code when it helps?

Because it leads to bad code too often to outweight the occasional
benefits.

Cheers

robert
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-19 18:35
(Received via mailing list)
On May 19, 2006, at 11:24 AM, Robert Klemme wrote:

> Because it leads to bad code too often to outweight the occasional
> benefits.

Just because many people would abuse it does not mean that a
programmer who could use it cleanly and elegantly should be unable to.

- Jake McArthur
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-19 18:39
(Received via mailing list)
2006/5/19, Jake McArthur <jake.mcarthur@gmail.com>:
> On May 19, 2006, at 11:24 AM, Robert Klemme wrote:
>
> > Because it leads to bad code too often to outweight the occasional
> > benefits.
>
> Just because many people would abuse it does not mean that a
> programmer who could use it cleanly and elegantly should be unable to.

Sometimes less is more.

robert
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-19 19:07
(Received via mailing list)
On May 19, 2006, at 11:37 AM, Robert Klemme wrote:

> 2006/5/19, Jake McArthur <jake.mcarthur@gmail.com>:
>> Just because many people would abuse it does not mean that a
>> programmer who could use it cleanly and elegantly should be unable
>> to.
>
> Sometimes less is more.

But that's kind of my point. To an experienced programmer, being able
to use a goto can amount to being able to cut a ton of complexity out
of his code.

Issues like this are not black and white. It's kind of close-minded
to simply rule a tool out because that tool is difficult to use
correctly. Should people stop playing musical instruments, using
manual cameras, and driving cars? Well, that last one is arguable,
but my point stands.

- Jake McArthur
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-19 19:20
(Received via mailing list)
On Friday 19 May 2006 11:05 am, Jake McArthur wrote:

> But that's kind of my point. To an experienced programmer, being able
> to use a goto can amount to being able to cut a ton of complexity out
> of his code.

The one time in 4 years of Ruby that I have needed something goto-like,
throw/catch worked perfectly to solve the need.

Goto is an ugly construct that is rarely missed and never needed.


Kirk Haines
0ca6e5c33d7e7ff901d75ff0b13d9e1c?d=identicon&s=25 Sam Roberts (Guest)
on 2006-05-19 19:41
(Received via mailing list)
Quoting shortcutter@googlemail.com, on Sat, May 20, 2006 at 01:24:44AM
+0900:
> I see this differently: experience has shown that GOTO in most cases
> leads to bad code. It's also formally proven that it's not needed,
> i.e. the same semantic can be achieved without it (but using if -
> else, loop constructs etc.).  Since these other constructs of course

It is also formally proven that just a conditional and a goto is
sufficient to implement loops, which I got to "appreciate" when writing
robot controllers in a variant of basic once. Bad memories.

I think goto would be difficult to implement in a dynamic language like
ruby, because of issues of scope and context, its not just where you are
in the code thats important, but how you got there.

If you want a goto, ruby has a number of options that might fit the
need: cast statements, call/cc is like goto on steroids with a laser
blaster, return/break/next, raising an exception, and catch and throw
all jump the point of execution from one place to another.

I use goto frequently in C for structured handling of error conditions.
This use is unnecessary in ruby, or even C++, because they have
exceptions and automatic stack cleanup builtin to the language.

Cheers,
Sam
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-20 16:34
(Received via mailing list)
2006/5/19, Jake McArthur <jake.mcarthur@gmail.com>:
> to use a goto can amount to being able to cut a ton of complexity out
> of his code.
>
> Issues like this are not black and white. It's kind of close-minded
> to simply rule a tool out because that tool is difficult to use
> correctly. Should people stop playing musical instruments, using
> manual cameras, and driving cars? Well, that last one is arguable,
> but my point stands.

This was not my point: my point was, that the harm done with GOTO far
outweights the benefits and that more is gained by removing it from
languages than would be won be keeping it.  Of course you can find for
every tool an application case where it's ideal but that doesn't
proove anything.

robert
D1be1ff625c6286f4734cb6019490301?d=identicon&s=25 Vlad GALU (Guest)
on 2006-05-20 23:19
(Received via mailing list)
On 5/20/06, Robert Klemme <shortcutter@googlemail.com> wrote:
> > But that's kind of my point. To an experienced programmer, being able
> outweights the benefits and that more is gained by removing it from
> languages than would be won be keeping it.  Of course you can find for
> every tool an application case where it's ideal but that doesn't
> proove anything.

   Nowadays I could only find goto useful in controlling the error
path flow inside the kernel. Not Ruby's Kernel, but the OS kernel,
where 'normal' stack unwinding is usually too expensive. But nobody
uses Ruby for kernel programming, right ? :)
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-05-23 02:06
(Received via mailing list)
On 5/19/06, Phil Jackson <phil@shellarchive.co.uk> wrote:
>
> This is why named loops in Perl was handy.
>
Precisely what I was thinking.  The spaghetti code problem is largely
attributed to non-local use of flow control.  I do miss being able to
easily jump out of a nested loop, and with the labeling construct Phil
refers to I think it's pretty readable.

Of course conditionals, loops, function returns, et cetra are all just
fancy "goto"s in disguise.
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-23 03:22
(Received via mailing list)
On Monday 22 May 2006 6:04 pm, Louis J Scoras wrote:

> Precisely what I was thinking.  The spaghetti code problem is largely
> attributed to non-local use of flow control.  I do miss being able to
> easily jump out of a nested loop, and with the labeling construct Phil
> refers to I think it's pretty readable.

The Ruby way involes a little more typing than the Perl way, but it
seems
pretty easy to me:

-----
tc = 0

catch(:bailout) do
  while true
    tc += 1
    throw :bailout if rand(50000) == 1
  end
end

puts "Bailed out after #{count} iterations."
-----

I like this.  It's very flexible.  It lets me pass data out of the dark
inner
place that the execution path is escaping from, and it will let me nest
catch() statements if I want.

Another silly, slightly more complex example:

-----
def do_iterations
  iterations = Hash.new {|h,k| h[k] = 0}
  tc = 0
  while true
    tc += 1
    iterations[0] += 1
    while tc % 100 != 0
      tc += 1
      iterations[1] += 1
      while tc % 10 != 0
        iterations[2] += 1
        tc += 1
        throw(:bailout,[tc,iterations]) if rand(50000) == 1
      end
    end
  end
end

count,iterations = catch(:bailout) {do_iterations}
puts "Bailed out after #{count} iterations.\nIterations:
#{iterations.inspect}"
-----

catch/throw don't need to be used often, but when they are needed, they
work
great for all of the same thing that labeled loops in Perl work for, and
then
some.


Kirk Haines
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-23 15:57
(Received via mailing list)
On 5/23/06, Kirk Haines <khaines@enigo.com> 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
B58c6eef325656d513d26e2c3ae6bfd9?d=identicon&s=25 Peter Bailey (peterbailey)
on 2006-05-23 16:08
Leslie Viljoen wrote:
> On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
> <steve.debaun@seminis.com> 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
F2d901ea9430646c6dd35a629bb3f119?d=identicon&s=25 Simen (Guest)
on 2006-05-23 16:43
Peter Bailey wrote:
> Leslie Viljoen wrote:
>> On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
>> <steve.debaun@seminis.com> 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.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-23 17:05
(Received via mailing list)
On 5/23/06, Simen <toalett@gmail.com> 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?
F2d901ea9430646c6dd35a629bb3f119?d=identicon&s=25 Simen (Guest)
on 2006-05-23 17:20
Leslie Viljoen wrote:
> On 5/23/06, Simen <toalett@gmail.com> 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.
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-23 18:41
Leslie Viljoen 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 Weirich
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-23 20:07
(Received via mailing list)
On 5/23/06, Simen <toalett@gmail.com> 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
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-23 23:39
(Received via mailing list)
On 5/23/06, Ryan Leavengood <leavengood@gmail.com> 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
This topic is locked and can not be replied to.