Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64979 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-07-09 12:49 +0200 |
| Last post | 2015-07-16 09:41 +1200 |
| Articles | 20 on this page of 292 — 25 participants |
Back to article view | Back to comp.lang.c
Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 12:49 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 12:03 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 14:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:25 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:36 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:51 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:02 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:48 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-09 09:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:08 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:16 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:18 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:24 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:31 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:42 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:39 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 22:50 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:26 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:28 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:09 +0200
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-09 09:25 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:41 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-10 11:52 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 18:44 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 18:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:34 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 11:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:56 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 13:30 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-11 10:51 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 16:07 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-12 00:20 -0700
Re: Recursion or loop, design questions gordonb.j93iw@burditt.org (Gordon Burditt) - 2015-07-11 21:26 -0500
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 10:08 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 19:19 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 19:11 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:28 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:41 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:22 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:45 +0200
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-09 18:05 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:06 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 09:36 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-15 10:49 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 13:05 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:28 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 12:41 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 21:37 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 13:05 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 15:07 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:42 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-24 15:38 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:39 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 22:35 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 07:09 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:43 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 09:48 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:23 +0200
Re: Recursion or loop, design questions Andrew Cooper <amc96@cam.ac.uk> - 2015-07-10 00:52 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 01:28 +0100
Re: Recursion or loop, design questions Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:20 +0300
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-12 11:39 +0100
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:28 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-13 08:17 +1200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 14:46 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:27 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:16 +0000
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 08:34 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 00:46 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 12:35 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 12:47 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 14:29 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 06:36 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:16 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:23 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:27 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:27 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 15:27 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:00 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:01 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:36 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:55 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 14:12 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:45 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:34 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:37 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:07 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:18 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 13:35 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-16 21:10 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 13:55 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-17 11:16 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 11:25 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-17 20:51 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:48 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 15:12 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 10:56 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 19:43 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 12:52 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 21:17 +0100
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 23:58 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:39 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 00:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 09:06 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 08:04 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 13:48 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-25 14:02 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 13:41 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 15:41 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-02 21:51 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-03 01:20 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-04 10:54 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:02 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:03 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:36 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:21 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 12:18 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:19 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:35 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 21:40 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:51 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 22:57 +0200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-05 08:45 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:19 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:22 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:28 -0700
Language (was: Re: Recursion or loop, design questions) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:35 +0200
Re: Language (was: Re: Recursion or loop, design questions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 14:45 -0700
Re: Language "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:55 +0200
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 16:44 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 17:18 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-05 01:32 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 09:51 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 12:55 +0100
Re: Language Gareth Owen <gwowen@gmail.com> - 2015-08-05 19:12 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-06 17:09 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-06 15:10 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-07 09:48 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-07 13:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-06 10:54 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-06 13:32 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 11:06 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 11:52 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-06 21:19 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 17:59 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 15:54 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 12:56 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-07 23:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-08 09:27 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:09 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:34 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 13:00 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 14:22 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:12 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 17:31 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:34 +0000
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 08:38 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-09 09:31 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 01:52 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 04:40 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 20:19 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:59 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:53 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:43 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 20:05 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:53 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-03 01:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 10:04 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:34 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:52 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 10:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 11:00 +0100
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-18 05:25 -0500
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 17:38 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:05 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:31 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 14:28 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:01 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:39 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:44 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:55 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 10:58 +1200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 16:26 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 17:23 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 18:04 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:03 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 13:30 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 08:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 20:59 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 21:19 +0200
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 07:23 -0500
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:11 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:55 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:22 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 17:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:25 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 03:15 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 10:36 +0100
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 12:45 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:05 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:09 -0400
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:40 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 22:31 +0100
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:05 +0000
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-09 21:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-09 16:14 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 05:39 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 01:40 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-08-10 21:03 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:16 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:16 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:36 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:45 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 02:47 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 22:23 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 05:01 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 09:55 +1200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 23:13 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 10:19 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:21 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 00:25 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 11:45 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-20 02:34 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 10:52 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 05:31 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:16 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 17:24 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:36 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 21:07 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 02:51 -0700
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-19 10:12 -0500
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 16:54 -0500
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 12:34 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-27 11:08 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 14:59 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:40 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:05 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-19 12:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 12:57 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 21:16 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:50 -0700
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:13 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:04 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 12:40 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 16:27 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:58 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:24 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-18 10:29 -0400
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-18 17:32 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:28 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 22:58 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:13 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:49 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:12 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:21 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:23 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:46 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:31 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-21 04:08 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:43 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:54 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:06 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-12 23:45 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-12 17:48 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-13 01:27 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 19:39 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 14:51 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 23:51 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:04 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:36 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:37 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-21 20:55 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:39 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:41 +1200
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 06:36 -0700 |
| Message-ID | <kfnbnfi24vx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65084 |
Andrew Cooper <amc96@cam.ac.uk> writes: > On 09/07/2015 11:49, Morten W. Petersen wrote: >> However, choosing between recursion and looping is less >> obvious, to me at least. > > Never ever ever recurse. It will come back and bite you. I would like to offer a counterpoint. I use recursion routinely. IME it is an extremely valuable and reliable tool, provided (like all tools) it is used properly. In most cases the problem with recursion is that someone who is using it doesn't really understand different kinds of recursion. Most programmers get only a shallow introduction to recursion, kind of like learning about sorting by looking only at bubble sort. Bubble sort has the advantage that it is easy to explain, but it certainly isn't all one should know if one wants to understand sorting. The problem with how recursion is taught is that most often the teaching stops at the bubble sort level. > In this example, there are specific XML files which will overflow > any arbitrary stack size you choose. That depends on how the recursion is accomplished. If the recursion is done naively, that is often true. If the recursion is done using the better-behaved recursion constructs, it will never be true. The key point is that recursive calls don't necessarily consume any stack space, but lots of people don't know that or distinguish between the different kinds. > One could argue that it might make more readable code. Some > programming languages actively encourage it as an example of > elegance[1]. IME recursion often produces code that is shorter, easier to comprehend, and more obviously correct than a corresponding non-recursive version. (I will take up the example below.) Understanding and appreciating that isn't trivial, and I think that is the mistake that many recursion advocates make: it isn't reasonable to expect a bubble-sort-level understanding of recursion to handle writing recursive code effectively. If this sounds harsh, well maybe it is, but it reflects my own experience - I had been programming more than 30 years (and having seen and used recursion for almost all of those) before I got beyond the CS 101 level of understanding recursion. > (I am a systems programmer and biased in this area. An 8K is > genuinely enough for anyone, and 4K is sufficient for the > overwhelming majority of cases.) I assume you mean an 8K (or 4K) stack there. Obviously a different stack size might make a difference in how one chooses to approach a problem, but most of what I have said above applies to a 4K stack environment just as much as a 4000K stack environment. > Of course, this like any rule is open to be broken. In my case, > anyone who is unable to justify why their specific use of recusion > is safe in all circumstances is not going to have their code > accepted. On this I agree with you - that is as it should be. > [2] We encountered a crash at work. The crash was a stack > overflow in program written exclusively on Ocaml. After > convincing the developers in question that Ocaml (being a > functional language) wasn't immune to the practicalities of real > life (a non-infinite stack), a fix was needed. It genuinely took > three of them a day crowded around a computer and a whiteboard to > alter the problematic function away from being a plain recursive > function. The purpose of the function in question was to read > data from stderr and forward it to syslog. These sound like somewhat novice OCaml programmers. Any OCaml programmer worth his salt learns to write functions using tail recursion so they don't use any stack space (past the first frame of course). It gets to be a habit, pretty much second nature. I regularly write code, in both OCaml and in C, that recurses billions of levels with no problem. The problem you are describing is one that shouldn't have occurred in the first place, if a recursion-experienced developer had written it. That it took so long to fix is another indication that this group was still coming up to speed, recursion-wise - the techniques used to transform naive recursion to tail recursion are pretty mechanical once one has used them for a while.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 07:16 -0700 |
| Message-ID | <2560c1b7-958a-4461-a57a-0a116ebe44a4@googlegroups.com> |
| In reply to | #65260 |
On Saturday, July 11, 2015 at 2:36:12 PM UTC+1, Tim Rentsch wrote: > > I use recursion routinely. IME it is an extremely valuable and > reliable tool, provided (like all tools) it is used properly. > I use it rarely, but not so rarely. If the problem naturally lends itself to recursion, I'll write it recursively rather create buffers,a s long as efficiency allows it. For example you want to check whether two 2D curves intersect. Obviously if the bounding boxes don't intersect, they don't intersect. And if both curves are straight lines, within tolerance, you can use a line intersection algorithm. If neither condition holds, a good strategy is to subdivide one or both of the curves, and run some extra tests. So that's very easy to write recursively. If your tolerance is 1 pixel and curves are always under 4 billion pixels long, and you cut halfway, your stack won't go deeper than 32, so stack space isn't going to be a problem. Now floodfill also lends itself naturally to recursion. Stop if the target pixel is the destination colour or a boundary. Otherwise set it tot eh destination colour and floodfill to the north, south, east and west. For anything other than a tiny raster, this algorithm is a disaster. > In most cases the problem with recursion is that someone who is > using it doesn't really understand different kinds of recursion. > Most programmers get only a shallow introduction to recursion, > kind of like learning about sorting by looking only at bubble > sort. Bubble sort has the advantage that it is easy to explain, > but it certainly isn't all one should know if one wants to > understand sorting. The problem with how recursion is taught is > that most often the teaching stops at the bubble sort level. > > That depends on how the recursion is accomplished. If the > recursion is done naively, that is often true. If the recursion > is done using the better-behaved recursion constructs, it will > never be true. The key point is that recursive calls don't > necessarily consume any stack space, but lots of people don't > know that or distinguish between the different kinds. > You need an insight into how the compiler is optimising the recursion. The best way to get that insight is to write the algorithm in C, disabling optimisation, then try to remove the recursion. > > IME recursion often produces code that is shorter, easier to > comprehend, and more obviously correct than a corresponding > non-recursive version. (I will take up the example below.) > Understanding and appreciating that isn't trivial, and I think > that is the mistake that many recursion advocates make: it > isn't reasonable to expect a bubble-sort-level understanding > of recursion to handle writing recursive code effectively. If > this sounds harsh, well maybe it is, but it reflects my own > experience - I had been programming more than 30 years (and > having seen and used recursion for almost all of those) before > I got beyond the CS 101 level of understanding recursion. > It produces code with certain theoretical advantages, if you consider computers to be machines that calculate rather than machines that do things. But it's harder for a human programmer who isn't a professional mathematician to understand and write the programs, and it's a lot harder to make the processing efficient. AS you've effectively admitted.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 14:23 -0700 |
| Message-ID | <kfnwpy1p12a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65266 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 2:36:12 PM UTC+1, Tim Rentsch wrote: > >> I use recursion routinely. IME it is an extremely valuable and >> reliable tool, provided (like all tools) it is used properly. >[snip] >> In most cases the problem with recursion is that someone who is >> using it doesn't really understand different kinds of recursion. >> Most programmers get only a shallow introduction to recursion, >> kind of like learning about sorting by looking only at bubble >> sort. Bubble sort has the advantage that it is easy to explain, >> but it certainly isn't all one should know if one wants to >> understand sorting. The problem with how recursion is taught is >> that most often the teaching stops at the bubble sort level. >> >> That depends on how the recursion is accomplished. If the >> recursion is done naively, that is often true. If the recursion >> is done using the better-behaved recursion constructs, it will >> never be true. The key point is that recursive calls don't >> necessarily consume any stack space, but lots of people don't >> know that or distinguish between the different kinds. > > You need an insight into how the compiler is optimising the > recursion. I don't agree with this. It may be important to understand what low-level code can represent a tail call (whether recursive or not), but it is not important to understand how a compiler decides to produce such a code sequence. In fact I'm not sure even that it's important to understand what is going on in terms of low-level code sequences; what is important is being able to recognize which calls are tail calls and which are not, and how to transform function definitions with calls that are not tail calls into definitions that do use tail calls, and that does not require either understanding lower-level instructions (eg, machine language) or how compilers might choose to generate those instructions. > The best way to get that insight is to write the algorithm in C, > disabling optimisation, then try to remove the recursion. IMO that is an absurd notion. The best way to understand tail recursion is to use recursive functions exclusively (ie, with no iteration allowed), and learn and practice how to transform calls that are not tail calls into calls that are tail calls. >> IME recursion often produces code that is shorter, easier to >> comprehend, and more obviously correct than a corresponding >> non-recursive version. (I will take up the example below.) >> Understanding and appreciating that isn't trivial, and I think >> that is the mistake that many recursion advocates make: it >> isn't reasonable to expect a bubble-sort-level understanding >> of recursion to handle writing recursive code effectively. If >> this sounds harsh, well maybe it is, but it reflects my own >> experience - I had been programming more than 30 years (and >> having seen and used recursion for almost all of those) before >> I got beyond the CS 101 level of understanding recursion. > > It produces code with certain theoretical advantages, if you > consider computers to be machines that calculate rather than > machines that do things. But it's harder for a human programmer > who isn't a professional mathematician to understand and write > the programs, and it's a lot harder to make the processing efficient. > > AS you've effectively admitted. I have said no such thing, either directly or "effectively." What was missing from my earlier background was not mathematical sophistication but just educational background, which was provided by courses and reading supplied in a Computer Science context, not a mathematical context. The idea that only mathematicians (either professional or non-professional) are capable of becoming proficient at writing good recursive function definitions is ludicrous; any competent software developer is capable of that, if given suitable educational material and guidance, none of which need be concerned with mathematics.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-15 15:27 -0700 |
| Message-ID | <51ff5491-51a5-4c74-b0f6-670b2922635c@googlegroups.com> |
| In reply to | #65661 |
On Wednesday, July 15, 2015 at 10:23:51 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > The best way to get that insight is to write the algorithm in C, > > disabling optimisation, then try to remove the recursion. > > IMO that is an absurd notion. The best way to understand tail > recursion is to use recursive functions exclusively (ie, with no > iteration allowed), and learn and practice how to transform calls > that are not tail calls into calls that are tail calls. > If you write the function recursively, in C, then you have the naive, fully recursive version. You know it's correct because functional programming functions are always correct. Now rewrite it to remove the recursion, using the original version to test it against. Now obviously you can miss a test case, but assuming that the tests are adequate, you've now proved that the removed calls are tail-recursive. If you practice transforming calls, then you could have got it right, or you could have failed to understand the procedure, and unless your functional programming language makes a syntactical distinction between the types of call, there's no way of knowing which. And even if it does make such a distinction, and rejects a supposedly tail-recursive marked call, there's no insight into why it has rejected that call or what needs to be done to fix up the situation. C is the superior language for learning about programming, because it provides a window onto what the processor is actually doing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 19:27 -0700 |
| Message-ID | <kfnoaj6jlcs.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65667 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, July 15, 2015 at 10:23:51 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> The best way to get that insight is to write the algorithm in C, >>> disabling optimisation, then try to remove the recursion. >> >> IMO that is an absurd notion. The best way to understand tail >> recursion is to use recursive functions exclusively (ie, with no >> iteration allowed), and learn and practice how to transform calls >> that are not tail calls into calls that are tail calls. > > If you write the function recursively, in C, then you have the > naive, fully recursive version. You know it's correct because > functional programming functions are always correct. > Now rewrite it to remove the recursion, using the original > version to test it against. Now obviously you can miss a test > case, but assuming that the tests are adequate, you've now > proved that the removed calls are tail-recursive. > > If you practice transforming calls, then you could have got it > right, or you could have failed to understand the procedure, > and unless your functional programming language makes a syntactical > distinction between the types of call, there's no way of knowing > which. And even if it does make such a distinction, and rejects > a supposedly tail-recursive marked call, there's no insight > into why it has rejected that call or what needs to be done to > fix up the situation. > > C is the superior language for learning about programming, > because it provides a window onto what the processor is actually > doing. Apparently you didn't understand my suggestion. The method you suggest is IMO confused and probably not going to be helpful in understanding how to write good recursive functions. Moreover it seems likely to be more of a hindrance than a help in going on to a broader understanding of writing programs in a functional programming language, assuming that is something one is aiming to do.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-11 15:27 +0100 |
| Message-ID | <mnr92m$sfc$1@dont-email.me> |
| In reply to | #65260 |
On 11/07/2015 14:36, Tim Rentsch wrote:
> Andrew Cooper <amc96@cam.ac.uk> writes:
>> [2] We encountered a crash at work. The crash was a stack
>> overflow in program written exclusively on Ocaml. After
>> convincing the developers in question that Ocaml (being a
>> functional language) wasn't immune to the practicalities of real
>> life (a non-infinite stack), a fix was needed. It genuinely took
>> three of them a day crowded around a computer and a whiteboard to
>> alter the problematic function away from being a plain recursive
>> function. The purpose of the function in question was to read
>> data from stderr and forward it to syslog.
>
> These sound like somewhat novice OCaml programmers. Any OCaml
> programmer worth his salt learns to write functions using tail
> recursion so they don't use any stack space (past the first
> frame of course). It gets to be a habit, pretty much second
> nature. I regularly write code, in both OCaml and in C, that
> recurses billions of levels with no problem.
It doesn't recurse using the stack then. C seems to be limited to a few
thousand levels.
But with optimisation turned on, it can sometimes avoid using the stack
(using tail recursion or whatever). It doesn't sound right however that
the outcome of a program should depend on the optimisation setting.
(I tried this code as an example of something that invites you to
express it recursively, but is really iterative. It ran under gcc -O3
but crashed with gcc -O0, when given a million-char string:
int my_strlen(char* s){
if (*s==0)
return 0;
else
return 1+my_strlen(s+1);
}
Maybe Ocaml encourages this sort of approach.)
--
Barrc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 08:00 -0700 |
| Message-ID | <703f15fe-30b8-48a6-a51a-04862ca26af7@googlegroups.com> |
| In reply to | #65272 |
On Saturday, July 11, 2015 at 3:28:05 PM UTC+1, Bart wrote: > On 11/07/2015 14:36, Tim Rentsch wrote: > > But with optimisation turned on, it can sometimes avoid using the stack > (using tail recursion or whatever). It doesn't sound right however that > the outcome of a program should depend on the optimisation setting. > It's not obvious what recursive calls are tail recursive and which are not. You have to have a deep understanding of how the optimiser works and not to be coding at 4 O clock in the morning to be sure that you code won't be catastrophically slow. With a naive C compiler, it's easy. Every function call in the source translates to a cheap but not trivial recursive call, which will put all the parameters, all of the local variables, and a little bit over overhead on the stack. If you've got experience and you don't use Russian doll programming that disguises your underlying bits, you can quickly eyeball the stack take and runtime overhead.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 15:46 -0700 |
| Message-ID | <lnio9qpb1z.fsf@kst-u.example.com> |
| In reply to | #65279 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 11, 2015 at 3:28:05 PM UTC+1, Bart wrote:
>> On 11/07/2015 14:36, Tim Rentsch wrote:
>> But with optimisation turned on, it can sometimes avoid using the stack
>> (using tail recursion or whatever). It doesn't sound right however that
>> the outcome of a program should depend on the optimisation setting.
>>
> It's not obvious what recursive calls are tail recursive and which are
> not. You have to have a deep understanding of how the optimiser works
> and not to be coding at 4 O clock in the morning to be sure that
> you code won't be catastrophically slow.
I believe that some functional languages (perhaps most of them) make
specific guarantees about tail recursion optimization. I don't know the
details, but it's possible and reasonable to rely on tail recursion to
be optimized to iteration.
For a language (like C) that doesn't make such guarantees, you may or
may not find it reasonable to depend on the compiler's behavior.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 16:01 -0700 |
| Message-ID | <e63c7374-ed9b-477a-ab40-380fbc12f7be@googlegroups.com> |
| In reply to | #65357 |
On Saturday, July 11, 2015 at 11:46:41 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > I believe that some functional languages (perhaps most of them) make > specific guarantees about tail recursion optimization. I don't know the > details, but it's possible and reasonable to rely on tail recursion to > be optimized to iteration. > > For a language (like C) that doesn't make such guarantees, you may or > may not find it reasonable to depend on the compiler's behavior. > If you're handling essentially iterative processes recursively then tail recursion optimisation is essential. Recursion is usually logarithmic when it's the natural solution to the problem - divide and conquer, rather than chop off a little bit, deal with that, then chop off the next little bit, and generally you want to ensure that the tree is genuinely balanced, you're dividing roughly by half each time.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-12 00:36 +0000 |
| Message-ID | <mnscqd$en6$1@speranza.aioe.org> |
| In reply to | #65357 |
Keith Thompson <kst-u@mib.org> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: (snip) >> It's not obvious what recursive calls are tail recursive and which are >> not. You have to have a deep understanding of how the optimiser works >> and not to be coding at 4 O clock in the morning to be sure that >> you code won't be catastrophically slow. > I believe that some functional languages (perhaps most of them) make > specific guarantees about tail recursion optimization. I don't know the > details, but it's possible and reasonable to rely on tail r secursion to > be optimized to iteration. > For a language (like C) that doesn't make such guarantees, you may or > may not find it reasonable to depend on the compiler's behavior. Yes. In some cases, you can make a simple change to handle the tail recursion case. That is, do it explicitly instead of depending on the compiler to figure it out. I suppose that makes the result somewhere between iterative and recursive, in implementation. But for recursive descent compilers, that usually doesn't come up. For that one case, it seems to me, that direct recursion is fine. Though that still leaves the problem of what to do when there is an error in the input. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 13:55 -0700 |
| Message-ID | <kfn1tg9qgxx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65279 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 3:28:05 PM UTC+1, Bart wrote: >> On 11/07/2015 14:36, Tim Rentsch wrote: >> >> But with optimisation turned on, it can sometimes avoid using the stack >> (using tail recursion or whatever). It doesn't sound right however that >> the outcome of a program should depend on the optimisation setting. > > It's not obvious what recursive calls are tail recursive and which are > not. It is obvious to anyone who understands what the definition of a tail call is. > You have to have a deep understanding of how the optimiser works > [snip elaboration]. No such understanding is needed because what constitutes a tail call is purely a property of how a function is defined, not on how well or poorly a compiler might optimize it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-15 14:12 -0700 |
| Message-ID | <dfdef522-d3fd-4f60-abca-7847bd502cd7@googlegroups.com> |
| In reply to | #65655 |
On Wednesday, July 15, 2015 at 9:55:30 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's not obvious what recursive calls are tail recursive and which are > > not. > > It is obvious to anyone who understands what the definition of a > tail call is. > If the recursive call is the last line of the function, then we can say it's a tail call, and it's easy enough to see how it can be optimised into iteration. But if it's embedded, that doesn't necessarily disqualify it as tail recursive. You can work it out by looking at the pattern of local memory access, but that's not something that can be eyeballed. > > > You have to have a deep understanding of how the optimiser works > > [snip elaboration]. > > No such understanding is needed because what constitutes a tail > call is purely a property of how a function is defined, not on > how well or poorly a compiler might optimize it. > Or sure, but the whole point is to replace the inefficient operation of recursion by a normal loop. If the language won't let you use loops, you have to work out how to coax the compiler into generating them, which isn't all that difficult, but not as easy as just using a loop directly either.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 19:45 -0700 |
| Message-ID | <kfnk2tujkiv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65658 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, July 15, 2015 at 9:55:30 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> It's not obvious what recursive calls are tail recursive and which are >>> not. >> >> It is obvious to anyone who understands what the definition of a >> tail call is. > > If the recursive call is the last line of the function, then we can > say it's a tail call, and it's easy enough to see how it can > be optimised into iteration. But if it's embedded, that doesn't > necessarily disqualify it as tail recursive. You can work it out > by looking at the pattern of local memory access, but that's > not something that can be eyeballed. Yes, it can be, if one has gotten the appropriate instruction, which doesn't take very long to provide. Apparently you are thinking about what constitutes a tail call by how/whether it can be transformed into an iterative form rather than a recursive form. That approach is more confusing than helpful. >>> You have to have a deep understanding of how the optimiser works >>> [snip elaboration]. >> >> No such understanding is needed because what constitutes a tail >> call is purely a property of how a function is defined, not on >> how well or poorly a compiler might optimize it. > > Or sure, but the whole point is to replace the inefficient operation > of recursion by a normal loop. That is the point of what a good compiler does. That is not the point of understanding the form of functions that make use of, eg, tail recursion rather than non-tail recursion. The point of understanding the tail-call pattern of function definition is to foster and develop a different way of thinking about how programs work. > If the language won't let you use > loops, you have to work out how to coax the compiler into generating > them, To repeat myself, this approach to framing the question is more confusing than helpful. > which isn't all that difficult, but not as easy as just > using a loop directly either. That is an artifact of educational background, not an inherent truth. IME once a certain level of familiarity and experience with functional and recursive methods is gained, writing recursive functions is in many cases easier and more natural than writing loops. I have been where you are, and then went forward to a fuller understanding of writing writing recursive functions and functional-style programs. So I think I am in a better position to say what is likely to work in advancing along that path.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 14:34 -0700 |
| Message-ID | <kfnsi8pp0k3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65272 |
Bartc <bc@freeuk.com> writes:
> On 11/07/2015 14:36, Tim Rentsch wrote:
>> Andrew Cooper <amc96@cam.ac.uk> writes:
>>
>>> [2] We encountered a crash at work. The crash was a stack
>>> overflow in program written exclusively on Ocaml. After
>>> convincing the developers in question that Ocaml (being a
>>> functional language) wasn't immune to the practicalities of real
>>> life (a non-infinite stack), a fix was needed. It genuinely took
>>> three of them a day crowded around a computer and a whiteboard to
>>> alter the problematic function away from being a plain recursive
>>> function. The purpose of the function in question was to read
>>> data from stderr and forward it to syslog.
>>
>> These sound like somewhat novice OCaml programmers. Any OCaml
>> programmer worth his salt learns to write functions using tail
>> recursion so they don't use any stack space (past the first
>> frame of course). It gets to be a habit, pretty much second
>> nature. I regularly write code, in both OCaml and in C, that
>> recurses billions of levels with no problem.
>
> It doesn't recurse using the stack then. [snip]
Yes. Did you miss the part where I said "learns to write
functions using tail recursion so they don't use any stack
space"?
> But with optimisation turned on, it can sometimes avoid using the
> stack (using tail recursion or whatever). It doesn't sound right
> however that the outcome of a program should depend on the
> optimisation setting.
I might agree with that, but at least as far as C goes that's
a quality-of-implementation question, not a language question.
And it is a fact of life in C that optimization can change
what a program does and how it works, and that is not limited
to questions regarding tail recursion.
> (I tried this code as an example of something that invites you
> to express it recursively, but is really iterative. It ran
> under gcc -O3 but crashed with gcc -O0, when given a
> million-char string:
>
> int my_strlen(char* s){
> if (*s==0)
> return 0;
> else
> return 1+my_strlen(s+1);
> }
>
> Maybe Ocaml encourages this sort of approach.)
This is not an example of tail recursion (and is not encouraged
in OCaml for just that reason). AFAIK this result is some sort
of special casing in gcc; the function definition is not a good
illustration of well-behaved recursion constructs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-15 15:37 -0700 |
| Message-ID | <5f394a20-64ec-4a15-9d2b-a8363fcbb248@googlegroups.com> |
| In reply to | #65662 |
On Wednesday, July 15, 2015 at 10:34:47 PM UTC+1, Tim Rentsch wrote:
> Bartc <bc@freeuk.com> writes:
>
> > On 11/07/2015 14:36, Tim Rentsch wrote:
>
> > (I tried this code as an example of something that invites you
> > to express it recursively, but is really iterative. It ran
> > under gcc -O3 but crashed with gcc -O0, when given a
> > million-char string:
> >
> > int my_strlen(char* s){
> > if (*s==0)
> > return 0;
> > else
> > return 1+my_strlen(s+1);
> > }
> >
> > Maybe Ocaml encourages this sort of approach.)
>
> This is not an example of tail recursion (and is not encouraged
> in OCaml for just that reason). AFAIK this result is some sort
> of special casing in gcc; the function definition is not a good
> illustration of well-behaved recursion constructs.
>
Bart's an experienced programmer and a compiler write.
But he's got it wrong.
int my_strlen(char *s)
{
int answer = 0;
start:
if(*s == 0)
return answer;
answer++;
s++;
goto start;
}
The recursion removal reveals the problem. As far as I
can tell. I must admit that I wouldn't have realised that
the function as written wasn't tail recursive, either.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-16 10:07 +0100 |
| Message-ID | <mo7s6c$agv$1@dont-email.me> |
| In reply to | #65668 |
On 15/07/2015 23:37, Malcolm McLean wrote:
> On Wednesday, July 15, 2015 at 10:34:47 PM UTC+1, Tim Rentsch wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 11/07/2015 14:36, Tim Rentsch wrote:
>>
>>> (I tried this code as an example of something that invites you
>>> to express it recursively, but is really iterative. It ran
>>> under gcc -O3 but crashed with gcc -O0, when given a
>>> million-char string:
>>>
>>> int my_strlen(char* s){
>>> if (*s==0)
>>> return 0;
>>> else
>>> return 1+my_strlen(s+1);
>>> }
>>>
>>> Maybe Ocaml encourages this sort of approach.)
>>
>> This is not an example of tail recursion (and is not encouraged
>> in OCaml for just that reason). AFAIK this result is some sort
>> of special casing in gcc; the function definition is not a good
>> illustration of well-behaved recursion constructs.
>>
> Bart's an experienced programmer and a compiler write.
> But he's got it wrong.
>
> int my_strlen(char *s)
> {
> int answer = 0;
> start:
> if(*s == 0)
> return answer;
> answer++;
> s++;
> goto start;
> }
>
> The recursion removal reveals the problem. As far as I
> can tell. I must admit that I wouldn't have realised that
> the function as written wasn't tail recursive, either.
What /is/ the problem? I don't understand. All I know that unoptimised,
a piece of code crashes, mostly likely due to exhausting the stack. But
optimised, it works. So something is being done, and I /suggested/ it
might be tail recursion optimisation. I made attempts to stop the
compiler just optimising by other means, but it's too much trouble to
find out exactly what it generated.
Here's the test code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
int my_strlen(volatile char* s){
if (*s==0)
return 0;
else
return 1+my_strlen(s+1);
}
int main(void) {
volatile char *p;
volatile int i,n,m;
m=rand()+1000000;
p=malloc(m+100);
//printf("%d %p\n",m,p);
for (i=0; i<m; ++i) p[i]='A';
p[m]=0;
//printf("%d\n",strlen((char*)p));
printf("%d\n",my_strlen((char*)p));
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-16 10:18 +0100 |
| Message-ID | <mo7sqe$cj8$1@dont-email.me> |
| In reply to | #65689 |
On 16/07/2015 10:07, Bartc wrote:
> On 15/07/2015 23:37, Malcolm McLean wrote:
>> On Wednesday, July 15, 2015 at 10:34:47 PM UTC+1, Tim Rentsch wrote:
>>> This is not an example of tail recursion (and is not encouraged
>>> in OCaml for just that reason). AFAIK this result is some sort
>>> of special casing in gcc; the function definition is not a good
>>> illustration of well-behaved recursion constructs.
>> But he's got it wrong.
>>
>> int my_strlen(char *s)
>> {
>> int answer = 0;
>> start:
>> if(*s == 0)
>> return answer;
>> answer++;
>> s++;
>> goto start;
>> }
>>
>> The recursion removal reveals the problem. As far as I
>> can tell. I must admit that I wouldn't have realised that
>> the function as written wasn't tail recursive, either.
>
> What /is/ the problem? I don't understand. All I know that unoptimised,
> a piece of code crashes, mostly likely due to exhausting the stack. But
> optimised, it works. So something is being done, and I /suggested/ it
> might be tail recursion optimisation. I made attempts to stop the
> compiler just optimising by other means, but it's too much trouble to
> find out exactly what it generated.
Actually it wasn't so hard. Looking at the generated code, with -O0
there was an actual recursive call to my_strlen. With -O3, there wasn't!
There seemed to be an actual loop, inlined onto main().
And stepping up the string size to 100M and 300M characters made it
proportionately slower. So the compiler /was/ eliminating that
recursion; where that counts as tail recursion elimination is not
relevant. The point is the over-use of the stack was removed:
optimisation makes a highly significant difference.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-16 13:35 +0100 |
| Message-ID | <87oajce0uv.fsf@bsb.me.uk> |
| In reply to | #65690 |
Bartc <bc@freeuk.com> writes:
> On 16/07/2015 10:07, Bartc wrote:
<snip>
>> What /is/ the problem? I don't understand. All I know that unoptimised,
>> a piece of code crashes, mostly likely due to exhausting the stack. But
>> optimised, it works. So something is being done, and I /suggested/ it
>> might be tail recursion optimisation. I made attempts to stop the
>> compiler just optimising by other means, but it's too much trouble to
>> find out exactly what it generated.
>
> Actually it wasn't so hard. Looking at the generated code, with -O0
> there was an actual recursive call to my_strlen. With -O3, there
> wasn't! There seemed to be an actual loop, inlined onto main().
>
> And stepping up the string size to 100M and 300M characters made it
> proportionately slower. So the compiler /was/ eliminating that
> recursion; where that counts as tail recursion elimination is not
> relevant.
It's not relevant to you, but the terminology is important in some
cases. Some compilers and/or languages guarantee tail call elimination
so it really matters what is and what is not a tail call.
Eliminating a tail call is a useful optimisation even when the call is
not a recursive one, not least because you don't need to check for
mutual recursion. In
int f(...) {
...
return g(...);
...
}
the call can be replaced by a jump (because nothing needs to be done
after g returns) and you get either just a slightly cheaper call or a
very big win if g calls f in the tail position.
Your case is not a tail call because 1 must be added after the call
returns. This does not mean, of course, that gcc should not optimise
away the use of the stack if it can -- and it clearly can do so. But
equally that does not mean that there's no point to getting the
terminology right.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-16 21:10 -0700 |
| Message-ID | <d44b6549-d8b3-409d-94d3-f48ac5efeabf@googlegroups.com> |
| In reply to | #65696 |
On Thursday, July 16, 2015 at 1:36:02 PM UTC+1, Ben Bacarisse wrote:
>
> It's not relevant to you, but the terminology is important in some
> cases. Some compilers and/or languages guarantee tail call elimination
> so it really matters what is and what is not a tail call.
>
> Eliminating a tail call is a useful optimisation even when the call is
> not a recursive one, not least because you don't need to check for
> mutual recursion. In
>
> int f(...) {
> ...
> return g(...);
> ...
> }
>
> the call can be replaced by a jump (because nothing needs to be done
> after g returns) and you get either just a slightly cheaper call or a
> very big win if g calls f in the tail position.
>
> Your case is not a tail call because 1 must be added after the call
> returns. This does not mean, of course, that gcc should not optimise
> away the use of the stack if it can -- and it clearly can do so. But
> equally that does not mean that there's no point to getting the
> terminology right.
>
I think my point is proved.
Functional programming is fine as a theoretical approach to computer
science, but it's too hard for the average programmer to know
when a call is "tail recursive" or not. So it's not suitable for
real software development.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-17 13:55 +0100 |
| Message-ID | <87mvyvc5a8.fsf@bsb.me.uk> |
| In reply to | #65752 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, July 16, 2015 at 1:36:02 PM UTC+1, Ben Bacarisse wrote:
>>
>> It's not relevant to you, but the terminology is important in some
>> cases. Some compilers and/or languages guarantee tail call elimination
>> so it really matters what is and what is not a tail call.
>>
>> Eliminating a tail call is a useful optimisation even when the call is
>> not a recursive one, not least because you don't need to check for
>> mutual recursion. In
>>
>> int f(...) {
>> ...
>> return g(...);
>> ...
>> }
>>
>> the call can be replaced by a jump (because nothing needs to be done
>> after g returns) and you get either just a slightly cheaper call or a
>> very big win if g calls f in the tail position.
>>
>> Your case is not a tail call because 1 must be added after the call
>> returns. This does not mean, of course, that gcc should not optimise
>> away the use of the stack if it can -- and it clearly can do so. But
>> equally that does not mean that there's no point to getting the
>> terminology right.
>>
> I think my point is proved.
>
> Functional programming is fine as a theoretical approach to computer
> science, but it's too hard for the average programmer to know
> when a call is "tail recursive" or not. So it's not suitable for
> real software development.
I won't pretend to know what "the average programmer" is like but I will
say that I am sceptical that you do. I will say that when I was teaching I
never found anyone who could not pick up the idea right away. I don't
recall it ever being seen as anything but a trivial definition that was
easy to understand. I suspect that people who get it wrong are more
likely simply never to have been told how to spot one.
I note your careful wording: too hard to know. Do you think the average
programmer could not learn what a tail call is in a matter of minutes?
That's the measure of how hard it is: know what the average programmer
knows, but what they can learn.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web