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 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-19 21:19 +0200 |
| Message-ID | <mogt7q$qn$1@speranza.aioe.org> |
| In reply to | #65911 |
On 07/19/2015 09:05 PM, Stefan Ram wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: >> Well, what I've gathered from all of this and doing some googling >> is that tail recursion can also be implemented as a loop and that >> "good optimizing compilers" should convert tail recursion code into >> a loop. > > »I have always felt that the transformation from > recursion to iteration is one of the most fundamental > concepts of computer science« - Donald E. Knuth And what does he mean by that? Assembler code was around before C and C transforms into assembler code. One can assume he knew perfectly well how function calls worked versus looping. If anything, I think functions (and thinking in those terms) lends themselves better to re-use and refactoring. If its easier to read a recursive call chain than a loop I don't know, it's probably about what one is used to. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-07-20 07:23 -0500 |
| Message-ID | <moip34$uoc$1@dont-email.me> |
| In reply to | #65913 |
Morten W. Petersen wrote: > On 07/19/2015 09:05 PM, Stefan Ram wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >>> Well, what I've gathered from all of this and doing some googling >>> is that tail recursion can also be implemented as a loop and that >>> "good optimizing compilers" should convert tail recursion code into >>> a loop. >> >> »I have always felt that the transformation from >> recursion to iteration is one of the most fundamental >> concepts of computer science« - Donald E. Knuth > > And what does he mean by that? > Computer science is only peripherally about coding. At the level of Knuth's statement, a "transformation" is more akin to an equivalence - "For (nearly) every recursive solution, there exists an equivalent iterative solution." > Assembler code was around before C and C transforms into assembler > code. One can assume he knew perfectly well how function calls > worked versus looping. > > If anything, I think functions (and thinking in those terms) lends > themselves better to re-use and refactoring. > > If its easier to read a recursive call chain than a loop I don't > know, it's probably about what one is used to. > > -Morten > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-19 21:11 +0000 |
| Message-ID | <55ac121c.4420984@news.xs4all.nl> |
| In reply to | #65911 |
"Morten W. Petersen" <morphex@gmail.com> wrote: > Well, what I've gathered from all of this and doing some googling > is that tail recursion can also be implemented as a loop and that > "good optimizing compilers" should convert tail recursion code into > a loop. Yes, this is the point. If it can't be _directly_ transformed into a straightforward loop without the addition of an extra stack or an extra counter, then for optimisation purposes at least it is not tail recursion. LISP advocates may quibble, but we're in a C newsgroup here - we should deal with practicalities, not mathematicopolitical theories. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 15:37 -0700 |
| Message-ID | <kfn4mkylal8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65924 |
raltbos@xs4all.nl (Richard Bos) writes: > "Morten W. Petersen" <morphex@gmail.com> wrote: > >> Well, what I've gathered from all of this and doing some googling >> is that tail recursion can also be implemented as a loop and that >> "good optimizing compilers" should convert tail recursion code into >> a loop. > > Yes, this is the point. > > If it can't be _directly_ transformed into a straightforward loop > without the addition of an extra stack or an extra counter, then > for optimisation purposes at least it is not tail recursion. LISP > advocates may quibble, but we're in a C newsgroup here - we should > deal with practicalities, not mathematicopolitical theories. I don't disagree exactly but I think this isn't the right way to think about it. Whether there is tail recursion is a question that can be answered fairly simply and easily just by looking at the function definition(s) involved. Whether those functions can be transformed into a loop is a much more subtle question involving C semantics and various messy constructs like pointers to local variables, setjmp(), function parameter types, and other things. IMO it is better to consider the question as just a simple declarative query rather than trying to produce an answer operationally, which is fraught with unobvious difficulties.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-09 13:55 +0000 |
| Message-ID | <55c75a82.16966562@news.xs4all.nl> |
| In reply to | #66075 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > "Morten W. Petersen" <morphex@gmail.com> wrote: > > > >> Well, what I've gathered from all of this and doing some googling > >> is that tail recursion can also be implemented as a loop and that > >> "good optimizing compilers" should convert tail recursion code into > >> a loop. > > > > Yes, this is the point. > > > > If it can't be _directly_ transformed into a straightforward loop > > without the addition of an extra stack or an extra counter, then > > for optimisation purposes at least it is not tail recursion. LISP > > advocates may quibble, but we're in a C newsgroup here - we should > > deal with practicalities, not mathematicopolitical theories. > > I don't disagree exactly but I think this isn't the right way to > think about it. Whether there is tail recursion is a question > that can be answered fairly simply and easily just by looking at > the function definition(s) involved. Whether those functions can > be transformed into a loop is a much more subtle question > involving C semantics and various messy constructs like pointers > to local variables, setjmp(), function parameter types, and other > things. IMO it is better to consider the question as just a > simple declarative query rather than trying to produce an answer > operationally, which is fraught with unobvious difficulties. Yes, but no. _In general_, I agree with you. However, in the context of how tail recursion can be useful in a C program, and tail optimisation can be useful in a C compiler, it's certainly necessary to take all those subtleties into account. And to be honest, it needn't be all that subtle. "Anything outside the recursive function which has a side effect which can change the course of the recursive function breaks tail recursion" is as subtle as we need to make it, unless we intend to write this into the Standard. (Side effects _from_ the function _on_ the outside program are, of course, fine. And while this does not cover, e.g., setjmp() from inside the function to the outside, that breaks recursion _itself_, not just tail recursion.) Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 11:22 -0700 |
| Message-ID | <kfnzj10wwsr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67032 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> "Morten W. Petersen" <morphex@gmail.com> wrote: >>> >>>> Well, what I've gathered from all of this and doing some googling >>>> is that tail recursion can also be implemented as a loop and that >>>> "good optimizing compilers" should convert tail recursion code into >>>> a loop. >>> >>> Yes, this is the point. >>> >>> If it can't be _directly_ transformed into a straightforward loop >>> without the addition of an extra stack or an extra counter, then >>> for optimisation purposes at least it is not tail recursion. LISP >>> advocates may quibble, but we're in a C newsgroup here - we should >>> deal with practicalities, not mathematicopolitical theories. >> >> I don't disagree exactly but I think this isn't the right way to >> think about it. Whether there is tail recursion is a question >> that can be answered fairly simply and easily just by looking at >> the function definition(s) involved. Whether those functions can >> be transformed into a loop is a much more subtle question >> involving C semantics and various messy constructs like pointers >> to local variables, setjmp(), function parameter types, and other >> things. IMO it is better to consider the question as just a >> simple declarative query rather than trying to produce an answer >> operationally, which is fraught with unobvious difficulties. > > Yes, but no. _In general_, I agree with you. However, in the > context of how tail recursion can be useful in a C program, and tail > optimisation can be useful in a C compiler, it's certainly necessary > to take all those subtleties into account. > > And to be honest, it needn't be all that subtle. "Anything outside > the recursive function which has a side effect which can change the > course of the recursive function breaks tail recursion" is as subtle > as we need to make it, unless we intend to write this into the > Standard. > > (Side effects _from_ the function _on_ the outside program are, of > course, fine. And while this does not cover, e.g., setjmp() from > inside the function to the outside, that breaks recursion _itself_, > not just tail recursion.) I think we are more or less in agreement, but let me say a little more to explore how large or small the difference may be. There are four different qualities that may be important to distinguish. The first is a language-independent notion of what constitutes a tail call (whether or not the call is a recursive call), regardless of whether any particular tail call might be subject to tail-call optimization. The second quality is a language-dependent (with the language being C in this case), but implementation-independent, property as to whether a particular tail call qualifies for TCO, considering just language semantics. This area covers things like setjmp(), etc. The third quality is an implementation-dependent question that says whether a particular tail call qualifies for TCO, considering things like ABI and other choices the implementation might make. An example of this I discovered recently is, it appears gcc will not do TCO for function whose return value is a struct (presumably having something to do with how such values are returned at the ABI level). (I've seen other examples at the ABI level but unfortunately I don't have any readily at hand.) There isn't anything inherent in the language that would prohibit TCO in such cases, but in the implementation (it appears that) there is. The fourth quality is, assuming a particular function call passes all of the preceding tests, whether a particular implmentation will actually effect an optimization for that call. Here we get into a very murky realm having to do with how the optimizer works, and is not necessarily easy to characterize, at least not completely. So probably what we have here is some black area and some white area, and some amount of gray in between. For various reasons I think the term "tail call" should be used just in reference to the first category. What I think you're saying is it is important to focus on the conditions that matter in the second and third categories. For these I would use the term "qualifies for TCO". IMO it is important to identify both properties, ie, to give them separate names. Leaving names aside, in practical application when considering C programs, it's important to focus on what makes a difference in terms of whether TCO is feasible, which at the risk of repeating myself is the point I think you are trying to make. So are we pretty much on the same page or is there something I have misunderstood?
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-07-19 17:22 +0100 |
| Message-ID | <87y4ic6rt5.fsf@gmail.com> |
| In reply to | #65895 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Is there any chance you can be persuaded not to make pronouncements > about things you don't know much about? Like Usenet isn't dying already - that would totally kill it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 10:25 -0700 |
| Message-ID | <23dacbf8-fe59-4469-b2c2-dc66a3c5cc46@googlegroups.com> |
| In reply to | #65874 |
On Sunday, July 19, 2015 at 1:24:10 AM UTC+1, Malcolm McLean wrote:
> On Sunday, July 19, 2015 at 12:27:00 AM UTC+1, Keith Thompson wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >
> >
> > Still, in the case of a call like f(g(), h()), the calls to g() and h()
> > still must occur before f() returns (assuming f refers to its
> > arguments), so it still wouldn't make for a tail-recursive call.
> >
> If we've got this
>
> int foo()
> {
> if(condition)
> return 0;
>
> return bar(foo(), foo());
> }
>
> and
> bar is
>
> int bar(a, b)
> {
> return a + b;
> }
>
> then it can affect the optimisation.
>
>
> bar becomes
>
> int bar( ... )
> {
> return foo() + foo();
> }
>
> So the last foo() call can be optimised out to a jump.
>
Of course I've got it wrong again.
We can't add foo() to anything. If bar is return b we're ok.
But then bar becomes a useless function. I think there's some
way of writing bar() so that it accumlates arguments to get
round that problem.
Doing it iteratively
int foo()
{
int answer = 0;
while(!condition())
answer += foo();
return answer;
}
you see you've got the same problem. You can't replace the while with
a goto function_start, because you need the answer variable. So
you have to rewrite foo() to accumulate the variable in a parameter.
Nor is it entirely obvious that the iterative and recursive solutions
evaluate condition() an identical number of times. I think it is,
but you've need to actually test it to see that on identical
condition() behaviour you get an identical number of calls.
This is the problem with the whole thing. It's not enough to be able
so see that an iterative solution is trivial, you've also got to
specify the function correctly, and non-intuitively.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-19 03:15 -0500 |
| Message-ID | <7qmmqal01d1iks2eb07lpv4apjbemooqoa@4ax.com> |
| In reply to | #65865 |
On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >And certainly I think it's time to admit that this stuff is too >complicated for the general programmer I certainly disagree. Functional programming is sufficiently different from more imperative models that there's a quite steep learning curve if all you know is on the imperative side of the world. Going from C to Haskell is much harder than going from C to Java, for example. But functional languages are not actually harder to learn than imperative languages in the first place. IOW, teaching a non-programmer Haskell is about as difficult as teaching them C or Java. So the "general programmer" is pretty much just as capable of learning to program in a functional language as they we able to learn to program in C, or whatever. It's just that the pain is more like learning to program in the first place, rather than learning yet another ~imperative language.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-19 10:36 +0100 |
| Message-ID | <mofr0j$a4p$1@dont-email.me> |
| In reply to | #65887 |
On 19/07/2015 09:15, Robert Wessel wrote: > On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean > <malcolm.mclean5@btinternet.com> wrote: > >> And certainly I think it's time to admit that this stuff is too >> complicated for the general programmer > > > I certainly disagree. Functional programming is sufficiently > different from more imperative models that there's a quite steep > learning curve if all you know is on the imperative side of the world. > > Going from C to Haskell is much harder than going from C to Java, for > example. But functional languages are not actually harder to learn > than imperative languages in the first place. IOW, teaching a > non-programmer Haskell is about as difficult as teaching them C or > Java. So the "general programmer" is pretty much just as capable of > learning to program in a functional language as they we able to learn > to program in C, or whatever. It's just that the pain is more like > learning to program in the first place, rather than learning yet > another ~imperative language. It helps that the available functional languages are more high level than ones such as C (so that you don't need to worry about managing lists and strings of any length for example). But I think that imperative style matches what is common in everyday life (from instructions on filling in your tax return, to how to build self-assembly furniture, to the flow-chart I'm obliged to create these days if I want someone else to be able to operate my TV/PVR/DVD setup). I don't think functional style is used in the same way, unless someone wants to give any counter-examples from real life. (I remember seeing examples of Ocaml code where it started off the usual impenetrable mathematical style, then it lapsed into imperative mode, with for-loops and the rest, when it needed to get some real work done!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-07-19 12:45 -0400 |
| Message-ID | <4vQqx.260759$GA1.57478@fx19.iad> |
| In reply to | #65888 |
On Sunday July 19 2015 12:28, in comp.lang.c, "Stefan Ram" <ram@zedat.fu-berlin.de> wrote: > Bartc <bc@freeuk.com> writes: >>But I think that imperative style matches what is common in everyday >>life > > When one gives commands in everyday life, the commands are issued > to a specific party. OOP reflects this: Not to get into an off-topic discussion of OOP, but the above is a pretty wide generality. The SVO (Subject-Verb-Object) ordering, while natural in some languages, is not the only way to "give commands in everyday life". > buttler.bring( wine ); > chauffeur.driveTo( cinema ); > gardener.cut( flowers ); > governess.teach( children ); These are all examples of a particular style of SVO-like expression. Linguistically, they could all be expressed as VSO-like expressions: bring(butler, wine); driveTo(chauffeur, cinema); cut(gardener,flowers); teach(governess,children); >>I don't think functional style is used in the same way, unless someone >>wants to give any counter-examples from real life. > > Functional style is the way noun phrases are built in everyday life: > > the buttler of Joe > > = buttler( Joe ) 1) What if Joe has two butlers? 2) /I/ wouldn't say the phrase "the butler of Joe". Instead, I'd say "Joe's butler". That makes 'butler' a property of Joe, just like "Joe's toes" makes the toes a property of Joe. So, shouldn't the syntax be something like = Joe.butler; ? [snip] -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-07-19 13:05 -0400 |
| Message-ID | <xNQqx.63519$EC7.41336@fx12.iad> |
| In reply to | #65904 |
On Sunday July 19 2015 12:58, in comp.lang.c, "Stefan Ram"
<ram@zedat.fu-berlin.de> wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>On Sunday July 19 2015 12:28, in comp.lang.c, "Stefan Ram"
>>>buttler.bring( wine );
>
> The meaning of the special OO call notation conveys the
> semantics that the butler is the executor (interpreter)
> of the message.
>
>>bring(butler, wine);
>
> This could also mean »Bring wine to the butler.«.
Not as a Verb-Subject-Object expression.
Verb -> bring
Subject -> butler
Object -> wine
The verb ("bring") joins the object ("wine") to the subject ("butler").
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-07-19 13:09 -0400 |
| Message-ID | <6RQqx.124074$722.57777@fx14.iad> |
| In reply to | #65906 |
On Sunday July 19 2015 13:05, in comp.lang.c, "Lew Pitcher"
<lew.pitcher@digitalfreehold.ca> wrote:
> On Sunday July 19 2015 12:58, in comp.lang.c, "Stefan Ram"
> <ram@zedat.fu-berlin.de> wrote:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>On Sunday July 19 2015 12:28, in comp.lang.c, "Stefan Ram"
>>>>buttler.bring( wine );
>>
>> The meaning of the special OO call notation conveys the
>> semantics that the butler is the executor (interpreter)
>> of the message.
>>
>>>bring(butler, wine);
>>
>> This could also mean »Bring wine to the butler.«.
>
> Not as a Verb-Subject-Object expression.
>
> Verb -> bring
> Subject -> butler
> Object -> wine
>
> The verb ("bring") joins the object ("wine") to the subject ("butler").
Among a large number of others, the C standard function strcpy() is a
reasonable example of a VSO linguistic expression.
strcpy(dest,source);
Verb -> strcpy
Subject -> dest
Object -> source
The verb ("strcpy") joins the object ("source") to the subject ("dest").
As an SVO linguistic expression, this would have to be
dest.strcpy(source);
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 10:40 -0700 |
| Message-ID | <e140843e-f1c7-429c-b512-a163d7faa9a4@googlegroups.com> |
| In reply to | #65904 |
On Sunday, July 19, 2015 at 5:46:02 PM UTC+1, Lew Pitcher wrote: > > > > > When one gives commands in everyday life, the commands are issued > > to a specific party. OOP reflects this: > > Not to get into an off-topic discussion of OOP, but the above is a > pretty wide generality. The SVO (Subject-Verb-Object) ordering, while > natural in some languages, is not the only way to "give commands in > everyday life". > > > buttler.bring( wine ); > > chauffeur.driveTo( cinema ); > > gardener.cut( flowers ); > > governess.teach( children ); > > These are all examples of a particular style of SVO-like expression. > Linguistically, they could all be expressed as VSO-like expressions: > bring(butler, wine); > driveTo(chauffeur, cinema); > cut(gardener,flowers); > teach(governess,children); > The thing is, the butler is an object, not a thread. If the butler has his own execution thread, then you must say "pass command to bring wine to butler". The butler then receives the command, and, in his own good time, after he has attended to higher priority guests or made an essential (to him) bathroom trip, he brings the wine. That's how real butlers work.But OOP butlers grab the execution thread and stall everything until the wine is transferred. The functional style is saying butlerwithwine = command(butler, "bring wine"); but in fact you hardly ever store the result. drink(pourout( takeobject(command(butler, "bring wine"))), takeobject(command(maid, "bring glasses")))) to indicate that you are drinking wine brought by the butler that has been poured into glasses brought by the maid.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-19 22:31 +0100 |
| Message-ID | <87si8j7s27.fsf@bsb.me.uk> |
| In reply to | #65888 |
Bartc <bc@freeuk.com> writes:
> On 19/07/2015 09:15, Robert Wessel wrote:
>> On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean
>> <malcolm.mclean5@btinternet.com> wrote:
>>
>>> And certainly I think it's time to admit that this stuff is too
>>> complicated for the general programmer
>>
>> I certainly disagree. Functional programming is sufficiently
>> different from more imperative models that there's a quite steep
>> learning curve if all you know is on the imperative side of the world.
>>
>> Going from C to Haskell is much harder than going from C to Java, for
>> example. But functional languages are not actually harder to learn
>> than imperative languages in the first place. IOW, teaching a
>> non-programmer Haskell is about as difficult as teaching them C or
>> Java. So the "general programmer" is pretty much just as capable of
>> learning to program in a functional language as they we able to learn
>> to program in C, or whatever. It's just that the pain is more like
>> learning to program in the first place, rather than learning yet
>> another ~imperative language.
>
> It helps that the available functional languages are more high level
> than ones such as C (so that you don't need to worry about managing
> lists and strings of any length for example).
>
> But I think that imperative style matches what is common in everyday
> life (from instructions on filling in your tax return, to how to build
> self-assembly furniture, to the flow-chart I'm obliged to create these
> days if I want someone else to be able to operate my TV/PVR/DVD
> setup).
>
> I don't think functional style is used in the same way, unless someone
> wants to give any counter-examples from real life.
Functional programming is often called "declarative programming", and
that style does occur in real life -- all the time in fact. The
"declarative" answer to the problem "what is the EU flag" is "twelve
gold stars in a ring on top of a 3 by 2 blue rectangle":
euFlag = stars 12 `atop` rect 3 2 # fc blue # lw none
How are these stars arranged? They are at the vertices of a regular
polygon[1]:
where stars n = atPoints (trailVertices (regPoly n 0.35)) (repeat oneStar)
What does one of the stars look like? It's made by joining every other
point in a pentagon:
oneStar = star (StarSkip 2) (regPoly 5 0.15) # strokeP # fc gold # lw none
(This is Haskell using the Diagrams package so it's a real program. The
down-side of using a real system is that there is more fiddly detail
than there need to be. If you were teaching this stuff you'd use a much
simpler API whether procedural or declarative.)
Ask almost anyone how to draw a flag and they'll give you a declarative
program rather than a procedural one (though they might mix the two up a
bit). You can get the same sort of answer about recipes if you ask the
right questions. What is a your favourite fish pie? It's smoked
haddock, cod and prawns cooked with onion, garlic, tomatoes and capers
with a grilled mashed potato topping.
<snip>
[1] You'll notice, if you try it, that the stars are not quite correctly
placed. The dodecagon needs to be rotated by 1/2 an inter-star angle so
that there is a single star at the top, rather than a pair:
stars n = atPoints (trailVertices (regPoly n 0.35 # rotate aBit))
(repeat oneStar)
where aBit = 180/fromIntegral n @@ deg
For obvious reasons I did not want to get into that sort of detail...
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-09 14:05 +0000 |
| Message-ID | <55c75bd3.17302671@news.xs4all.nl> |
| In reply to | #65929 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Bartc <bc@freeuk.com> writes: > > > On 19/07/2015 09:15, Robert Wessel wrote: > >> On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean > >> <malcolm.mclean5@btinternet.com> wrote: > >> > >>> And certainly I think it's time to admit that this stuff is too > >>> complicated for the general programmer > >> > >> I certainly disagree. Functional programming is sufficiently > >> different from more imperative models that there's a quite steep > >> learning curve if all you know is on the imperative side of the world. > >> > >> Going from C to Haskell is much harder than going from C to Java, for > >> example. But functional languages are not actually harder to learn > >> than imperative languages in the first place. IOW, teaching a > >> non-programmer Haskell is about as difficult as teaching them C or > >> Java. So the "general programmer" is pretty much just as capable of > >> learning to program in a functional language as they we able to learn > >> to program in C, or whatever. It's just that the pain is more like > >> learning to program in the first place, rather than learning yet > >> another ~imperative language. > > > > It helps that the available functional languages are more high level > > than ones such as C (so that you don't need to worry about managing > > lists and strings of any length for example). > > > > But I think that imperative style matches what is common in everyday > > life (from instructions on filling in your tax return, to how to build > > self-assembly furniture, to the flow-chart I'm obliged to create these > > days if I want someone else to be able to operate my TV/PVR/DVD > > setup). > > > > I don't think functional style is used in the same way, unless someone > > wants to give any counter-examples from real life. > > Functional programming is often called "declarative programming", and > that style does occur in real life -- all the time in fact. The > "declarative" answer to the problem "what is the EU flag" is "twelve > gold stars in a ring on top of a 3 by 2 blue rectangle": > > euFlag = stars 12 `atop` rect 3 2 # fc blue # lw none Mind you, those are closer to markup languages than to programming languages. It's not normally possible to describe an _action_ using heraldic language or similar, only an object (in the non-programming meaning of that word). When you ask for the process of how to _make_ an EU flag, you get a lot closer to imperative style programming: - take a piece of cloth 1.5 times as wide as high; - paint this cloth aquamarine blue; - take twenty-four yellow, five-pointed stars of size x; - lightly mark a circle on the flag, 2/3 the height of the flag; - mark twelve points on the flag, situated equidistantly along this circle, starting at the top; - sew two stars to each point, one in front, one in back; - erase the circle. > Ask almost anyone how to draw a flag and they'll give you a declarative > program rather than a procedural one (though they might mix the two up a > bit). That's because they'll _describe_ the flag, not tell you how to draw it. Ask, OTOH, one of those "Learn To Draw In 12 Easy Lessons" how to draw a horse, and it won't give you a description of a horse; instead, it'll tell you to start by drawing an ellipse, then four rectangles, then another ellipse, then lines connecting those ellipses, then refinements, and so on. > You can get the same sort of answer about recipes if you ask the > right questions. What is a your favourite fish pie? It's smoked > haddock, cod and prawns cooked with onion, garlic, tomatoes and capers > with a grilled mashed potato topping. Again, that's a description of the pie, _not_ a recipe. A good cook can turn one into the other, but a good cook_book_ will give you the recipe, not the description. The Rick Stein babble is descriptive and declarative, the recipe is imperative. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-09 21:22 +0100 |
| Message-ID | <87h9o843fm.fsf@bsb.me.uk> |
| In reply to | #67033 |
raltbos@xs4all.nl (Richard Bos) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> Bartc <bc@freeuk.com> writes: >> >> > On 19/07/2015 09:15, Robert Wessel wrote: >> >> On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean >> >> <malcolm.mclean5@btinternet.com> wrote: >> >> >> >>> And certainly I think it's time to admit that this stuff is too >> >>> complicated for the general programmer >> >> >> >> I certainly disagree. Functional programming is sufficiently >> >> different from more imperative models that there's a quite steep >> >> learning curve if all you know is on the imperative side of the world. >> >> >> >> Going from C to Haskell is much harder than going from C to Java, for >> >> example. But functional languages are not actually harder to learn >> >> than imperative languages in the first place. IOW, teaching a >> >> non-programmer Haskell is about as difficult as teaching them C or >> >> Java. So the "general programmer" is pretty much just as capable of >> >> learning to program in a functional language as they we able to learn >> >> to program in C, or whatever. It's just that the pain is more like >> >> learning to program in the first place, rather than learning yet >> >> another ~imperative language. >> > >> > It helps that the available functional languages are more high level >> > than ones such as C (so that you don't need to worry about managing >> > lists and strings of any length for example). >> > >> > But I think that imperative style matches what is common in everyday >> > life (from instructions on filling in your tax return, to how to build >> > self-assembly furniture, to the flow-chart I'm obliged to create these >> > days if I want someone else to be able to operate my TV/PVR/DVD >> > setup). >> > >> > I don't think functional style is used in the same way, unless someone >> > wants to give any counter-examples from real life. >> >> Functional programming is often called "declarative programming", and >> that style does occur in real life -- all the time in fact. The >> "declarative" answer to the problem "what is the EU flag" is "twelve >> gold stars in a ring on top of a 3 by 2 blue rectangle": >> >> euFlag = stars 12 `atop` rect 3 2 # fc blue # lw none > > Mind you, those are closer to markup languages than to programming > languages. It's not normally possible to describe an _action_ using > heraldic language or similar, only an object (in the non-programming > meaning of that word). You are right that there are computational tasks that are not a natural fit for declarative languages (search for "Haskell" and "tackling the awkward squad" for example), but it is often the result of actions that is the important thing, and those are frequently amenable to a declarative style. (Unrelated, and even more off-topic, Haskell has a purely functional but imperative sub-language within it.) > When you ask for the process of how to _make_ an EU flag, you get a lot > closer to imperative style programming: > - take a piece of cloth 1.5 times as wide as high; > - paint this cloth aquamarine blue; > - take twenty-four yellow, five-pointed stars of size x; > - lightly mark a circle on the flag, 2/3 the height of the flag; > - mark twelve points on the flag, situated equidistantly along this > circle, starting at the top; > - sew two stars to each point, one in front, one in back; > - erase the circle. Yes, of course. But the point I was responding to was that a functional style is not used in real life. I think it very often is. >> Ask almost anyone how to draw a flag and they'll give you a declarative >> program rather than a procedural one (though they might mix the two up a >> bit). > > That's because they'll _describe_ the flag, not tell you how to draw > it. But, as the example shows, you don't need to know exactly how to draw a flag to draw it. The procedural style usually says too much. > Ask, OTOH, one of those "Learn To Draw In 12 Easy Lessons" how to draw a > horse, and it won't give you a description of a horse; instead, it'll > tell you to start by drawing an ellipse, then four rectangles, then > another ellipse, then lines connecting those ellipses, then refinements, > and so on. > >> You can get the same sort of answer about recipes if you ask the >> right questions. What is a your favourite fish pie? It's smoked >> haddock, cod and prawns cooked with onion, garlic, tomatoes and capers >> with a grilled mashed potato topping. > > Again, that's a description of the pie, _not_ a recipe. Only because of your (correct but modern) definition. Old recipes were often exactly like the one above. > A good cook can > turn one into the other, but a good cook_book_ will give you the recipe, > not the description. The Rick Stein babble is descriptive and > declarative, the recipe is imperative. I grant you the recipe example is stretching my point to breaking, but your reply does highlight an important part of the analogy. The "good cook" plays the role of the "good programming language". High-level languages let you say more using fewer words. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-09 16:14 -0700 |
| Message-ID | <8cbfc806-9caa-43be-aa27-1b9021d80ddf@googlegroups.com> |
| In reply to | #67041 |
On Sunday, August 9, 2015 at 9:23:06 PM UTC+1, Ben Bacarisse wrote: > > Yes, of course. But the point I was responding to was that a functional > style is not used in real life. I think it very often is. > You can nest a little bit. The limit is about three levels " a flag, containing a circle of stars, of five points, represents the European Union". But add another level or two describing the stars, and it becomes impossible to jump back out to "represents the European Union". You can concatenate indefinitely. You can write a long history of how the EU flag came to be. It will consist of thousands of short sentences, each with a small amount of internal nesting structure, strung together in what is probably a largely chronological order. > > I grant you the recipe example is stretching my point to breaking, but > your reply does highlight an important part of the analogy. The "good > cook" plays the role of the "good programming language". High-level > languages let you say more using fewer words. > That's only true to a point. A very low-level language has only a few simple operations which can be built into complex ones, but only in place. But once you've got a certain level of structure, the very low level operations are hidden away, and the higher-level operations are too specialised to be part of the core of a general-purpose language. What a higher-level language does is provide keywords which are not operations, but which are ways of setting up a programming environment in the language itself. An example is a C++ class which is designed to be used as a base from which user classes are derived. A pure virtual base function provides no functionality, but it's an interface by which the derived class and code which to which the derived class is passed can communicate with each other. Often the low-level equivalent - pass in a function pointer - will be a bit shorter, but it's less obvious what the "contract" should be. If you've got several functions and several datasets, the programmer has to make sure he attaches the right function to the right data, by hand. The higher level language is thus a bit longer and says more, in more words but it's got the advantage of being more robust to programmer error.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-10 05:39 +0200 |
| Message-ID | <mq96d6$ffp$1@speranza.aioe.org> |
| In reply to | #67046 |
On 10.08.2015 01:14, Malcolm McLean wrote:
[...]
>> I grant you the recipe example is stretching my point to breaking, but
>> your reply does highlight an important part of the analogy. The "good
>> cook" plays the role of the "good programming language". High-level
>> languages let you say more using fewer words.
>>
> That's only true to a point. A very low-level language has only a
> few simple operations which can be built into complex ones, but
> only in place. But once you've got a certain level of structure,
> the very low level operations are hidden away, and the higher-level
> operations are too specialised to be part of the core of a
> general-purpose language.
> What a higher-level language does is provide keywords which are
> not operations, but which are ways of setting up a programming
> environment in the language itself. An example is a C++ class which
> is designed to be used as a base from which user classes are derived.
> A pure virtual base function provides no functionality, but it's
> an interface by which the derived class and code which to which
> the derived class is passed can communicate with each other.
> Often the low-level equivalent - pass in a function pointer -
> will be a bit shorter, but it's less obvious what the "contract"
> should be. If you've got several functions and several datasets,
> the programmer has to make sure he attaches the right function to
> the right data, by hand.
> The higher level language is thus a bit longer and says more,
> in more words but it's got the advantage of being more robust to
> programmer error.
Well, the classic higher level language feature seems to be OOP, with
classes and instances. OOP with its classes are good for thinking
in taxonomy terms, that is classifying and organizing things into
groups.
Coming from the Python world, operator overloading / syntactic sugar is
also nice, to be able to implement some class that allows sequential
access is practical and "easy on the eyes". For example say I have an
IMAP server class that connects to an IMAP server. The class is setup
so that indexed access to instances of that class gives an RFC822
message, so instance[0] gives the first message available on the server.
Now say that I want to create a new IMAP server class that supports
SSL and caching. I can subclass the first IMAP server class, and
also override the method that gives sequential access, so that it
uses an internal dictionary to cache email messages, reducing network
use and latency.
Now there is no magic in the things above, but it is rather that higher
level languages work more on a conceptual level, enable thinking in
conceptual ways and that they hide away details of what it takes to
actually get something done.
Take for example the task of counting the digit 1 in a text.. Now
with the most recent version of Python, the internal storage format
of a string depends on what characters are used. But this is hidden
from the average programmer so that regardless of whether the string
contents is English and ASCII characters or Chinese with Chinese
characters, calling text.count('1') will do the right thing. Because of
this, a fresh programmer that hasn't been around for a long time can
think of a string as a sequence of characters, whatever characters they
are, and might never have to get to know the lower level details of
ASCII, Unicode and all those things, and instead focus on higher level
issues. The ability to focus is important, because there are a limited
number of things a person can consider at the same time.
With the proper abstractions and thinking, a set of structs and
increasingly abstracted functions could do the same as OOP, but I guess
the taxonomy-style thinking of OOP is something that comes naturally to
a lot of people.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-10 01:40 -0700 |
| Message-ID | <0c63c54a-08a2-4937-9f1b-dee147d06cff@googlegroups.com> |
| In reply to | #67051 |
On Monday, August 10, 2015 at 4:39:30 AM UTC+1, Morten W. Petersen wrote:
>
> Take for example the task of counting the digit 1 in a text.. Now
> with the most recent version of Python, the internal storage format
> of a string depends on what characters are used. But this is hidden
> from the average programmer so that regardless of whether the string
> contents is English and ASCII characters or Chinese with Chinese
> characters, calling text.count('1') will do the right thing.
>
> With the proper abstractions and thinking, a set of structs and
> increasingly abstracted functions could do the same as OOP, but I guess
> the taxonomy-style thinking of OOP is something that comes naturally to
> a lot of people.
>
A lot of high-level languages automate a bit of trivial reformatting
of data. Such as converting strings between different representations.
However the example actually breaks down in real life. In Arabic,
there's an Arabic glyph for one, which is used for everyday Arabic
numbers. But in texts written in Arabic, you also quite often see
Western numerals being used, particularly for scientific or
technical data. So if you search for digit '1' what do you actually
mean?
The the trivial data reformatting is grandiously named "proper
abstractions and thinking". Not really. It's just a recognition that
essentially the same data may be in different formats. To be fair,
you do sometimes have a taxonomy, but that's rare - sometimes
the real world objects you are modelling are structured with
hierarchical "is a" relationships, but not all that often.
[toc] | [prev] | [next] | [standalone]
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web