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
···
On 5/23/06, Kirk Haines <khaines@enigo.com> wrote:
On Monday 22 May 2006 6:04 pm, Louis J Scoras wrote:
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.
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.
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).
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
···
On 5/23/06, Ryan Leavengood <leavengood@gmail.com> 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
>
> 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:
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
···
On May 19, 2006, at 11:37 AM, Robert Klemme wrote:
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
···
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.
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.
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.
>
> >> 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.
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.
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 ?
···
On 5/20/06, Robert Klemme <shortcutter@googlemail.com> wrote:
2006/5/19, Jake McArthur <jake.mcarthur@gmail.com>:
> On May 19, 2006, at 11:37 AM, Robert Klemme wrote:
> > 2006/5/19, Jake McArthur <jake.mcarthur@gmail.com>:
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.