Re: the Evil Effects of Inlining

carter@cs.wisc.edu (Gregory Carter) writes:
> Everyone secretly knows anyway that goto's are better, nicer and more
> efficient programming context for designing loops of all kinds anyway. (Of
> course, I will contend that too much of a good thing is bad..or is it?)


The last time I used gotos was when a program needed to get turned in in
about 30 seconds, and I had forgotten one of my loop exiting conditions.
Then I wrote an if statement which just jumped me out of the loop without
having to add another boolean termination value.


That I see as the primary value of gotos, is the elmination of the
if (Multi level exit test)
    then terminate := true;
to get you out of 2 or three depths of loops.


> [To each his own, I suppose. I find that the most natural way to express a
> nontrivial routine is more often than not recursive. Converting recursive
> programs to non-recursive mechanically is not hard. It must be, since no
> computer I know up supports recursion in hardware -- they all implement
> recursion with arrays of activation records. Also, the arguments about
> gotoless programming usually refer to programs written by humans, not
> programs written by machine, though on a deeply pipelined RISC, any sort of
> branch tends to be expensive. -John]


I believe that in SML of New Jersey, recursion is supported not by using
arrays of activation records, but more by jumping around from place to
place via continuation passing (please correct me if I am wrong, I have
just started to learn functional programming, and some of the concepts
seem pretty nebulus/like magic to me). Functional language compilers tend
to spend a lot of time making it so that recursion is efficient because
that is the only way to do things. As a result, in the article on the
continuation passing style, they note that properly tail recursive
functions will optimize to a loop type method.


> On another note, some of you have mentioned that recursion would die this
> way, and since I have never been a big fan of recursion, and avoid it where
> possible, and very seldom do we think recursively (BE HONEST NOW) I thought
> this option would be common enough to actually be feasable. (Yes,
> recursion has its place, yes its useful, but it's a specialty item!)


I'd say that I often think recusively, how do you do a quicksort?
partition, then recursively sort each side. How do you do a binary
search. Check the middle then recursively search the side it's on. I
think that it is merely a matter of personal preference if you like the
recursive .vs. non-recursive style of programming, as you can convert one
to the other.


                    -Eric
[Good point about continuation passing which involves a heap rather than an
array of activation records. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.