Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60096 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2015-04-15 11:46 -0700 |
| Last post | 2015-04-30 01:40 -0700 |
| Articles | 20 on this page of 318 — 32 participants |
Back to article view | Back to comp.lang.c
Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 11:46 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-15 19:55 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:00 -0700
Re: Readability part I - code Xcott Craver <xcottcraver@gmail.com> - 2015-04-15 13:19 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-16 13:08 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:25 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-04-16 01:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:37 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-05-01 02:07 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:29 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:13 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:34 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:46 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-04-30 05:54 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:37 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-01 11:48 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-02 23:59 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 20:52 +0000
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-08 16:15 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-09 16:14 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:11 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 00:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:51 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-30 20:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 05:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-01 06:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:17 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-16 11:01 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:26 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-16 13:19 -0500
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 09:20 +0200
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-04-17 08:21 -0400
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 15:04 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 06:18 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 12:24 -0500
Re: Readability part I - code Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-17 15:58 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 04:10 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 13:47 +0200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-04-30 13:48 +0100
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 16:35 +0200
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-04-30 10:00 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 06:25 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-02 15:53 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:42 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-04 09:41 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 07:01 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-06 09:34 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 04:33 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:51 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:51 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-07 21:49 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 13:22 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 15:27 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 21:00 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 00:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-06 13:11 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:48 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:26 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 16:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 20:22 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-08 02:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-08 10:53 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:30 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-08 09:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-08 11:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:31 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:01 +1200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-09 13:13 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:51 +1200
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-09 16:45 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:28 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:36 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-05-06 22:13 -0500
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:56 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 14:16 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:02 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:36 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 15:09 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 17:13 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:07 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-08 11:35 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:41 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 10:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 10:50 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-10 19:09 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 04:54 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 13:19 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-12 05:26 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:31 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:40 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 10:28 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-10 11:39 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 05:33 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 17:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 09:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:37 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:46 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:53 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:47 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 20:04 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 12:39 -0700
Re: Readability part I - code Nathan Wagner <nw@hydaspes.if.org> - 2015-05-12 07:34 +0000
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 10:58 +0000
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 21:00 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:18 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 23:37 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 00:07 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 16:52 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 01:19 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 01:43 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 11:00 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 12:33 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 13:25 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:01 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:26 -0700
Re: Readability part I - code Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 19:58 +0000
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 20:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:25 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 08:50 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-25 02:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:25 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:35 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 15:53 +0100
Re: Readability part I - code Martin Shobe <martin.shobe@yahoo.com> - 2015-07-10 10:20 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 16:30 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 10:49 -0700
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-10 11:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:47 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-13 20:20 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:57 -0700
Re: Readability part I - code "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-13 12:27 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:35 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 18:46 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-15 11:35 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:47 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 21:24 +0000
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 08:43 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-21 13:26 -0400
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 22:11 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-22 04:03 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:30 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:14 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:24 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 23:39 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-22 11:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-23 07:35 +1200
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:36 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:25 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 08:44 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-10 16:53 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:57 -0700
Re: Readability part I - code Öö Tiib <ootiib@hot.ee> - 2015-05-23 06:27 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-23 16:07 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-23 19:10 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:25 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 12:24 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:49 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 12:49 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:56 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:07 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:29 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:52 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 19:45 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:27 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:50 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:48 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-23 21:30 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:30 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:16 -0500
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 23:04 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:12 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-12 17:28 +1200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:43 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:16 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:34 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 22:52 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:45 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 12:53 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-21 11:01 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 20:18 +0100
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 21:47 +0100
Re: Readability part I - code Kusalananda <kusalananda@example.com> - 2015-05-24 07:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:18 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:15 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:53 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-11 14:09 +1200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 10:37 +0800
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 12:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-12 10:20 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 07:23 -0700
Re: Readability part I - code jadill33@gmail.com - 2015-05-11 13:30 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:14 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:15 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:38 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:38 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 17:58 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 13:44 -0500
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:32 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 11:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-21 08:41 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 18:12 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 19:20 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:35 -0700
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 14:54 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 15:10 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:51 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 13:22 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:47 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 17:05 -0700
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 11:04 +0200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 18:06 +0800
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 14:57 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 09:20 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:06 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:55 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 13:26 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 06:29 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 13:49 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:12 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 15:26 +0000
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-22 11:36 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 23:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:42 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:37 +0000
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 16:47 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 17:03 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 06:52 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:23 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:52 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 09:29 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 14:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:30 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:04 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 18:39 -0500
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:02 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 01:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:48 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:50 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 06:55 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 15:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:14 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:53 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 22:04 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 14:51 -0700
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:05 -0400
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:31 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:24 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:00 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-13 13:24 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 06:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 23:21 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:35 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:43 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 10:31 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 16:12 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 18:02 +0100
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-12 11:16 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 21:06 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:44 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:13 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:01 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:28 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:53 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:45 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:55 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:44 +0000
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 16:51 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:25 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-11 09:25 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:15 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 16:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:35 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 11:53 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 20:01 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:09 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:43 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-25 14:51 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-26 09:17 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:44 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:19 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 14:04 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 08:07 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-02 09:18 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-03 10:43 -0700
Re: Readability part I - code Melzzzzz <mel@zzzzz.com> - 2015-05-03 19:47 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 06:45 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-05 09:06 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 20:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:33 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:33 -0700
Re: Readability part I - code Les Cargill <lcargill99@comcast.com> - 2015-04-16 12:28 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:42 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 01:40 -0700
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-11 20:05 -0400 |
| Message-ID | <1biox.190623$GA1.117625@fx19.iad> |
| In reply to | #65345 |
On 7/11/15 5:51 PM, Malcolm McLean wrote: > It's the mismatch between something that makes theoretical sense > and something that human programmers actually want to use. > > Lisp's tree syntax for arithmetical expressions makes perfect sense, > and BODMAS does not 4 - 2 + 1 should be 1, not 3, and 2 * -3 > is another difficulty. And in reality, if you see 100 + 10 * 2 in > many contexts, you need to check the logic to see what is intended. > But trying to express formulae using the tree system is hopeless, maybe > if you'd been taught it a primary school it would feel natural, but > nobody is taught arithmetic with that notation. > > The only way that I see 4 - 2 + 1 = 1 would be if it was treated as 4 - (2 + 1) which goes contrary to the way I am used to seeing expressions evaluated. Universally, a series of additive terms (including some being subtracted) the subtraction only applies to the term immediately following. Never have I seen an implication that the minus applies to any other following term.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-12 01:31 +0100 |
| Message-ID | <87bnfirzbt.fsf@bsb.me.uk> |
| In reply to | #65345 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 10:05:04 PM UTC+1, Ben Bacarisse wrote: >> >> As you may know, one of C's grandparents (BCPL) had this construct. >> Function bodies where just expressions, many of which where blocks that >> returned. And Algol 68 (another ancestor) made little distinction >> between what C calls expressions and statements. Just as in C a >> procedure call is a function call whose value you ignore, in Algol 68 an >> IF clause is just a conditional expression whose value you ignore. >> >> It seems odd to me that this generality of design should have been >> thrown away. Why can't I declare a variable in the condition of an if? >> Why can't I initialise a variable with the result of a calculation that >> involves, for example, a while loop? These features would probably be >> used rarely, but omitting them complicates the language, at least from >> an intellectual point of view. >> > It's the mismatch between something that makes theoretical sense > and something that human programmers actually want to use. You just keep going like an aphorism energiser bunny. *I* want to use these constructs and I am a human programmer. You don't. Fine. You are not hindered by their availability. I am constrained by their absence. > Lisp's tree syntax for arithmetical expressions makes perfect sense, > and BODMAS does not 4 - 2 + 1 should be 1, not 3, and 2 * -3 > is another difficulty. And in reality, if you see 100 + 10 * 2 in > many contexts, you need to check the logic to see what is intended. > But trying to express formulae using the tree system is hopeless, maybe > if you'd been taught it a primary school it would feel natural, but > nobody is taught arithmetic with that notation. Does that relate in any way to what I'm saying? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 18:24 -0700 |
| Message-ID | <506f5fee-b247-4f67-aeaa-5d6b4aace78b@googlegroups.com> |
| In reply to | #65377 |
On Sunday, July 12, 2015 at 1:31:44 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's the mismatch between something that makes theoretical sense > > and something that human programmers actually want to use. > > You just keep going like an aphorism energiser bunny. *I* want to use > these constructs and I am a human programmer. You don't. Fine. You > are not hindered by their availability. I am constrained by their > absence. > That's OK as long as you're only writing code for private projects that won't be seen by anyone else. But when you need to use code that's doing something perfectly routine, and it's written in a fancy way rather than with a few simple loops, and it takes half the day to work through it, that's irritating.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-12 19:00 +0100 |
| Message-ID | <87fv4tqmrc.fsf@bsb.me.uk> |
| In reply to | #65386 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, July 12, 2015 at 1:31:44 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > It's the mismatch between something that makes theoretical sense >> > and something that human programmers actually want to use. >> >> You just keep going like an aphorism energiser bunny. *I* want to use >> these constructs and I am a human programmer. You don't. Fine. You >> are not hindered by their availability. I am constrained by their >> absence. >> > That's OK as long as you're only writing code for private projects > that won't be seen by anyone else. Not at all. I have found that I am not alone in being able to read code written using conditional expressions. There seems to be a large number of peculiar people who find such things perfectly simple and readable. Some of us can even follow deeply nest Lisp -- something you once said was not humanly possible. There are freaks out there -- accept it! Conversely, there are some people who find even the simplest code baffling, so writing "down" to the LCD is almost impossible. > But when you need to use code that's doing something perfectly > routine, and it's written in a fancy way rather than with a few > simple loops, and it takes half the day to work through it, that's > irritating. For you -- it's irritating for you -- it's not simply "irritating". Though you are, as always, low on detail, I bet that I'd find the loops irritating and the fancy code (whatever that is) much clearer. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-13 13:24 +0100 |
| Message-ID | <mo0aiu$g23$1@dont-email.me> |
| In reply to | #65430 |
On 12/07/2015 19:00, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> That's OK as long as you're only writing code for private projects >> that won't be seen by anyone else. > > Not at all. I have found that I am not alone in being able to read code > written using conditional expressions. There seems to be a large number > of peculiar people who find such things perfectly simple and readable. > Some of us can even follow deeply nest Lisp -- something you once said > was not humanly possible. There are freaks out there -- accept it! > Conversely, there are some people who find even the simplest code > baffling, so writing "down" to the LCD is almost impossible. The LCD of programming code be useful. There are a small number of constructions that everyone knows and understands, which might differ only in a particular language's syntax. Then you can't really go wrong (well until you into the semantics which might vary across languages). The in-expression form of if-then-else is borderline, but there was a reason why I adopted only the (a|b|c) form from Algol-68 and not the (a|b:|c...) or whatever it was that corresponded to if-then-elif.... Beyond a certain point, it just becomes too cryptic instead of obvious. Also, if someone ever wants to translate an algorithm into another language (or just wants to understand it), the more LCD-like it is the better. (If I need to translate or understand some code, and there is a choice of source languages, I generally choose Lua or Pascal if they are available. Those are simple languages with fewer fancy features. Something like Python would more than likely include impenetrable features from its vast repertoire of built-ins and libraries.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-13 06:11 -0700 |
| Message-ID | <eb0d00d4-0924-47c9-9e4e-01a6acbc39ec@googlegroups.com> |
| In reply to | #65478 |
On Monday, July 13, 2015 at 1:24:33 PM UTC+1, Bart wrote: > On 12/07/2015 19:00, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Conversely, there are some people who find even the simplest code > > baffling, so writing "down" to the LCD is almost impossible. > > The LCD of programming code be useful. There are a small number of > constructions that everyone knows and understands, which might differ > only in a particular language's syntax. Then you can't really go wrong > (well until you into the semantics which might vary across languages). > > The in-expression form of if-then-else is borderline, but there was a > reason why I adopted only the (a|b|c) form from Algol-68 and not the > (a|b:|c...) or whatever it was that corresponded to if-then-elif.... > > Beyond a certain point, it just becomes too cryptic instead of obvious. > > Also, if someone ever wants to translate an algorithm into another > language (or just wants to understand it), the more LCD-like it is the > better. > > (If I need to translate or understand some code, and there is a choice > of source languages, I generally choose Lua or Pascal if they are > available. Those are simple languages with fewer fancy features. > Something like Python would more than likely include impenetrable > features from its vast repertoire of built-ins and libraries.) > Exactly. If a sub-routine isn't provided, and the reader doesn't know how to implement it himself, then the code becomes useless once taken out of its environment. So routines are most useful if written in C, with the source having not a single dependency. The next best situation is a file which has functions which call each other or rely on each other to set up data structures, but has no external dependencies. The next best is a dependency on the standard library, and the minimum good situation is a series of files which depend on each other. Once you've got more dependencies, the situation rapidly gets more difficult. It's the same with the language, the simpler the better. The place for complexity is the algorithm, not the language used to express it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-11 23:09 +0100 |
| Message-ID | <87wpy6s5wm.fsf@bsb.me.uk> |
| In reply to | #65341 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>Why can't I declare a variable in the condition of an if? >>Why can't I initialise a variable with the result of a calculation that >>involves, for example, a while loop? > > As you may know, one of C's children (C++) has these possibilities. Yes, but C++ does not make the syntax general in the way I meant. I was giving examples -- not an exhaustive list of everything that should be allowed. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-11 23:21 +0100 |
| Message-ID | <mns4qv$4en$1@dont-email.me> |
| In reply to | #65341 |
On 11/07/2015 22:04, Ben Bacarisse wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> A function-like macro often need to return a value based on a
>>> condition. Since it can't use the return keyword, ? : syntax is
>>> the only way of making the macro look like a function call.
>>
>> It is true that »if« cannot be used in an expression.
>>
>> However, if one would really care for macros, it would
>> be more general to introduce the block return as in:
>>
>> double const pi ={ double x = atan( 1 ); x *= 4; return x; };
>
> As you may know, one of C's grandparents (BCPL) had this construct.
> Function bodies where just expressions, many of which where blocks that
> returned. And Algol 68 (another ancestor) made little distinction
> between what C calls expressions and statements. Just as in C a
> procedure call is a function call whose value you ignore, in Algol 68 an
> IF clause is just a conditional expression whose value you ignore.
>
> It seems odd to me that this generality of design should have been
> thrown away. Why can't I declare a variable in the condition of an if?
> Why can't I initialise a variable with the result of a calculation that
> involves, for example, a while loop? These features would probably be
> used rarely, but omitting them complicates the language, at least from
> an intellectual point of view.
The private language I was using until a few years worked ago just that
way. It was inspired by Algol-68 in syntax and also in the way that
statements and expression were interchangeable.
But when I decided it should use (high level) C as a target, that caused
problems, because C didn't work like that. So the language was
simplified to make statements and expressions separate.
Then I found out that gcc has an extension where this might have been
possible to express. But by then, I'd decided that having statements and
expressions distinct was much better; easier to implement, and more
kinds of errors were picked up.
(A few statements that were also useful as expressions, such as simple
if/then/else/fi, had duplicate forms as expressions, using (a|b|c)
syntax, like C's a?b:c. But I do miss the coolness of being to write any
arbitrarily complex statement on either or both sides of an assignment -
or as a function argument.
That reminds me - I still have the construct (n|a,b,c,...|z) to select
the nth value from a list, but I haven't managed to express that in C
yet. I might have to use that gcc extension after all as it calls for a
switch statement inside an expression.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 17:35 -0700 |
| Message-ID | <lnfv4unrg2.fsf@kst-u.example.com> |
| In reply to | #65353 |
Bartc <bc@freeuk.com> writes:
[...]
> That reminds me - I still have the construct (n|a,b,c,...|z) to select
> the nth value from a list, but I haven't managed to express that in C
> yet. I might have to use that gcc extension after all as it calls for a
> switch statement inside an expression.)
(int[]){a, b, c}[n]
Though it creates an array object, which might be overkill.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-12 01:43 +0100 |
| Message-ID | <874mlarysa.fsf@bsb.me.uk> |
| In reply to | #65353 |
Bartc <bc@freeuk.com> writes:
> On 11/07/2015 22:04, Ben Bacarisse wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> A function-like macro often need to return a value based on a
>>>> condition. Since it can't use the return keyword, ? : syntax is
>>>> the only way of making the macro look like a function call.
>>>
>>> It is true that »if« cannot be used in an expression.
>>>
>>> However, if one would really care for macros, it would
>>> be more general to introduce the block return as in:
>>>
>>> double const pi ={ double x = atan( 1 ); x *= 4; return x; };
>>
>> As you may know, one of C's grandparents (BCPL) had this construct.
>> Function bodies where just expressions, many of which where blocks that
>> returned. And Algol 68 (another ancestor) made little distinction
>> between what C calls expressions and statements. Just as in C a
>> procedure call is a function call whose value you ignore, in Algol 68 an
>> IF clause is just a conditional expression whose value you ignore.
>>
>> It seems odd to me that this generality of design should have been
>> thrown away. Why can't I declare a variable in the condition of an if?
>> Why can't I initialise a variable with the result of a calculation that
>> involves, for example, a while loop? These features would probably be
>> used rarely, but omitting them complicates the language, at least from
>> an intellectual point of view.
>
> The private language I was using until a few years worked ago just
> that way. It was inspired by Algol-68 in syntax and also in the way
> that statements and expression were interchangeable.
>
> But when I decided it should use (high level) C as a target, that
> caused problems, because C didn't work like that. So the language was
> simplified to make statements and expressions separate.
Seems wrong to me.
<snip>
> That reminds me - I still have the construct (n|a,b,c,...|z) to select
> the nth value from a list, but I haven't managed to express that in C
> yet.
(T []){z, a, b, c, ...}[(n <= k) * n]
but that assumes you evaluate all the expressions and that that can all
be converted to a single type. (k is the number of non-default options
and the indexing from 1 as I think it was in Algol 68.)
> I might have to use that gcc extension after all as it calls for
> a switch statement inside an expression.)
I can see how if you want to find literal translations, your target
language will influence the original. That does seem like a good plan.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-12 10:31 +0100 |
| Message-ID | <mntc2c$664$1@dont-email.me> |
| In reply to | #65382 |
On 12/07/2015 01:43, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> That reminds me - I still have the construct (n|a,b,c,...|z) to select
>> the nth value from a list, but I haven't managed to express that in C
>> yet.
>
> (T []){z, a, b, c, ...}[(n <= k) * n]
>
> but that assumes you evaluate all the expressions and that that can all
> be converted to a single type.
Yes, that will work if the options are constants. But then it could also
set up a static array and index into that, guarded by a ?: test on the
index. (Then I can also be sure it doesn't repeatedly evaluate the list
even when the elements are constants. And it would work with more C
compilers.)
But in the general case, evaluating one and only one option is key. That
is how a?b:c works: only b or c is evaluated.
This code:
print (n|printf("A"), printf("AB"), printf("ABC")|printf("ZZZZ"))
displays "AB2" when n is 2. But if I try it in C:
int x,n=2;
x=(int[]){printf("ZZZZ"),
printf("A"),
printf("AB"),
printf("ABC")}[(n<=3)*n];
printf("%d",x);
it produces "ZZZZAABABC2". Although I was impressed that it worked at all!
(I suppose another way to do it is as a nested sequence of ?: terms.
This won't be efficient when there are lots of terms, and the index
expression will be evaluated more than once, but it will at least do the
job.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-12 16:12 +0100 |
| Message-ID | <mnu02b$83t$1@dont-email.me> |
| In reply to | #65395 |
On 12/07/2015 10:31, Bartc wrote:
> On 12/07/2015 01:43, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> That reminds me - I still have the construct (n|a,b,c,...|z) to select
>>> the nth value from a list, but I haven't managed to express that in C
>>> yet.
>>
>> (T []){z, a, b, c, ...}[(n <= k) * n]
>>
>> but that assumes you evaluate all the expressions and that that can all
>> be converted to a single type.
> (I suppose another way to do it is as a nested sequence of ?: terms.
> This won't be efficient when there are lots of terms, and the index
> expression will be evaluated more than once, but it will at least do the
> job.)
That latter approach seemed to work. Input of:
x:=(n|a,b,c,d,e|z)
produces this C version:
x=(n==1?a:(n==2?b:(n==3?c:(n==4?d:(n==5?e:z)))));
while complex indices are copied to a temporary which then becomes the
index. This code based on my earlier example:
print (++n|printf("A"),printf("AB"),printf("ABC")|printf("ZZZZ"))
outputs the correct "ABC3" when n starts at 2, when the C equivalent is run.
It's a nice little construct. A shame it doesn't exist in C and you
can't really write anything similar without so much clutter that it
destroys the expressiveness. (It would definitely never get past Tim!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-12 18:02 +0100 |
| Message-ID | <mnu6gq$vlj$1@dont-email.me> |
| In reply to | #65412 |
On 12/07/2015 16:20, Stefan Ram wrote: > Bartc <bc@freeuk.com> writes: >> x=(n==1?a:(n==2?b:(n==3?c:(n==4?d:(n==5?e:z))))); > > x = n == 1 ? a: > n == 2 ? b: > n == 3 ? c: > n == 4 ? d: > n == 5 ? e: > z; What's this in response too, to the above format, or as an alternative to the original non-C construct? (The above is machine-generated and, while statements are line-oriented with properly indented blocks, expressions are just strings within a line. Formatting a complex expression across multiple lines is difficult to do automatically.) Your version is reasonable when the example is just an isolated (n|a,b,c,d,e|z), but it can be just be part of a more complicated expression; try: (m | p.x, p.y | p.z) * (n | q.x, q.y | q.z) It can also be an l-value, which in C has to be written differently from an r-value when ?: is involved, with extra * and & operators. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-07-12 11:16 -0700 |
| Message-ID | <MPG.300c4ed3456cbe7e4f@news.eternal-september.org> |
| In reply to | #65423 |
Bartc wrote: > Stefan Ram wrote: > > Bartc writes: > >> x=(n==1?a:(n==2?b:(n==3?c:(n==4?d:(n==5?e:z))))); > > > > x = n == 1 ? a: > > n == 2 ? b: > > n == 3 ? c: > > n == 4 ? d: > > n == 5 ? e: > > z; > > What's this in response too, to the above format, or as an alternative > to the original non-C construct? It was clearly a counter to your statement "A shame [that in C] you can't really write anything similar without so much clutter that it destroys the expressiveness."
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-12 21:06 +0100 |
| Message-ID | <mnuh8t$86m$1@dont-email.me> |
| In reply to | #65434 |
On 12/07/2015 19:16, Philip Lantz wrote:
> Bartc wrote:
>> Stefan Ram wrote:
>>> Bartc writes:
>>>> x=(n==1?a:(n==2?b:(n==3?c:(n==4?d:(n==5?e:z)))));
>>>
>>> x = n == 1 ? a:
>>> n == 2 ? b:
>>> n == 3 ? c:
>>> n == 4 ? d:
>>> n == 5 ? e:
>>> z;
>>
>> What's this in response too, to the above format, or as an alternative
>> to the original non-C construct?
>
> It was clearly a counter to your statement "A shame [that in C] you
> can't really write anything similar without so much clutter that it
> destroys the expressiveness."
OK, in that case my response is that:
(1) The selector expression has to be repeated (it might not be a simple
term).
(2) The indices have to be stated explicitly (although this also gives
extra flexibility and extra information).
(3) It now sprawls across several lines, which may not sit well with the
rest of the expression when the latter is more elaborate.
(4) It gives the impression that the tests have to be performed in order
(and they probably are), but in the original form, the selected
expression is accessed directly. (The ?: chain is what I've chosen to
implement it in C.)
(5) As I mentioned, there's slightly more clutter when this is an l-value:
*(n == 1 ? &a:
n == 2 ? &b:
n == 3 ? &c:
n == 4 ? &d:
n == 5 ? &e:
&z) = x;
Apart from all that, it's pretty much identical to the non-C version...
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 15:44 -0700 |
| Message-ID | <kfn8uamuxeu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65262 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 10:50:46 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >>> The ?: syntax was really introduced to make macros easier to write, >> >> Do you have any evidence for that odd claim? All of the >> often-cited influences on C (BCPL (and hence CPL), B and Algol 68) >> had such an operator and none had macros. The C reference manual >> uses ?: but not in a macro. The evidence (such as it is) points to >> it's being introduced because it's useful (as indeed it is). > > I might be wrong about that. > A function-like macro often need to return a value based on a > condition. Since it can't use the return keyword, ? : syntax is > the only way of making the macro look like a function call. >> >>> but it can be more readable, in relatively advanced code that's >>> gone beyond the teaching language stage and has long functions >>> with lots of trivial jumps. >> >> I don't consider an expression whose value depends on a condition >> to be either advanced or "beyond teaching the language". It's a >> natural expression form that occurs in mathematics and predates >> programming by a long chalk. > > It's a functional programming construct. [snip] Your education is lacking. Conditional expression constructs have been present in procedural programming languages since, well, probably before you were born. Even before BASIC.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-11 16:15 -0700 |
| Message-ID | <a5bd418b-8515-4a94-9b14-5a2598f85b93@googlegroups.com> |
| In reply to | #65356 |
On Saturday, July 11, 2015 at 11:44:52 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's a functional programming construct. [snip] > > Your education is lacking. Conditional expression constructs > have been present in procedural programming languages since, > well, probably before you were born. Even before BASIC. > I had thought it was added to C primarily to support function- like macros. But it appears I was wrong about that. It is a little bit of functional programming in a primarily procedural language, however. As such, it should be used sparingly. (Like function calls, no-one is going to argue for no function calls at all, but generally the function call shod be the only thing on the line. Early functions like strcpy returned their arguments so you could chain calls together, but this is an extremely bad idea in C. )
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 13:50 -0700 |
| Message-ID | <kfn615lqh5a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65364 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, July 11, 2015 at 11:44:52 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> It's a functional programming construct. [snip] >> >> Your education is lacking. Conditional expression constructs >> have been present in procedural programming languages since, >> well, probably before you were born. Even before BASIC. > > I had thought it was added to C primarily to support function- > like macros. But it appears I was wrong about that. > It is a little bit of functional programming in a primarily > procedural language, however. As such, it should be used > sparingly. [snip] I understand that is your viewpoint. However I believe that view stems more from an educational bias on your part rather than any essential underlying truth.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-11 20:13 +0000 |
| Message-ID | <mnrtd0$fqs$1@speranza.aioe.org> |
| In reply to | #65212 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, July 11, 2015 at 1:29:25 AM UTC+1, Stefan Ram wrote: >> When I teach »if« after having taught »?:«, I want >> to show something that can be done much better with >> »if« than with »?:«, something where »if« really shines! > That's a weird strategy. > Most programming languages have an if. It's completely intuitive. > If some condition holds, do something. > The ?: syntax was really introduced to make macros easier to write, > but it can be more readable, in relatively advanced code that's > gone beyond the teaching language stage and has long functions with > lots of trivial jumps. ALGOL allows IF in expressions, in the same way as C's ?:. X := IF A=B THEN Y ELSE Z; (I think that is right, but didn't check it.) The verilog hardware description language uses the C ?: for the logic of a hardware multiplexer. assign x=(a==b)? y : z; VHDL uses: x <= y when a=b else z; I like the C and verilog form better. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-11 23:01 +0100 |
| Message-ID | <874mlatktk.fsf@bsb.me.uk> |
| In reply to | #65330 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: <snip> > ALGOL allows IF in expressions, in the same way as C's ?:. What's ALGOL? There are dozens of languages with Algol in the name, and two very different ones that are widely know standards, but I don't know any called simply ALGOL. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web