C
Christopher Benson-Manica
Christian Bau said:
Especially by one Joona Palaste, whom I mention solely for the purpose
of wondering where he's been lately.
Especially by one Joona Palaste, whom I mention solely for the purpose
of wondering where he's been lately.
R
Randy Howard
Christopher Benson-Manica wrote
Heathfield Syndrome
(patent pending)
(in article said:
Heathfield Syndrome
(patent pending)
L
Lawrence Kirby
Although I'm not sure that paper would mean much to somebody just
starting to learn programming.
Programming paradigms like structured programming, functional programming,
object oriented programming and so on are really all about approaches to
encapsulation. Even a program of 100 lines can can contain a lot of
complexity, as program size increases so does complexity. But the human
mind can only deal with a fairly small amount of complexity at a time. So
we try to manage complex software by arranging it into units that can be
described and thought about simply, so we don't have to consider the
complexity of the whole program all at once. Functions in C are a very
obvious construct for doing this. But there is also complexity within the
code of a function body and it can also be managed. C is a block
structured language and statements can be grouped together in {}'s and
treated like a single entity. This is an, albeit simple, form of
encapsulation. A loop like:
for (.....) {
loop body
}
can also be considered as a single entity whith a purpose that can
hopefully be described and thought about simply. Perhaps less obviously
that is also true for a conditional statement like
if (test) {
code
} else {
code
}
if well designed it can be considered as a single entity with a simple
purpose. The thing about all of these constructs is that they are well
delineated, they have a clear start and end and hopefully clear and simple
entry and exit conditions. When that's the case they are easy to think
about and fit together in the larger whole.
Problems with gotos are:
1. the lack of control on them. You can jump to anywhere in the function
whch tends to destroy the sort of structure I talk about above that
makes code easier to think about.
2. Being so general, a goto tells you very little about the purpose it is
being put to. For example a for loop tells you that you have a loop, the
control expressions give well defined information about the loop in a well
defined place that is easy to find, and it is easy to see where the code
for the loop starts and ends. Gotos give you very little of this.
It is possible to program in a "structured" way using gotos, and this was
a reasonable thing to do in languages that didn't give you alternative
constructs. However it is up to you to make sure the structure of your
code stays clean, goto doesn't give you any help in that respect, and it
still lacks the clues that are helpful to somebody reading the code. So
when structured constructs are available, as they are in C, it is
preferable to use them.
Even so C still provides a goto statement. And there are occasions where
it is useful, but they are rare. Offhand I can think of 3 areas where
using goto can be reasonable: error handling, exiting from nested loops,
and finite state machines.
If you DO ever use a goto you can avoid much of the nastiness by following
the simple rule that a goto should jump forwards and never backwards in
the code. Although finite state machines that use goto are an exception to
this.
Lawrence
R
Richard Tobin
Lawrence Kirby said:
As is simulation of tail-recursion.
-- Richard
K
Keith Thompson
Hmm. Do you have an example of using a goto to simulate
tail-recursion that wouldn't be better implemented as an explicit
loop?
R
Richard Tobin
I'm not sure I have one where using goto is better as an implementation
of the function per se, but it's better as an expression of the fact
that I am writing it as a tail-recursive function and have to get
around the limitation that compilers won't necessarily compile
tail-recursive functions to something that works.
You might say that it's better to stick to idioms that are directly
supported by C, but sometimes I prefer to impose my will on the laguage.
-- Richard
A
Anonymous 7843
The Ackerman function comes to mind.
http://mathworld.wolfram.com/AckermannFunction.html
Perhaps I am over-simplifying, but I think that any recursive
function that (a) is otherwise amenable to TRE and (b) calls
itself from multiple places, not just the "end" is not well
served by a loop. Frankly, I don't think it is well-served by a
goto either. It may simply be that there is a a very, very
small class of algorithms that C is not ideal for.
Related to this kind of multi-point recursion is:
http://mathworld.wolfram.com/TAKFunction.html
A long time ago, a scheme programmer and I had a disagreement
over a benchmark component based on TAK. Scheme liberally
applies TRE and handily beat gcc. I tuned the C code not by
TRE, but by hoisting the if's up one level of recursion.
This kept the code readable and recognizable, and didn't involve
goto's or extra loops.
Lest I seem pseudo-intellectual, let me disclaim that I don't
really understand the above functions or their applicability;
I just coded them and optimized them in C, which is something
I know I can handle.
M
Michael Wojcik
Based on Greg Chaitin's work, I'd guess that it's actually a very,
very large class of algorithms. Fortunately, nearly all are useless.
--
Michael Wojcik (e-mail address removed)
Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random. -- G J Chaitin
A
Anonymous 7843
I'm hoping he'll stumble upon a P=NP proof somewhere along
the way. It sure isn't anywhere else.