Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98254 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-07 05:08 -0800 |
| Last post | 2016-12-10 13:49 -0800 |
| Articles | 20 on this page of 180 — 22 participants |
Back to article view | Back to comp.lang.c
while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 05:08 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 13:46 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:27 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:17 +0000
Re: while loop vs do while loop reading from the file issue Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-12-07 14:54 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 07:29 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 17:20 +0000
Re: while loop vs do while loop reading from the file issue "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-08 01:24 +0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 22:51 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:30 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:45 -0500
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 17:50 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 12:56 -0500
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:09 -0800
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 14:38 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:29 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:35 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-08 16:57 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:45 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 01:08 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:30 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-09 01:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 02:34 -0800
Re: while loop vs do while loop reading from the file issue fir <profesor.fir@gmail.com> - 2016-12-10 03:18 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:43 -0800
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-10 18:21 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 10:08 +0000
Re: while loop vs do while loop reading from the file issue Manfred <noname@invalid.add> - 2016-12-09 19:19 +0100
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 12:39 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 14:58 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 16:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 19:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 20:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 21:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-10 22:33 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 23:50 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 00:35 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:52 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 01:34 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 02:25 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:11 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 18:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 19:44 +0000
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 13:11 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 22:40 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 02:03 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 12:53 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 13:04 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-12 15:16 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:00 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 00:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 03:25 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 13:08 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:56 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 15:31 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 08:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:07 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:12 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 18:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 18:34 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-13 18:39 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-13 13:47 -0500
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 19:03 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 11:30 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 20:10 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 12:42 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:29 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 14:27 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 16:13 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-14 07:33 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 09:05 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-13 12:48 -0800
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 21:37 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 00:08 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 01:24 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-13 17:56 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 02:33 +0000
Re: while loop vs do while loop reading from the file issue David Brown <david.brown@hesbynett.no> - 2016-12-14 10:03 +0100
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:09 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:24 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 13:00 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-14 08:54 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 17:01 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 17:27 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 20:24 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:47 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-15 11:54 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 04:02 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-15 07:40 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-15 11:48 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-16 11:09 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 18:35 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:18 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 20:14 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 20:15 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-13 22:26 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 02:19 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 12:45 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 14:00 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 20:59 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-14 21:59 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 02:42 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:20 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:28 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:42 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:53 +0000
Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-15 01:55 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 02:03 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 10:13 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-15 22:05 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 14:15 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 10:44 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 03:31 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 01:11 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 06:16 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 17:24 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 09:53 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 20:38 +0000
Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:13 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 21:50 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:19 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-16 15:03 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:20 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 02:21 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 12:14 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 04:56 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:28 +0000
Re: while loop vs do while loop reading from the file issue Ike Naar <ike@iceland.freeshell.org> - 2016-12-17 22:51 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 11:45 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 19:42 +0000
Re: while loop vs do while loop reading from the file issue Les Cargill <lcargill99@comcast.com> - 2016-12-17 20:39 -0600
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-18 10:49 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 09:41 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 10:01 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-16 12:31 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 13:33 -0800
Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-17 11:12 +1300
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-16 14:30 -0800
Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2016-12-20 11:16 +0000
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:29 -0800
Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 16:13 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 01:09 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 16:08 -0800
Re: while loop vs do while loop reading from the file issue Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2016-12-11 01:31 +0100
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 14:52 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 15:26 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:22 +0000
Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-11 16:42 +0000
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:56 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-11 12:56 -0800
Re: while loop vs do while loop reading from the file issue supercat@casperkitty.com - 2016-12-11 08:55 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 17:19 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 04:09 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:18 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 07:30 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 15:43 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:56 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:57 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-09 11:40 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-10 03:19 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-10 07:49 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 16:11 +0000
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-10 14:45 -0800
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:59 +0000
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:26 -0500
Re: while loop vs do while loop reading from the file issue Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:48 -0500
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-11 23:33 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:09 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 09:53 -0800
Re: while loop vs do while loop reading from the file issue Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:26 -0800
Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-07 11:50 -0800
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-07 23:12 -0800
Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 07:31 +0000
Re: while loop vs do while loop reading from the file issue Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 11:00 +0000
Re: while loop vs do while loop reading from the file issue Alla _ <modelling.data@gmail.com> - 2016-12-09 00:48 -0800
Re: while loop vs do while loop reading from the file issue Siri Cruise <chine.bleu@yahoo.com> - 2016-12-10 13:49 -0800
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-16 09:53 -0800 |
| Message-ID | <a724d7fb-b68b-444f-866d-e9b0d9d4cf8e@googlegroups.com> |
| In reply to | #99666 |
On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Friday, December 16, 2016 at 1:11:42 AM UTC, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> > On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
> >> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> >>
> >> >> > while(line = getline(fp))
> >> >> > priocessline(line);
> >> >>
> >> >> Anyway, how do you propose to write the endoffile function without
> >> >> putting a side effect into the condition?
> >> >>
> >> > You can't easily support all stream types, which is why C's feof()
> >> > doesn't work as everyone new to C thinks it should.
> >>
> >> Here is the code you cut. My question makes no sense without it.
> >>
> >> || while(!endoffile(fp))
> >> || {
> >> || line = getline(fp);
> >> || processline(line);
> >> || }
> >>
> >> You seem to be saying that your endoffile(fp) can not be written in C,
> >> and even if it built in to the language (or supplied in some other way)
> >> it won't work on all streams. I agree on both counts but I don't see
> >> why you want to take C back to the 70s.
> >>
> > Really we want this (pseudo-code)
> >
> > nextline:
> > line = getline();
> > if(line == endofdata)
> > goto endofdata;
> > processline(line);
> > goto nextline;
> > endofdata:
> >
> > but it's not structured.
>
> I think we agree about some of this though for some reason you cut the
> goto-less pseudo-code version of this that I posted. What didn't you
> like about it? I much prefer it to using goto.
>
> And you also cut the C version. What's unstructured about
>
> while (
> line = getline(),
> line != endofdata ) {
> processline(line);
> }
>
> ? (I know the term "structured" is not exactly specified.)
>
> I used a comma, by the way, because it matches the sequencing of your
> pseudo code more closely. You would, in practice, simplify the
> expression in C to while ((line = getline()) != endofdata) but the
> pattern
>
> while (
> code before,
> loop condition )
> body;
>
> is the more general one.
>
That pattern isn't structured.
Structured program are only allowed square blocks which do things
and diamond blocks which take binary branches. (And recursion,
but that's not an issue here). And they must be themselves
square blocks. (You must be able to take a structured program
and insert it as a square block in a greater program).
I don't think we can draw it thusly
start
|
|-Illegal join here-------|
| |
|-------------| |
| code before | |
|-------------| |
| |
/ \ |
/ \ |
/ \ |
/ \ |------| |
/condition\------------| body |---
\ ? / |------|
\ /
\ /
\ /
\ /
|
stop
I think that's right. I will admit you've got me puzzled.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 20:38 +0000 |
| Message-ID | <87wpezzk1o.fsf@bsb.me.uk> |
| In reply to | #99672 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Friday, December 16, 2016 at 1:11:42 AM UTC, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >> > On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
>> >> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >> >>
>> >> >> > while(line = getline(fp))
>> >> >> > priocessline(line);
>> >> >>
>> >> >> Anyway, how do you propose to write the endoffile function without
>> >> >> putting a side effect into the condition?
>> >> >>
>> >> > You can't easily support all stream types, which is why C's feof()
>> >> > doesn't work as everyone new to C thinks it should.
>> >>
>> >> Here is the code you cut. My question makes no sense without it.
>> >>
>> >> || while(!endoffile(fp))
>> >> || {
>> >> || line = getline(fp);
>> >> || processline(line);
>> >> || }
>> >>
>> >> You seem to be saying that your endoffile(fp) can not be written in C,
>> >> and even if it built in to the language (or supplied in some other way)
>> >> it won't work on all streams. I agree on both counts but I don't see
>> >> why you want to take C back to the 70s.
>> >>
>> > Really we want this (pseudo-code)
>> >
>> > nextline:
>> > line = getline();
>> > if(line == endofdata)
>> > goto endofdata;
>> > processline(line);
>> > goto nextline;
>> > endofdata:
>> >
>> > but it's not structured.
>>
>> I think we agree about some of this though for some reason you cut the
>> goto-less pseudo-code version of this that I posted. What didn't you
>> like about it? I much prefer it to using goto.
>>
>> And you also cut the C version. What's unstructured about
>>
>> while (
>> line = getline(),
>> line != endofdata ) {
>> processline(line);
>> }
>>
>> ? (I know the term "structured" is not exactly specified.)
>>
>> I used a comma, by the way, because it matches the sequencing of your
>> pseudo code more closely. You would, in practice, simplify the
>> expression in C to while ((line = getline()) != endofdata) but the
>> pattern
>>
>> while (
>> code before,
>> loop condition )
>> body;
>>
>> is the more general one.
>>
> That pattern isn't structured.
>
> Structured program are only allowed square blocks which do things
> and diamond blocks which take binary branches.
Where does that definition come from? It just sounds like a flow chart
to me, which was how programs were often sketched before structured
programming cam along.
> I don't think we can draw it thusly
<snip flow chart>
Given S a statement, C an expression suitable for a truth condition, and
E an arbitrary expression which we will turn into an expression
statement by adding a semi-colon, is
E;
while (C) { S; E; }
a structured program? What diagram does it correspond to? In what way
is that diagram different to the diagram you would have to draw for
while (E, C) S;
?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-16 21:13 +0000 |
| Message-ID | <8737hnfuha.fsf@gmail.com> |
| In reply to | #99685 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> That pattern isn't structured. >> >> Structured program are only allowed square blocks which do things >> and diamond blocks which take binary branches. > > Where does that definition come from? It just sounds like a flow chart > to me, which was how programs were often sketched before structured > programming cam along. Where do you suppose it came from? Do you think a) Malcolm looked upwhat "structured programme" meant and understood it or b) just made up his own definition based on something he once heard?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-16 21:50 +0000 |
| Message-ID | <87r357zgq3.fsf@bsb.me.uk> |
| In reply to | #99685 |
Just a clarification...
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Friday, December 16, 2016 at 5:24:32 PM UTC, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>
>>> > On Friday, December 16, 2016 at 1:11:42 AM UTC, Ben Bacarisse wrote:
>>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> >>
>>> >> > On Thursday, December 15, 2016 at 10:44:32 AM UTC, Ben Bacarisse wrote:
>>> >> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> >> >>
>>> >> >> > while(line = getline(fp))
>>> >> >> > priocessline(line);
>>> >> >>
>>> >> >> Anyway, how do you propose to write the endoffile function without
>>> >> >> putting a side effect into the condition?
>>> >> >>
>>> >> > You can't easily support all stream types, which is why C's feof()
>>> >> > doesn't work as everyone new to C thinks it should.
>>> >>
>>> >> Here is the code you cut. My question makes no sense without it.
>>> >>
>>> >> || while(!endoffile(fp))
>>> >> || {
>>> >> || line = getline(fp);
>>> >> || processline(line);
>>> >> || }
>>> >>
>>> >> You seem to be saying that your endoffile(fp) can not be written in C,
>>> >> and even if it built in to the language (or supplied in some other way)
>>> >> it won't work on all streams. I agree on both counts but I don't see
>>> >> why you want to take C back to the 70s.
>>> >>
>>> > Really we want this (pseudo-code)
>>> >
>>> > nextline:
>>> > line = getline();
>>> > if(line == endofdata)
>>> > goto endofdata;
>>> > processline(line);
>>> > goto nextline;
>>> > endofdata:
>>> >
>>> > but it's not structured.
>>>
>>> I think we agree about some of this though for some reason you cut the
>>> goto-less pseudo-code version of this that I posted. What didn't you
>>> like about it? I much prefer it to using goto.
>>>
>>> And you also cut the C version. What's unstructured about
>>>
>>> while (
>>> line = getline(),
>>> line != endofdata ) {
>>> processline(line);
>>> }
>>>
>>> ? (I know the term "structured" is not exactly specified.)
>>>
>>> I used a comma, by the way, because it matches the sequencing of your
>>> pseudo code more closely. You would, in practice, simplify the
>>> expression in C to while ((line = getline()) != endofdata) but the
>>> pattern
>>>
>>> while (
>>> code before,
>>> loop condition )
>>> body;
>>>
>>> is the more general one.
>>>
>> That pattern isn't structured.
>>
>> Structured program are only allowed square blocks which do things
>> and diamond blocks which take binary branches.
>
> Where does that definition come from? It just sounds like a flow chart
> to me, which was how programs were often sketched before structured
> programming cam along.
>
>> I don't think we can draw it thusly
> <snip flow chart>
>
> Given S a statement, C an expression suitable for a truth condition, and
> E an arbitrary expression which we will turn into an expression
> statement by adding a semi-colon, is
>
> E;
> while (C) { S; E; }
>
> a structured program? What diagram does it correspond to? In what way
> is that diagram different to the diagram you would have to draw for
>
> while (E, C) S;
>
> ?
That's not a fruitful question, especially considering your last remark
that I did not properly register:
> I will admit you've got me puzzled.
I expected you to say (or for me to out out) that both meet your rather
sketchy definition but it's now clear to me that you know that more is
needed. So a better questions is what is it about the differences that
is so important to your notion of structured? I.e. why is one graph of
boxes and lines OK and another not?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-16 14:19 -0800 |
| Message-ID | <4fd933b6-d713-43b4-9d3c-06657a4bcb91@googlegroups.com> |
| In reply to | #99706 |
On Friday, December 16, 2016 at 9:50:21 PM UTC, Ben Bacarisse wrote: > Just a clarification... > > That's not a fruitful question, especially considering your last remark > that I did not properly register: > > > I will admit you've got me puzzled. > > I expected you to say (or for me to out out) that both meet your rather > sketchy definition but it's now clear to me that you know that more is > needed. So a better questions is what is it about the differences that > is so important to your notion of structured? I.e. why is one graph of > boxes and lines OK and another not? > Blocks have to have one point of entry and of exit, and you can't get round that rule by splitting a block and jumping into or out of the connector line you have created. OTOH iteration is an allowed operation, and of course that means entering the block either from the first pass or from a subsequent one. So there must be a loop and hence a merge structure. Now I had thought that the C while was robust to creating non- structured programs. But I think now it is not. But it's not quite clear to me which rule you are breaking and why.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-16 15:03 -0800 |
| Message-ID | <ec373472-53cd-42e0-8c52-858178796bba@googlegroups.com> |
| In reply to | #99711 |
On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
> Now I had thought that the C while was robust to creating non-
> structured programs. But I think now it is not. But it's not quite
> clear to me which rule you are breaking and why.
Conditional tests aren't allowed to have side-effects in the traditional
pattern, but the remedy is to extend the rules of structured programming
to allow for "loop-and-a-half" constructs. While some people might prefer:
while(get_data(&my_data))
{
process_data(my_data);
}
to
for(;;) // Or while(1)..., or do {...} while(1), etc.
{
if (!get_data(&my_data))
break;
process_data(my_data);
}
the former pattern can make it awkward to add logic around the data-fetch
code. C may not have any particularly idiomatic way of representing a
loop-and-a-half construct in cases where the code before the test won't
fit in an expression, but the second construct above is still reasonably
clean.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 02:20 +0000 |
| Message-ID | <87fulnz479.fsf@bsb.me.uk> |
| In reply to | #99711 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, December 16, 2016 at 9:50:21 PM UTC, Ben Bacarisse wrote: >> Just a clarification... >> >> That's not a fruitful question, especially considering your last remark >> that I did not properly register: >> >> > I will admit you've got me puzzled. >> >> I expected you to say (or for me to out out) that both meet your rather >> sketchy definition but it's now clear to me that you know that more is >> needed. So a better questions is what is it about the differences that >> is so important to your notion of structured? I.e. why is one graph of >> boxes and lines OK and another not? >> > Blocks have to have one point of entry and of exit, and you can't > get round that rule by splitting a block and jumping into or out > of the connector line you have created. The code I showed: while (E, C) S; is a block with has one entry and one exit. In the paper that spawned the term, Dijkstra draws some of the block diagrams constructed from primitives. I can't be bothered with ASCII art so here they are drawn properly: http://www.bsb.me.uk/tmp/sp1.pdf Five of those six are straight from the paper using the same symbols and shapes. The sixth is the construct above showing its single entry and single exit. What is so beyond the pale about it? (To keep the form used in the paper, E is called S1, S is called S2 and C is the ? box.) There /is/ a problem with it, but it's that C is not flexible enough. You should be able to recursively replace the boxes in these diagrams with the dotted blocks -- that's the whole point of the single entry, single exit rule -- but in C you can't put arbitrary code where I put E in the example (S1 in the diagram). (Dijkstra should have used diamonds for the ? boxes because they can't be substituted in this way and that would make the distinction clearer.) > OTOH iteration is an allowed operation, and of course that means > entering the block either from the first pass or from a subsequent > one. So there must be a loop and hence a merge structure. > > Now I had thought that the C while was robust to creating non- > structured programs. But I think now it is not. But it's not quite > clear to me which rule you are breaking and why. You'd have to define some rules first. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-17 02:21 -0800 |
| Message-ID | <38f12ceb-ac88-4f03-86cf-b003dce3a479@googlegroups.com> |
| In reply to | #99719 |
On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> The code I showed:
>
> while (E, C) S;
>
> is a block with has one entry and one exit.
>
Yes, it holds to that rule.
>
> In the paper that spawned the term, Dijkstra draws some of the block
> diagrams constructed from primitives. I can't be bothered with ASCII
> art so here they are drawn properly:
>
> http://www.bsb.me.uk/tmp/sp1.pdf
>
> Five of those six are straight from the paper using the same symbols and
> shapes. The sixth is the construct above showing its single entry and
> single exit. What is so beyond the pale about it? (To keep the form
> used in the paper, E is called S1, S is called S2 and C is the ? box.)
>
> There /is/ a problem with it, but it's that C is not flexible enough.
> You should be able to recursively replace the boxes in these diagrams
> with the dotted blocks -- that's the whole point of the single entry,
> single exit rule -- but in C you can't put arbitrary code where I put E
> in the example (S1 in the diagram).
>
> (Dijkstra should have used diamonds for the ? boxes because they can't
> be substituted in this way and that would make the distinction clearer.)
>
> > OTOH iteration is an allowed operation, and of course that means
> > entering the block either from the first pass or from a subsequent
> > one. So there must be a loop and hence a merge structure.
> >
> > Now I had thought that the C while was robust to creating non-
> > structured programs. But I think now it is not. But it's not quite
> > clear to me which rule you are breaking and why.
>
> You'd have to define some rules first.
>
If you read the paper, Djikstra says
We have now seen three types of decomposition; we could
call them "concatenation", "selection" and "repetition"
respectively. The first two are understood by enumerative
reasoning, the last one by mathematical induction
.
The programs that can be written using the selection clauses
and the repetition clauses as only the means for sequencing
control, permit straightforward translation into a programming
language that is identical but for the fact that sequencing
control has to be expressed by jumps to labelled points.
The converse is not true. Alternatively: restricting ourselves
to the three mentioned types of decomposition leads to flowcharts
of a restricted topology compared with the flowcharts one can
make when arrows can be drawn from any block leading into any other.
Compared with that greater freedom, to restrict oneself to the
clauses presents itself as a sequencing discipline.
Why do I propose to adhere to this sequencing discipline ?
The justification for this decision can be presented in
many ways and let me try a number of them in the hope that
at least one of them will appeal to my readers.
So that's the answer. Djikstra's five primitives are meant to be
exhaustive. Now we need to understand on a deeper level why your
primitive is disallowed. Which in a sense I've done by using if ..
goto notation. But we need more than that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 12:14 +0000 |
| Message-ID | <87wpeyycq7.fsf@bsb.me.uk> |
| In reply to | #99730 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The code I showed: >> >> while (E, C) S; >> >> is a block with has one entry and one exit. >> > Yes, it holds to that rule. >> >> In the paper that spawned the term, Dijkstra draws some of the block >> diagrams constructed from primitives. I can't be bothered with ASCII >> art so here they are drawn properly: >> >> http://www.bsb.me.uk/tmp/sp1.pdf >> >> Five of those six are straight from the paper using the same symbols and >> shapes. The sixth is the construct above showing its single entry and >> single exit. What is so beyond the pale about it? (To keep the form >> used in the paper, E is called S1, S is called S2 and C is the ? box.) >> >> There /is/ a problem with it, but it's that C is not flexible enough. >> You should be able to recursively replace the boxes in these diagrams >> with the dotted blocks -- that's the whole point of the single entry, >> single exit rule -- but in C you can't put arbitrary code where I put E >> in the example (S1 in the diagram). >> >> (Dijkstra should have used diamonds for the ? boxes because they can't >> be substituted in this way and that would make the distinction clearer.) >> >> > OTOH iteration is an allowed operation, and of course that means >> > entering the block either from the first pass or from a subsequent >> > one. So there must be a loop and hence a merge structure. >> > >> > Now I had thought that the C while was robust to creating non- >> > structured programs. But I think now it is not. But it's not quite >> > clear to me which rule you are breaking and why. >> >> You'd have to define some rules first. >> > > If you read the paper, Djikstra says > > We have now seen three types of decomposition; we could > call them "concatenation", "selection" and "repetition" > respectively. The first two are understood by enumerative > reasoning, the last one by mathematical induction > . > The programs that can be written using the selection clauses > and the repetition clauses as only the means for sequencing > control, permit straightforward translation into a programming > language that is identical but for the fact that sequencing > control has to be expressed by jumps to labelled points. > > The converse is not true. Alternatively: restricting ourselves > to the three mentioned types of decomposition leads to flowcharts > of a restricted topology compared with the flowcharts one can > make when arrows can be drawn from any block leading into any other. > Compared with that greater freedom, to restrict oneself to the > clauses presents itself as a sequencing discipline. > > Why do I propose to adhere to this sequencing discipline ? > The justification for this decision can be presented in > many ways and let me try a number of them in the hope that > at least one of them will appeal to my readers. > > So that's the answer. Djikstra's five primitives are meant to be > exhaustive. But only two would be exhaustive[1]. In fact he gives six because he includes a multi-way selection. He's quite happy not to have a minimal set. Repetition is clearly important, but why two forms? One can be built from the other by either duplicating the test code or duplicating the statement code, just as the last form (the one in question) can be built by from a normal loop by duplicating some code. (Here, "duplicating" is not literal duplication -- you'd put it in a procedure if it were at all complex.) But notice how both of Dijkstra's loops are simply special cases of the last -- make S1 null to get a while loop and S2 null to get a do-while. It's just a combination both. If you want a minimal set of primitives, you could do worse than choose selection and the contended loop form. > Now we need to understand on a deeper level why your primitive is > disallowed. It's not disallowed, it's just not chosen by Dijkstra (or Hoare). And the reason is very simple -- its proof rule will be more complex than that for either of the simpler loops. Both Dijkstra and Hoare are primarily concerned with reasoning, formally, about code, so they want to use a set of primitives with the simplest possible proof rules, rather than just smallest number of primitives. They don't mind having an extra proof rule because it's simple. If you are not concerned with formal proofs, I don't see why you would not prefer to have only two primitives: choice and "my" repetition, and if you are concerned with formal proofs you wouldn't use C. Mind you, if you want to use the more general loop pattern a lot, you wouldn't opt for C either since C supports only some cases of it. <snip> [1] Formally, you don't even need two since a loop can be re-purposed to make a simple choice. But that's not the point here. We're talking about small (rather then formally minimal) sets of structuring primitives that are, none the less, practical to use. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-17 04:56 -0800 |
| Message-ID | <0c7b7ce2-1440-49bc-9061-a19363458a67@googlegroups.com> |
| In reply to | #99732 |
On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > But notice how both of Dijkstra's loops are simply special cases of the > last -- make S1 null to get a while loop and S2 null to get a do-while. > It's just a combination both. If you want a minimal set of primitives, > you could do worse than choose selection and the contended loop form. > I think that's the mistake. Null is not a generalisable case with these diagrams. We can jump into or out of a null block happily enough. It's blocks which do something which create problems for us. And you can't have two branches from two blocks going into the same block. Only branches from diamonds to block or blocks to diamonds. (I'm still not sure about this. "Djikstra seems to say so and he must be right because he's Djikstra" is the lowest level of understanding).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 19:28 +0000 |
| Message-ID | <87h962xsmq.fsf@bsb.me.uk> |
| In reply to | #99733 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> But notice how both of Dijkstra's loops are simply special cases of the >> last -- make S1 null to get a while loop and S2 null to get a do-while. >> It's just a combination both. If you want a minimal set of primitives, >> you could do worse than choose selection and the contended loop form. >> > I think that's the mistake. > Null is not a generalisable case with these diagrams. We can jump > into or out of a null block happily enough. It's blocks which do > something which create problems for us. I understand the words on their own, but that's about it. Structured programming has no jumps except within a fixed small set of primitives that describe how basic actions and, recursively, the diagrams themselves can be combined -- sequencing, choice and iteration. There is no prohibition on having a basic action which is "skip" or ";" -- the "if" diagram is just the "if/else" diagram with a "skip" action which is best drawn as a line. > And you can't have two branches from two blocks going into the same > block. Only branches from diamonds to block or blocks to diamonds. That would rule out having anything after an if/else. Or it would mean I don't follow. The latter is much more likely. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-12-17 22:51 +0000 |
| Message-ID | <slrn3vfso5bgcn.621.ike@iceland.freeshell.org> |
| In reply to | #99733 |
On 2016-12-17, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, December 17, 2016 at 12:14:19 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> But notice how both of Dijkstra's loops are simply special cases of the >> last -- make S1 null to get a while loop and S2 null to get a do-while. >> It's just a combination both. If you want a minimal set of primitives, >> you could do worse than choose selection and the contended loop form. >> > I think that's the mistake. > Null is not a generalisable case with these diagrams. We can jump > into or out of a null block happily enough. It's blocks which do > something which create problems for us. > > And you can't have two branches from two blocks going into the same > block. Only branches from diamonds to block or blocks to diamonds. > > (I'm still not sure about this. "Djikstra seems to say so and he > must be right because he's Djikstra" is the lowest level of > understanding). It's Dijkstra, not Djikstra.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-12-17 11:45 -0600 |
| Message-ID | <o33th0$io9$1@dont-email.me> |
| In reply to | #99730 |
Malcolm McLean wrote: > On Saturday, December 17, 2016 at 2:20:50 AM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The code I showed: >> >> while (E, C) S; >> >> is a block with has one entry and one exit. >> > Yes, it holds to that rule. >> >> In the paper that spawned the term, Dijkstra draws some of the block >> diagrams constructed from primitives. I can't be bothered with ASCII >> art so here they are drawn properly: >> >> http://www.bsb.me.uk/tmp/sp1.pdf >> >> Five of those six are straight from the paper using the same symbols and >> shapes. The sixth is the construct above showing its single entry and >> single exit. What is so beyond the pale about it? (To keep the form >> used in the paper, E is called S1, S is called S2 and C is the ? box.) >> >> There /is/ a problem with it, but it's that C is not flexible enough. >> You should be able to recursively replace the boxes in these diagrams >> with the dotted blocks -- that's the whole point of the single entry, >> single exit rule -- but in C you can't put arbitrary code where I put E >> in the example (S1 in the diagram). >> >> (Dijkstra should have used diamonds for the ? boxes because they can't >> be substituted in this way and that would make the distinction clearer.) >> >>> OTOH iteration is an allowed operation, and of course that means >>> entering the block either from the first pass or from a subsequent >>> one. So there must be a loop and hence a merge structure. >>> >>> Now I had thought that the C while was robust to creating non- >>> structured programs. But I think now it is not. But it's not quite >>> clear to me which rule you are breaking and why. >> >> You'd have to define some rules first. >> > > If you read the paper, Djikstra says > > We have now seen three types of decomposition; we could > call them "concatenation", "selection" and "repetition" > respectively. The first two are understood by enumerative > reasoning, the last one by mathematical induction > . > The programs that can be written using the selection clauses > and the repetition clauses as only the means for sequencing > control, permit straightforward translation into a programming > language that is identical but for the fact that sequencing > control has to be expressed by jumps to labelled points. > > The converse is not true. Alternatively: restricting ourselves > to the three mentioned types of decomposition leads to flowcharts > of a restricted topology compared with the flowcharts one can > make when arrows can be drawn from any block leading into any other. > Compared with that greater freedom, to restrict oneself to the > clauses presents itself as a sequencing discipline. > > Why do I propose to adhere to this sequencing discipline ? > The justification for this decision can be presented in > many ways and let me try a number of them in the hope that > at least one of them will appeal to my readers. > > So that's the answer. Djikstra's five primitives are meant to be > exhaustive. Now we need to understand on a deeper level why your > primitive is disallowed. Which in a sense I've done by using if .. > goto notation. But we need more than that. > > They aren't just *meant* to be exhaustive; there's a riff from "Godel, Escher, Bach" where he describes the languages Bloop and Floop ( bounded vs. free loops ) and indicates that there is a proof that "there is no higher level language than Floop" ). I take that to mean that it is exhaustive and this has been proven ( I have never taken the time to lay hands on that proof, though ). Of course the control structure that best-fits correctness thinking is the Finite State Machine, which is something you can build out of the mentioned primitives. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-17 19:42 +0000 |
| Message-ID | <87bmwaxrz8.fsf@bsb.me.uk> |
| In reply to | #99758 |
Les Cargill <lcargill99@comcast.com> writes: > Malcolm McLean wrote: <snip> >> If you read the paper, Djikstra says >> >> We have now seen three types of decomposition; we could >> call them "concatenation", "selection" and "repetition" >> respectively. The first two are understood by enumerative >> reasoning, the last one by mathematical induction >> . >> The programs that can be written using the selection clauses >> and the repetition clauses as only the means for sequencing >> control, permit straightforward translation into a programming >> language that is identical but for the fact that sequencing >> control has to be expressed by jumps to labelled points. >> >> The converse is not true. Alternatively: restricting ourselves >> to the three mentioned types of decomposition leads to flowcharts >> of a restricted topology compared with the flowcharts one can >> make when arrows can be drawn from any block leading into any other. >> Compared with that greater freedom, to restrict oneself to the >> clauses presents itself as a sequencing discipline. >> >> Why do I propose to adhere to this sequencing discipline ? >> The justification for this decision can be presented in >> many ways and let me try a number of them in the hope that >> at least one of them will appeal to my readers. >> >> So that's the answer. Djikstra's five primitives are meant to be >> exhaustive. <snip> > They aren't just *meant* to be exhaustive; there's a riff from > "Godel, Escher, Bach" where he describes the languages Bloop > and Floop ( bounded vs. free loops ) and indicates that there is a > proof that "there is no higher level language than Floop" ). I take > that to mean that it is exhaustive and this has been proven ( I have > never taken the time to lay hands on that proof, though ). There's two meaning for exhaustive here. One: computationally complete (a model of computation that, given unlimited but finite resources, can compute any computable function), and two: describes all the structures present in some simple but none the less useful programming language. Dijkstra includes more forms than are needed for the first meaning because he's aiming to describe the combining forms that a simple programming language might have. I'm not sure which meaning Malcolm has in mind. > Of course the control structure that best-fits correctness > thinking is the Finite State Machine, which is something > you can build out of the mentioned primitives. Can you point me to something that expands on this? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-12-17 20:39 -0600 |
| Message-ID | <o34sqq$gnp$1@dont-email.me> |
| In reply to | #99764 |
Ben Bacarisse wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Malcolm McLean wrote: > <snip> >>> If you read the paper, Djikstra says >>> >>> We have now seen three types of decomposition; we could >>> call them "concatenation", "selection" and "repetition" >>> respectively. The first two are understood by enumerative >>> reasoning, the last one by mathematical induction >>> . >>> The programs that can be written using the selection clauses >>> and the repetition clauses as only the means for sequencing >>> control, permit straightforward translation into a programming >>> language that is identical but for the fact that sequencing >>> control has to be expressed by jumps to labelled points. >>> >>> The converse is not true. Alternatively: restricting ourselves >>> to the three mentioned types of decomposition leads to flowcharts >>> of a restricted topology compared with the flowcharts one can >>> make when arrows can be drawn from any block leading into any other. >>> Compared with that greater freedom, to restrict oneself to the >>> clauses presents itself as a sequencing discipline. >>> >>> Why do I propose to adhere to this sequencing discipline ? >>> The justification for this decision can be presented in >>> many ways and let me try a number of them in the hope that >>> at least one of them will appeal to my readers. >>> >>> So that's the answer. Djikstra's five primitives are meant to be >>> exhaustive. > <snip> >> They aren't just *meant* to be exhaustive; there's a riff from >> "Godel, Escher, Bach" where he describes the languages Bloop >> and Floop ( bounded vs. free loops ) and indicates that there is a >> proof that "there is no higher level language than Floop" ). I take >> that to mean that it is exhaustive and this has been proven ( I have >> never taken the time to lay hands on that proof, though ). > > There's two meaning for exhaustive here. One: computationally complete > (a model of computation that, given unlimited but finite resources, can > compute any computable function), and two: describes all the structures > present in some simple but none the less useful programming language. > > Dijkstra includes more forms than are needed for the first meaning > because he's aiming to describe the combining forms that a simple > programming language might have. I'm not sure which meaning Malcolm has > in mind. > >> Of course the control structure that best-fits correctness >> thinking is the Finite State Machine, which is something >> you can build out of the mentioned primitives. > > Can you point me to something that expands on this? > It's roughly - very roughly- in the direction of Church-Rosser. This isn't what I was looking for but it's not bad. https://www.cs.auckland.ac.nz/courses/compsci220s1t/lectures/lecturenotes/old/NFA.pdf Remember - academics think of automata in terms of "languages" for all sorts of historic reasons. So the terminology is biased that way. In fact, we can have "message passing" of linguistic elements for things like control and standard computation. Bruce Powell-Douglas' "Doing Hard Time" is a more cookbook approach. It may depend on the Rose tool ( Rational Rose ) and is oriented towards "executable UML". -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-18 10:49 +0000 |
| Message-ID | <8737hl7brt.fsf@bsb.me.uk> |
| In reply to | #99776 |
Les Cargill <lcargill99@comcast.com> writes: > Ben Bacarisse wrote: >> Les Cargill <lcargill99@comcast.com> writes: <snip> >>> Of course the control structure that best-fits correctness >>> thinking is the Finite State Machine, which is something >>> you can build out of the mentioned primitives. >> >> Can you point me to something that expands on this? > > It's roughly - very roughly- in the direction of Church-Rosser. > > This isn't what I was looking for but it's not bad. > > https://www.cs.auckland.ac.nz/courses/compsci220s1t/lectures/lecturenotes/old/NFA.pdf Thanks. But that's just a standard text on NFAs and their languages, so I'm still lost as to what it was you were saying about correctness and control structures. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-16 09:41 -0800 |
| Message-ID | <lnzijvkbz5.fsf@kst-u.example.com> |
| In reply to | #99653 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Really we want this (pseudo-code)
>
> nextline:
> line = getline();
> if(line == endofdata)
> goto endofdata;
> processline(line);
> goto nextline;
> endofdata:
>
> but it's not structured.
But it can be written in an equivalent structured form:
while ((line = getline()) != endofdata) {
processline(line);
}
(This assumes `line` is of a type that can be compared for equality.)
--
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 | 2016-12-16 10:01 -0800 |
| Message-ID | <10e036fc-93fb-4d99-ba8f-1bbd16448b8c@googlegroups.com> |
| In reply to | #99669 |
On Friday, December 16, 2016 at 5:41:33 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] > > Really we want this (pseudo-code) > > > > nextline: > > line = getline(); > > if(line == endofdata) > > goto endofdata; > > processline(line); > > goto nextline; > > endofdata: > > > > but it's not structured. > > But it can be written in an equivalent structured form: > That's not really possible. Structured programming isn't about the notation you use for the program, but the logical flow. To turn an unstructured program into an equivalent one that is structured, you need to rewrite it, not translate it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-16 12:31 -0800 |
| Message-ID | <lneg17k44t.fsf@kst-u.example.com> |
| In reply to | #99676 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, December 16, 2016 at 5:41:33 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>> > Really we want this (pseudo-code)
>> >
>> > nextline:
>> > line = getline();
>> > if(line == endofdata)
>> > goto endofdata;
>> > processline(line);
>> > goto nextline;
>> > endofdata:
>> >
>> > but it's not structured.
>>
>> But it can be written in an equivalent structured form:
>>
> That's not really possible.
>
> Structured programming isn't about the notation you use for
> the program, but the logical flow. To turn an unstructured
> program into an equivalent one that is structured, you need
> to rewrite it, not translate it.
That's a quibble about the meaning of the word "structured".
Whether it's strictly structured or not, I'd say that my equivalent
version (which you inexplicably snipped):
while ((line = getline()) != endofdata) {
processline(line);
}
is more *nearly* "structured" than yours, and that it's much clearer
(at least to someone reasonably familiar with C, and such readers
are usually my only target audience for C code).
Why exactly did you feel the need to post your version with goto
statements? What point were you trying to make?
--
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 | 2016-12-16 13:33 -0800 |
| Message-ID | <74cef61a-e3aa-4162-a9c7-22a89af0ce46@googlegroups.com> |
| In reply to | #99684 |
On Friday, December 16, 2016 at 8:31:27 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Friday, December 16, 2016 at 5:41:33 PM UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> [...]
> >> > Really we want this (pseudo-code)
> >> >
> >> > nextline:
> >> > line = getline();
> >> > if(line == endofdata)
> >> > goto endofdata;
> >> > processline(line);
> >> > goto nextline;
> >> > endofdata:
> >> >
> >> > but it's not structured.
> >>
> >> But it can be written in an equivalent structured form:
> >>
> > That's not really possible.
> >
> > Structured programming isn't about the notation you use for
> > the program, but the logical flow. To turn an unstructured
> > program into an equivalent one that is structured, you need
> > to rewrite it, not translate it.
>
> That's a quibble about the meaning of the word "structured".
>
> Whether it's strictly structured or not, I'd say that my equivalent
> version (which you inexplicably snipped):
>
> while ((line = getline()) != endofdata) {
> processline(line);
> }
>
> is more *nearly* "structured" than yours, and that it's much clearer
> (at least to someone reasonably familiar with C, and such readers
> are usually my only target audience for C code).
>
> Why exactly did you feel the need to post your version with goto
> statements? What point were you trying to make?
>
A structured program should remain a structured program after
the compiler translates it to machine code.
The rule is that you can't jump into or out of a block. Each
block has one point of entry and one point of exit. But you can't
circumvent the rules by simply splitting a block into two and
jumping into the line connecting them.
You can however have backwards loops, otherwise you couldn't
have loops at all.
But I think yours and Ben's code violates some rule. It becomes
obvious if you ban all control-flow statements except if and
goto.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web