Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!mit-eddie!nessus From: nessus@mit-eddie.UUCP (Doug Alan) Newsgroups: net.lang Subject: Re: Re: Gotos; tail-recursion - (nf) Message-ID: <2122@mit-eddie.UUCP> Date: Wed, 13-Jun-84 23:44:52 EDT Article-I.D.: mit-eddi.2122 Posted: Wed Jun 13 23:44:52 1984 Date-Received: Thu, 14-Jun-84 07:09:16 EDT References: <1986@mit-eddi.UUCP> <5400008@ea.UUCP> Organization: MIT, Cambridge, MA Lines: 59 > From: mwm@ea.UUCP > I'm completely confused. As I understand it, tail recursion is an > implementation technique that allows languages to generate faster > code. People may write code to take advantage of this, but it still > doesn't change the semantics of the language. Hence comparing it > to gotos, loops and etc. doesn't seem to make sense. Well, it depends on what you mean by "the semantics of the language". If you mean by that, some pure mathematical notion, then tail-recursion doesn't change the semantics. But in that case you don't need loops and gotos: you can do gotos with procedure calls and loops (even infinite loops) with recursion, because you don't care about efficiency and you don't care about stack overflows -- when your stack is infinitely big, you can't have an overflow. But in real implementations, you can't program like that because you have to worry about efficiency and stack overflows (well you don't HAVE to worry about efficiency, but you do HAVE to worry about stack overflows). Tail-recursion allows you to pretend that your implementation is a pure mathematical model, and still get efficiency and no stack overflows. You can do infinite loops with recursion and gotos with procedure calls, and have it all work fine in the real world. In this sense, tail-recursion does change the semantics of the language. > You also have a logical fallacy. You seem to think that being > able to do bad things with a language feature is a good reason > to consider taking it out of a language. You have a logical fallacy. The alleged fallacy you're talking about isn't in the domain of logic -- it's a matter of taste and practicality. I'd like to see, though, a logical proof that I'm wrong. Then I can show you some proofs for the existence of God. Aquinas had a couple good ones. Besides, I never said that just because you can do bad things with a language feature, you should remove it from the language. I just think it's a factor to consider just like everything else. When you design a language, you don't want to put in everything in the world. If you do, you get PL/1. You want to put in the minimum number of features that integrate well together and let you do everything you want to easily. You should consider the negative effects of a feature as well as its benefits. One of your design considerations may very well be that your programming language is going to be used to do large software projects by programming teams, and in that case the language should do it best to encourage good programming practices without being limitting. There are always trade-offs, and they should be considered. And like I said before, I think that tail-recursion is a good feature. In fact, I think it is a great feature. I think its advantages far outweigh its disadvantages. I was just pointing out its major disadvantage and asking if anyone thinks this disadvantage is important. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?