Timeline for Are functional languages better at recursion?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 28, 2014 at 13:18 | answer | added | Karl Bielefeldt | timeline score: 0 | |
| May 18, 2012 at 16:57 | vote | accept | marco-fiset | ||
| May 18, 2012 at 16:49 | answer | added | Bruce Ediger | timeline score: 1 | |
| May 18, 2012 at 16:24 | comment | added | marco-fiset | @PeterTaylor : I haven't thought about it, but yes, it is more a compiler issue than a language one. | |
| May 18, 2012 at 15:59 | comment | added | Peter Taylor | When you say "language" are you including compilers in the scope of discussion? ISTM that it's the popular implementations of functional languages which are better at recursion rather than the languages per se. | |
| May 18, 2012 at 15:42 | vote | accept | marco-fiset | ||
| May 18, 2012 at 15:43 | |||||
| May 18, 2012 at 15:09 | answer | added | tdammers | timeline score: 40 | |
| May 18, 2012 at 14:15 | history | tweeted | twitter.com/#!/StackProgrammer/status/203488914235858944 | ||
| May 18, 2012 at 13:45 | comment | added | marco-fiset | @chrisaycock : It could, but I wanted to show the code as it is in the book. | |
| May 18, 2012 at 13:43 | comment | added | chrisaycock | Your imperative code could be collapsed to x == 0 ? 1 : x * factorial(x - 1). | |
| S May 18, 2012 at 13:39 | history | suggested | dagnelies | CC BY-SA 3.0 | just removing some unnecessary brackets |
| May 18, 2012 at 13:35 | review | Suggested edits | |||
| S May 18, 2012 at 13:39 | |||||
| May 18, 2012 at 13:19 | history | edited | marco-fiset | CC BY-SA 3.0 | deleted 5 characters in body |
| May 18, 2012 at 13:18 | comment | added | marco-fiset | @delnan : Thanks for the clarification ! I'll edit my edit ;) | |
| May 18, 2012 at 13:16 | comment | added | user7043 | Your edit indicates you didn't catch my drift. The definition you gave is a perfect example of recursion which is bad even in functional languages. My alternative is also recursive (though it's in a library function) and very efficient, only how it recurses makes a difference. Haskell is also an odd case in that laziness breaks the usual rules (case in point: functions can overflow the stack while being tail recursive, and be very efficient without being tail recursive). | |
| May 18, 2012 at 13:13 | answer | added | Telastyn | timeline score: 5 | |
| May 18, 2012 at 13:09 | history | edited | marco-fiset | CC BY-SA 3.0 | added 235 characters in body |
| May 18, 2012 at 13:06 | comment | added | Mark Booth | @JoachimSauer - With a little embellishment, your comment would make a worthwhile answer. | |
| May 18, 2012 at 13:05 | answer | added | chrisaycock | timeline score: 18 | |
| May 18, 2012 at 12:59 | answer | added | Mert Akcakaya | timeline score: 1 | |
| May 18, 2012 at 12:55 | answer | added | K.Steff | timeline score: 0 | |
| May 18, 2012 at 12:54 | answer | added | Steven Evers | timeline score: 1 | |
| May 18, 2012 at 12:53 | comment | added | user7043 | Actually, the Haskell definition you gave is pretty bad. factorial n = product [1..n] is more succinct, more efficient, and does not overflow the stack for large n (and if you need memoization, entirely different options are requires). product is defined in terms of some fold, which is defined recursively, but with extreme care. Recursion is an acceptable solution most of the time, but it's still easy to do it wrong/suboptimal. | |
| May 18, 2012 at 12:46 | comment | added | Joachim Sauer | Case in point: many functional languages make heavy use of tail call optimization, while very few procedural languages do that. This means that tail call recursion is much cheaper in those functional languages. | |
| May 18, 2012 at 12:46 | history | edited | yannis | CC BY-SA 3.0 | a space before the punctuation mark may push it to a new line, and it looks ugly when that happens. |
| May 18, 2012 at 12:41 | history | asked | marco-fiset | CC BY-SA 3.0 |