Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!mintaka!spdcc!iecc!compilers-sender From: ea08+@andrew.cmu.edu (Eric A. Anderson) Newsgroups: comp.compilers Subject: Re: the Evil Effects of Inlining Keywords: recursion, design Message-ID: Date: 6 May 91 06:07:56 GMT References: <1991May1.035622.25021@daffy.cs.wisc.edu> <1991May2.180508.17100@rice.edu> , <1991May5.025004.11897@daffy.cs.wisc.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: "Eric A. Anderson" Organization: Compilers Central Lines: 53 Approved: compilers@iecc.cambridge.ma.us In-Reply-To: <1991May5.025004.11897@daffy.cs.wisc.edu> 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] -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.