Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172354 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2023-08-16 00:31 -0700 |
| Last post | 2023-08-17 03:42 -0700 |
| Articles | 20 on this page of 287 — 19 participants |
Back to article view | Back to comp.lang.c
C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 00:31 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-16 11:14 +0100
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 00:23 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 21:38 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 12:19 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-17 07:53 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 00:15 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-18 16:33 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:46 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-19 03:04 -0700
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 13:19 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 14:48 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 15:09 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 15:17 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:05 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:05 +0100
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:07 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 22:31 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-19 22:04 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-20 07:41 -0400
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 17:00 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 11:20 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-20 14:45 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 00:05 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 19:45 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 14:51 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-21 11:28 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 02:59 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-21 15:17 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 23:03 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 14:09 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 05:38 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 15:31 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 06:51 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 19:19 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 21:59 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 09:57 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 07:48 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-23 16:05 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 08:21 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 19:30 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 18:50 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 10:49 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 18:08 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 21:28 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 20:53 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-24 15:15 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-24 07:50 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-24 16:48 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 17:35 +0000
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 18:09 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 09:59 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 09:46 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 01:37 -0700
Re: C vs Haskell for XML parsing Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 08:50 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 01:53 -0700
Underscores in type names (was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 09:17 +0000
Re: Underscores in type names (was : C vs Haskell for XML parsing) Richard Harnden <richard.nospam@gmail.com> - 2023-08-25 11:35 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 13:42 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:59 +0000
Re: C vs Haskell for XML parsing candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-26 00:45 +1300
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 19:50 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 02:55 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:21 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 03:05 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:28 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:01 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:07 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 09:16 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:22 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-29 19:38 +0000
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 20:11 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 21:59 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-30 00:43 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:30 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-30 05:04 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 17:50 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 19:41 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-31 11:18 +0200
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-30 14:40 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-30 15:03 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 12:00 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 20:50 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 08:12 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:51 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 00:55 +0100
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:17 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 04:31 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 14:06 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-25 15:35 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 11:45 -0700
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-25 20:06 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 19:35 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 19:55 -0700
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:26 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:24 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 02:52 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-26 14:10 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 22:54 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:39 +0200
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-27 15:56 -0400
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 00:42 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 10:39 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 02:03 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 13:29 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 16:35 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 10:11 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 19:40 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 12:31 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 22:39 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 14:22 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:02 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 16:21 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 10:05 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:50 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:50 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:13 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:31 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 23:08 -0700
Re: C vs Haskell for XML parsing "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 23:23 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:41 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 13:38 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 11:59 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 19:34 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 17:12 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-26 01:44 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 22:18 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 19:58 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 23:07 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 21:17 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 10:12 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 15:13 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 19:47 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 19:09 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 22:27 -0400
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:55 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 02:16 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 18:39 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 22:26 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 11:07 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 10:33 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 16:27 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 11:57 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 17:11 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 12:35 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 18:24 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 13:35 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 20:11 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 17:07 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 22:40 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 23:32 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 03:02 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 13:25 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 14:37 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-26 19:49 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 22:00 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 17:31 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 15:28 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 04:24 +0000
Re: C vs Haskell for XML parsing "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 21:59 -0700
Re: C vs Haskell for XML parsing candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-27 02:42 +1300
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-27 11:23 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 22:45 +0000
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-27 19:06 -0400
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-28 02:18 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 16:21 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 00:00 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 19:36 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 03:00 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:58 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 15:22 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:49 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 17:11 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:06 +0200
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 08:27 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 01:36 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 01:22 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 10:40 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-29 02:53 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 03:00 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:18 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:06 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 22:14 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 01:32 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 21:09 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:44 +0200
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-30 12:32 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 11:44 -0700
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:15 -0400
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-31 04:47 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 11:42 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 23:36 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 08:15 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:48 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 03:55 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:44 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 16:20 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 16:47 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-09-03 17:24 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 03:16 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:26 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 03:19 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:43 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:23 -0700
Re: C vs Haskell for XML parsing Bobby Moore <bobbymoore018@gmail.com> - 2023-08-29 13:54 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 11:41 +0200
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 08:29 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 16:54 +0100
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-30 19:30 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 19:53 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-30 20:07 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 20:42 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Richard Harnden <richard.nospam@gmail.com> - 2023-08-30 23:15 +0100
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-31 18:41 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) David Brown <david.brown@hesbynett.no> - 2023-08-31 12:43 +0200
Re: Named function arguments (Was : C vs Haskell for XML parsing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 20:40 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:15 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 15:53 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 18:41 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 18:01 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 20:01 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 20:14 +0100
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 19:27 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:09 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 21:53 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 20:37 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 23:39 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 00:23 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-29 01:01 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:28 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 11:08 +0100
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 01:31 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:18 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:50 +0200
Re: C vs Haskell for XML parsing Richard Harnden <richard.nospam@gmail.com> - 2023-08-27 19:18 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 21:19 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-27 20:33 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 14:14 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 13:56 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:00 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 15:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:32 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:50 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 23:38 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-26 14:09 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 00:44 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 00:18 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 17:56 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 19:20 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 11:18 -0700
Re: C vs Haskell for XML parsing kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-27 18:34 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 00:32 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:14 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:10 +0000
Re: C vs Haskell for XML parsing kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-29 10:47 +0000
Re: C vs Haskell for XML parsing Michael S <already5chosen@yahoo.com> - 2023-08-29 04:53 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 06:35 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 08:24 +0200
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 22:17 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 14:35 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:38 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 01:00 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:24 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 03:29 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 14:01 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 08:40 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 19:11 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-25 14:49 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 19:59 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 18:31 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:03 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-23 14:54 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:57 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-22 14:10 +0100
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 13:46 +0100
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:32 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:47 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 00:37 +0000
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:40 -0700
Re: C vs Haskell for XML parsing Michael S <already5chosen@yahoo.com> - 2023-08-17 02:37 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 13:50 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 00:07 +0100
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:25 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-17 03:32 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-17 03:42 -0700
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-28 15:12 -0700 |
| Message-ID | <87pm36byty.fsf@nosuchdomain.example.com> |
| In reply to | #172958 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/08/2023 22:56, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> And if one translation unit defined "void foo(int a, int b);", while
>>> another declared "void foo(int b, int a);" and used that with named
>>> parameters, you would not get the correct call.
>> True. So don't do that.
>
> That would boil down to undiagnosable undefined behaviour - and I'd
> rather avoid that. If there was a way to enforce checking here, it
> would be significantly better (IMHO). To me, avoiding mistakes is the
> most important justification for named parameters.
An implementation could warn about it, assuming it keep information
about parameter names in separately compiled translation units.
But we're talking about defining a function in one file, and then
writing an inconsistent declaration for that function in another file.
It's already easy to get undefined behavior that way -- and easy to
avoid it, by putting function declarations in headers that are included
by all source files that define or call the function.
> Since we can't do anything about currently legal declarations and
> definitions with different (or missing) parameter names, I think we
> want a new or modified syntax for the declaration and definition of
> functions that can use named parameters.
We can do something about current declarations and definitions. We can
define the behavior, and specify the few cases where the behavior is
undefined. If there are no parameter names in the visible declaration,
you can't use named arguments. If there are multiple compatible
declarations with differing parameter names (which is confusing and
easily avoidable), use the last one.
> I think that with this new
> type of declaration, the rules should be that a function should either
> be "static" and have at most one forward declaration, or non-static
> and have exactly one "extern" declaration in scope before it, and that
> the parameter names and styles (such as pointers or array parameter)
> match exactly. This would not force programmers to have declarations
> in a single header that is included by both the defining TU and TU's
> that use the function, but it would strongly encourage it. And it
> would make it a lot harder to get wrong.
How much harder does it have to be? A declaration that swaps the
parameter names would almost have to be deliberate, perhaps something
for the IOCCC.
> Since this would conflict with existing styles used in some code, I
> think we'd need a new syntax (or a new function attribute or
> qualifier). It's possible that compilers could have a flag to apply
> such checks by default (gcc has "-Wmissing-declarations
> -Wredundant-declarations", but no check on parameter names AFAIK), but
> that would be an implementation option, useful to some people and not
> others.
I don't think any of that is necessary, and I think it would make the
new feature more complicated, likely to the point that it would be
rejected.
Keep it simple. Parameters have names. For historical reasons, you can
redeclare a function with different parameter names, but it's a bad idea
unless you're doing it very carefully for the purpose of improving code
clarity.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-29 16:32 +0200 |
| Message-ID | <uckvi2$29oe0$2@dont-email.me> |
| In reply to | #173095 |
On 29/08/2023 00:12, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 27/08/2023 22:56, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: > [...] >>>> And if one translation unit defined "void foo(int a, int b);", while >>>> another declared "void foo(int b, int a);" and used that with named >>>> parameters, you would not get the correct call. >>> True. So don't do that. >> >> That would boil down to undiagnosable undefined behaviour - and I'd >> rather avoid that. If there was a way to enforce checking here, it >> would be significantly better (IMHO). To me, avoiding mistakes is the >> most important justification for named parameters. > > An implementation could warn about it, assuming it keep information > about parameter names in separately compiled translation units. > > But we're talking about defining a function in one file, and then > writing an inconsistent declaration for that function in another file. > It's already easy to get undefined behavior that way -- and easy to > avoid it, by putting function declarations in headers that are included > by all source files that define or call the function. Yes, that is entirely true. But rather than adding new ways to get inconsistent or undefined behaviour, I would prefer taking the opportunity to make it harder to get inconsistent or undefined behaviour here. We can't force people to write good code, or to stop writing bad code - but we /can/ encourage it. I've had to maintain code where the program works in all its testing, despite having functions defined in one file and then declared (and used) in a different file with a different number or type of parameters. It was not fun trying to make sense of the mess, and turn it into something that worked by design instead of luck! So if there's a chance to help avoid that when (hypothetically) adding a new feature to C, I'd prefer to put quite a bit of effort in that direction. (There are perhaps better ways to achieve this than my suggestion.) > >> Since we can't do anything about currently legal declarations and >> definitions with different (or missing) parameter names, I think we >> want a new or modified syntax for the declaration and definition of >> functions that can use named parameters. > > We can do something about current declarations and definitions. We can > define the behavior, and specify the few cases where the behavior is > undefined. If there are no parameter names in the visible declaration, > you can't use named arguments. If there are multiple compatible > declarations with differing parameter names (which is confusing and > easily avoidable), use the last one. > >> I think that with this new >> type of declaration, the rules should be that a function should either >> be "static" and have at most one forward declaration, or non-static >> and have exactly one "extern" declaration in scope before it, and that >> the parameter names and styles (such as pointers or array parameter) >> match exactly. This would not force programmers to have declarations >> in a single header that is included by both the defining TU and TU's >> that use the function, but it would strongly encourage it. And it >> would make it a lot harder to get wrong. > > How much harder does it have to be? A declaration that swaps the > parameter names would almost have to be deliberate, perhaps something > for the IOCCC. Maybe you've been lucky about the code you've had to deal with! But I suppose the kind of programmer who gets these things wrong today, is unlikely to use the new features. And even if they did, they'd just invent some new ways to make a disaster out of their code. > >> Since this would conflict with existing styles used in some code, I >> think we'd need a new syntax (or a new function attribute or >> qualifier). It's possible that compilers could have a flag to apply >> such checks by default (gcc has "-Wmissing-declarations >> -Wredundant-declarations", but no check on parameter names AFAIK), but >> that would be an implementation option, useful to some people and not >> others. > > I don't think any of that is necessary, and I think it would make the > new feature more complicated, likely to the point that it would be > rejected. > > Keep it simple. Parameters have names. For historical reasons, you can > redeclare a function with different parameter names, but it's a bad idea > unless you're doing it very carefully for the purpose of improving code > clarity. > Certainly if simple support for named parameters were added to C, I'd make use of it. And I'm sure gcc would add warnings to check for name consistency, and I'm sure I'd use those warnings too :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-29 13:12 -0700 |
| Message-ID | <871qflbob8.fsf@nosuchdomain.example.com> |
| In reply to | #173196 |
David Brown <david.brown@hesbynett.no> writes:
> On 29/08/2023 00:12, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 27/08/2023 22:56, Keith Thompson wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>>>> And if one translation unit defined "void foo(int a, int b);", while
>>>>> another declared "void foo(int b, int a);" and used that with named
>>>>> parameters, you would not get the correct call.
>>>> True. So don't do that.
>>>
>>> That would boil down to undiagnosable undefined behaviour - and I'd
>>> rather avoid that. If there was a way to enforce checking here, it
>>> would be significantly better (IMHO). To me, avoiding mistakes is the
>>> most important justification for named parameters.
>> An implementation could warn about it, assuming it keep information
>> about parameter names in separately compiled translation units.
>> But we're talking about defining a function in one file, and then
>> writing an inconsistent declaration for that function in another file.
>> It's already easy to get undefined behavior that way -- and easy to
>> avoid it, by putting function declarations in headers that are included
>> by all source files that define or call the function.
>
> Yes, that is entirely true.
>
> But rather than adding new ways to get inconsistent or undefined
> behaviour, I would prefer taking the opportunity to make it harder to
> get inconsistent or undefined behaviour here. We can't force people
> to write good code, or to stop writing bad code - but we /can/
> encourage it.
Not if the additional changes intended to make the feature harder to
abuse make it harder to use (and harder to explain).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-30 12:50 +0200 |
| Message-ID | <ucn6t5$2n2kb$2@dont-email.me> |
| In reply to | #173217 |
On 29/08/2023 22:12, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> But rather than adding new ways to get inconsistent or undefined >> behaviour, I would prefer taking the opportunity to make it harder to >> get inconsistent or undefined behaviour here. We can't force people >> to write good code, or to stop writing bad code - but we /can/ >> encourage it. > > Not if the additional changes intended to make the feature harder to > abuse make it harder to use (and harder to explain). > Agreed. There are always balances and trade-offs involved. I do not claim to know an "ideal" solution here (especially since "ideal" will vary wildly for different people). But I think it should be an important part of the discussion and consideration before implementing such new features. In the end, I would expect to see the rules being looser than I personally would prefer, and hope to see compilers provide warnings or other flags to let people enforce tighter rules if they want.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 23:38 -0700 |
| Message-ID | <efcf98fa-f078-490c-99fa-5c281cadcebbn@googlegroups.com> |
| In reply to | #172757 |
On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
>
> Ritchie didn't use long identifiers much - and when he did, he used
> underscores.
>
Here's some code by K and R. Either by Ritchie or agreed to by Ritchie.
#include <stdio.h>
#define MAXLINE 1000 /* maximum input line length */
int getline(char line[], int max)
int strindex(char source[], char searchfor[]);
char pattern[] = "ould"; /* pattern to search for */
/* find all lines matching pattern */
main()
{
char line[MAXLINE];
int found = 0;
while (getline(line, MAXLINE) > 0)
if (strindex(line, pattern) >= 0) {
printf("%s", line);
found++;
}
return found;
}
/* getline: get line into s, return length */
int getline(char s[], int lim)
{
int c, i;
i = 0;
while (--lim > 0 && (c=getchar()) != EOF && c != '\n')
s[i++] = c;
if (c == '\n')
s[i++] = c;
s[i] = '\0';
return i;
}
/* strindex: return index of t in s, -1 if none */
int strindex(char s[], char t[])
{
int i, j, k;
for (i = 0; s[i] != '\0'; i++) {
for (j=i, k=0; t[k]!='\0' && s[j]==t[k]; j++, k++)
61
;
if (k > 0 && t[k] == '\0')
return i;
}
return -1;
}
You see quite clearly that the style used is to avoid underscores.
>
> Not that either of these appeals to authority have any relevance.
>
You don't really understand the "authority" fallacy.
Denis Ritchie's opinion that const was a bad idea doesn't make it true that
const was a bad idea. His opinion that Coke is nicer than Pepsi would
however make it true that Coke is nicer than Pepsi, for him.
See the difference?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-26 14:09 +0000 |
| Message-ID | <QInGM.142650$ftCb.73994@fx34.iad> |
| In reply to | #172807 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
>>
>> Ritchie didn't use long identifiers much - and when he did, he used
>> underscores.
>>
>Here's some code by K and R. Either by Ritchie or agreed to by Ritchie.
<elided C code Malcolm attributes to DR>
>
>You see quite clearly that the style used is to avoid underscores.
The old saying, "One Swallow Doesn't make a Summer" applies.
A simple grep of the Unix Version 6 source base shows underscores
in identifiers and structure tags. struct stat is a classic example,
even leaving aside the use of a leading underscore in external symbols.
Perhaps those are all Ken's doing, but your example proves little
about DR's opinions on underscores in identifiers.
if(ip->i_mode & (IFCHR&IFBLK))
ip->i_addr[i] = 0;
ip->i_addr[i] = rcop();
ip->i_mode =& ~ILARG;
ip->i_addr[j] = alloc();
dwrite(ip->i_addr[j], dbuf); else
ip->i_addr[j] = alloc();
dwrite(ip->i_addr[j], dbuf); else
dwrite(ip->i_addr[7], xbuf);
ip->i_mode =| ILARG;
for(i=0; i<sblock.s_isize;-)
i = --sblock.s_nfree;
b = sblock.s_free[i];
if(sblock.s_nfree <= 0) {
sblock.s_nfree = cbuf[0];
sblock.s_free[i] = cbuf[i+1];
if(sblock.s_nfree >= 100) {
cbuf[0] = sblock.s_nfree;
cbuf[i+1] = sblock.s_free[i];
sblock.s_nfree = 0;
sblock.s_free[sblock.s_nfree++] = in;
setup(&nl[0], "_proc");
setup(&nl[1], "_swapdev");
# define b_sp_max 1500
int b_space [ b_sp_max ];
int * b_sp_nxt { b_space };
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-27 00:44 +0100 |
| Message-ID | <873505pdw0.fsf@bsb.me.uk> |
| In reply to | #172807 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote: >> Not that either of these appeals to authority have any relevance. >> > You don't really understand the "authority" fallacy. > Denis Ritchie's opinion that const was a bad idea doesn't make it true that > const was a bad idea. His opinion that Coke is nicer than Pepsi would > however make it true that Coke is nicer than Pepsi, for him. So you cited DMR, the designer of the C language, simply as an example of one person with a preference to avoid underscores in C identifiers? It could have been Kevin from accounts or Barbara finance as neither uses underscores in their C programs? In no way did you want to imply that Ritchie's opinion as a highly respected programmer and the designer of the language in question might carry greater weight (i.e. authority) on this topic? Kevin, Barbara and DMR are all equally authoritative on the matter of their own preferences. I find that hard to believe, but if you /didn't/ intend an appeal to his (often presumed) authority, then it was a very poor choice. As it happens, I am not with David on this. There are many matters on which I think an appeal to authority carries significant weight. I don't know DMR's opinion of underscores (the code in K&R is indicative but not exactly conclusive), but I would take more time considering it than I would Kevin's or Barbara's. It's just one way to simplify life. But maybe you cited DMR simply because could not find any other examples. I looked at your BBXRC code (I know it's not all yours) and I found lots of identifiers with underscores: only_saw_ascii_range le_control_chars be_control_chars null_suggests_binary_ unexpected_null_threshold even_null_threshold TEXTENC_UTF8_BOM TEXTENC_ANSI utf16_unexpected_null_percent_ lodepng_decode32_file error_exit out_of_memory opt_get and so on. Are they your choices or someone else's? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-27 00:18 -0700 |
| Message-ID | <dd23e702-21e4-4aa3-ba21-613a6f1e4456n@googlegroups.com> |
| In reply to | #172840 |
On Sunday, 27 August 2023 at 00:45:02 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote: > >> Not that either of these appeals to authority have any relevance. > >> > > You don't really understand the "authority" fallacy. > > Denis Ritchie's opinion that const was a bad idea doesn't make it true that > > const was a bad idea. His opinion that Coke is nicer than Pepsi would > > however make it true that Coke is nicer than Pepsi, for him. > > So you cited DMR, the designer of the C language, simply as an example > of one person with a preference to avoid underscores in C identifiers? > > DB >> The only thing /wrong/ - and pretty much everyone thinks it is wrong - >> would be to call it "multiplymatrixwithvector". >> Malcolm >Well Caesar disagreed. >Denis Ritchie disagreed. >Unfortunately I can't find it, but some reasearch on human-readable urls disagreed. >Whilst all you can offer is "I disagree". But you automatically disagree with things > some people say. So how much weight should we give to that? > Whist it is ultimately about something objective, because it's an objective statement about human psychology, then "what everybody thinks" isn't a fallacy in the same way that it would be if it were a claim about, for example, psychology. Exceptions to David Brown's claim include Caesar, who would have written without spaces, Denis Ritchie, who chose "isdigit" over is_digit, the url reasearchers I can't dig out but I specifically remember the conclusion that hyphens made it easier for computers to parse urls, but made it harder for humans, > > It could have been Kevin from accounts or Barbara finance as neither > uses underscores in their C programs? In no way did you want to imply > that Ritchie's opinion as a highly respected programmer and the designer > of the language in question might carry greater weight (i.e. authority) > on this topic? Kevin, Barbara and DMR are all equally authoritative on > the matter of their own preferences. I find that hard to believe, but > if you /didn't/ intend an appeal to his (often presumed) authority, then > it was a very poor choice. > Its also a case that since Ritchie chose identifiers without underscores, then that style continues, because his idnefiers are commonly seen in C source. (The point David Brown only half understood). But of course, yes, one of the reasons C was successful was that Ritchie was careful in his choice of names. I do believe that people who came after have uglified things, and done great damage to the language. > > As it happens, I am not with David on this. There are many matters on > which I think an appeal to authority carries significant weight. I > don't know DMR's opinion of underscores (the code in K&R is indicative > but not exactly conclusive), but I would take more time considering it > than I would Kevin's or Barbara's. It's just one way to simplify life. > > But maybe you cited DMR simply because could not find any other > examples. I looked at your BBXRC code (I know it's not all yours) and I > found lots of identifiers with underscores: > > only_saw_ascii_range > le_control_chars > be_control_chars > null_suggests_binary_ > unexpected_null_threshold > even_null_threshold > TEXTENC_UTF8_BOM > TEXTENC_ANSI > utf16_unexpected_null_percent_ > lodepng_decode32_file > error_exit > out_of_memory > opt_get > > and so on. Are they your choices or someone else's? > Some are my choices, some aren't. BabyXRC is a standalone program which includes code from many sources, (if you go to the webpages I attribute each file to the author). But it's not primarily meant to be an API, so I'm not as careful in choices of interfaces as with Baby X. Baby X is const free, and uses the prefix bbx_ on all user-callable functions, except for "startbabyx", and the prefix BBX_ for non-function-like macros and opaque pointers. There's then a name in lower case, without underscores, for functions, whilst non- functions are in all-caps. Whilst it's not perfectly consistent (the UTF-8 functions take const char *s, for example) it's pretty consistent, and it's designed with simplicity and ease of use as the top priorty. I use underscores to separate a prefix which isn't part of an English phrase, and for a suffix like "_r" to indicate a recursive function. I do use out_of_memory as a label very frequently. Fair point. Then of course most of the time I don't work on my own projects. I work on code to which other people contribute. And we have a house style, which is driven mainly by the third party API, and capitalises each word. It's better to be consistent.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-27 17:56 +0100 |
| Message-ID | <87cyz8o253.fsf@bsb.me.uk> |
| In reply to | #172867 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> ... I looked at your BBXRC code (I know it's not all yours) and I >> found lots of identifiers with underscores: >> >> only_saw_ascii_range >> le_control_chars >> be_control_chars >> null_suggests_binary_ >> unexpected_null_threshold >> even_null_threshold >> TEXTENC_UTF8_BOM >> TEXTENC_ANSI >> utf16_unexpected_null_percent_ >> lodepng_decode32_file >> error_exit >> out_of_memory >> opt_get >> >> and so on. Are they your choices or someone else's? >> > Some are my choices, some aren't. It's odd (to me) that you chose /any/ since you are so sure they are a bad idea for readability. > Baby X is const free, and uses the prefix bbx_ on all user-callable > functions, You will note I did not pick any with a "bbx_" prefix because you had explained that already. You have quite a collection of prefixes (bbx_, xml_, opt_) as well as some sub-prefixes like utf8_. The result is a fair few underscores. > I use underscores to separate a prefix which isn't part of an English > phrase, and for a suffix like "_r" to indicate a recursive function. Why do you think they help with prefixes and suffixes but not also with words? To me, both are uses are just separating parts. > I do use out_of_memory as a label ... and, it would appear, error_exit and parse_error. In fact I did not see a label without an underscore. > very frequently. Fair point. Despite "knowing" that it's harder to read? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 19:20 +0200 |
| Message-ID | <ucg0lf$18cb9$6@dont-email.me> |
| In reply to | #172840 |
On 27/08/2023 01:44, Ben Bacarisse wrote: > > As it happens, I am not with David on this. There are many matters on > which I think an appeal to authority carries significant weight. I > don't know DMR's opinion of underscores (the code in K&R is indicative > but not exactly conclusive), but I would take more time considering it > than I would Kevin's or Barbara's. It's just one way to simplify life. Ah, now it is /your/ turn to misunderstand the "appeal to authority" fallacy - or at least, to Malcolm's use of it or my objection to his use. It's fine to "appeal to authority" as supporting evidence for a claim, and it is absolutely appropriate to view DMR's opinion on C style in higher standing than Kevin's or Barbara's. But it is fallacious to think of DMR's opinion as being proof that Malcolm's theories are correct - at best, they could be supporting evidence. (Even experts are wrong sometimes.) It is fallacious to appeal to DMR's authority when his coding and writing don't actually support Malcolm's ideas at all. It is fallacious to cherry-pick bits of code that appear to support it, rather than looking at a wider selection of his code. It is fallacious to consider his code written in different circumstances than code written now (his tools had very limited lengths of significant characters in identifiers). There's nothing wrong with using expert or authority opinion to bolster an argument, when it is not fallacious.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-27 11:18 -0700 |
| Message-ID | <ed2e87a5-7930-41c4-b29c-2d91227ea50cn@googlegroups.com> |
| In reply to | #172889 |
On Sunday, 27 August 2023 at 18:21:00 UTC+1, David Brown wrote: > On 27/08/2023 01:44, Ben Bacarisse wrote: > > > > As it happens, I am not with David on this. There are many matters on > > which I think an appeal to authority carries significant weight. I > > don't know DMR's opinion of underscores (the code in K&R is indicative > > but not exactly conclusive), but I would take more time considering it > > than I would Kevin's or Barbara's. It's just one way to simplify life. > Ah, now it is /your/ turn to misunderstand the "appeal to authority" > fallacy - or at least, to Malcolm's use of it or my objection to his use. > > It's fine to "appeal to authority" as supporting evidence for a claim, > and it is absolutely appropriate to view DMR's opinion on C style in > higher standing than Kevin's or Barbara's. > > But it is fallacious to think of DMR's opinion as being proof that > Malcolm's theories are correct - at best, they could be supporting > evidence. (Even experts are wrong sometimes.) It is fallacious to > appeal to DMR's authority when his coding and writing don't actually > support Malcolm's ideas at all. It is fallacious to cherry-pick bits of > code that appear to support it, rather than looking at a wider selection > of his code. It is fallacious to consider his code written in different > circumstances than code written now (his tools had very limited lengths > of significant characters in identifiers). > > There's nothing wrong with using expert or authority opinion to bolster > an argument, when it is not fallacious. > No. Denis Ritchie didn't like const. But to say "const is a bad idea because Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie almost certainly knows what he is talking about, and obvioulsy the committee has shown their inferiority inm many other ways. But you have to look at the arguments Ritchie used, not just say "Ritchie says so, so it is". However identifers are a. bit different. Ritchie was no expert on Colas. But, as I said, if he said "Coke is nicer than Pepsi" then that makes it true that Coke is nicer than Pepsi, for him. And it is a counter-example to the claim that everyone prefers Pepsi. Ritchie used identifiers without spaces to separate the words. So that disproves the claim that everyone agree that this style is wrong. And of course because he is a familiar and well respected figure, he's a good counterexampe to choose. But I also gave Caesar as a counter-example, and of course no-one would say that Caesar was an authority on C. But Ceasar is someone everyone would have heard of. God also gave His Torah to the Jewish people, without spaces. So on my side, Caesar, Denis Ritchie, and God. That's clearly no "no-one". Whilst had I offered Kevin and Barbara from the office I could be accused of trawling through a vast bank of people to cherry pick But the actual argument from Denis Ritchie was a bit different.. Calls to the standard library are very common in C code. And Ritchie chose the names of the standard library functions. So, since he agreed with my style, where a standard library function consists of two English words, they are not separated by an underscore. Now consistency is important, and Denis Ritchie, as the author of C, set the C "house style".
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-08-27 18:34 +0000 |
| Message-ID | <ucg4uo$19fkm$1@dont-email.me> |
| In reply to | #172891 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > No. Denis Ritchie didn't like const. But to say "const is a bad idea because > Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie > almost certainly knows what he is talking about, and obvioulsy the committee > has shown their inferiority inm many other ways. But you have to look at the > arguments Ritchie used, not just say "Ritchie says so, so it is". I am sorry, I am a bit lazy today and cannot be bothered to do web searches. What exactly are Ritchie's arguments against "const"? I cannot think of any, but I have heard some that lend support to having, and properly using, "const". br, KK
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-28 00:32 -0700 |
| Message-ID | <dee77a79-b9c6-4528-b563-91e7491505cbn@googlegroups.com> |
| In reply to | #172892 |
On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote: > Malcolm McLean <malcolm.ar...@gmail.com> wrote: > > No. Denis Ritchie didn't like const. But to say "const is a bad idea because > > Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie > > almost certainly knows what he is talking about, and obvioulsy the committee > > has shown their inferiority inm many other ways. But you have to look at the > > arguments Ritchie used, not just say "Ritchie says so, so it is". > I am sorry, I am a bit lazy today and cannot be bothered to do web > searches. What exactly are Ritchie's arguments against "const"? > > I cannot think of any, but I have heard some that lend support > to having, and properly using, "const". > He write them in a leter tot he committee many years ago. I believe there was also apost to this newsgroup. His main focus of ire was "no alias", but he also criticised const. [Ritchie] Let me begin by saying that I’m not convinced that even the pre-December qualifiers (`const’ and `volatile’) carry their weight; I suspect that what they add to the cost of learning and using the language is not repaid in greater expressiveness. `Const’ is simultaneously more useful and more obtrusive; you can’t avoid learning about it, because of its presence in the library interface. Nevertheless, I don’t argue for the extirpation of qualifiers, if only because it is too late. ... 1. The qualifiers create an inconsistent language A substantial fraction of the library cannot be expressed in the proposed language. One of the simplest routines, char *strchr(const noalias char *s, int c); can return its first parameter. This first parameter must be declared with `const noalias;’ otherwise, it would be illegal (by the constraints on assignment, 3.3.16.1) to pass the address of a const or noalias object. That is, the type qualifiers in the prototype are not merely an optional pleasantry of the interface; they are required, if one is to pass some kinds of data to this or most other library routines. Unfortunately, there is no way in X3J11’s language for strchr to return the value it promises to, because of the semantics of return (3.6.6.4) and casts (3.3.4). Whether the stripping of the const and noalias qualifiers is done by cast inside strchr, or implicitly by its return statement, strchr returns a pointer that (because of `const’) cannot be stored through, and (because of `noalias’) cannot even be dereferenced; by the rules, it is useless. (Incidentally, I think this observation was made by Tom Plum several years ago; it’s disconcerting that the inconsistency remains.) Although the plain words of the Standard deny it, plastering the appropriate `non-const’ cast on an expression to silence a compiler is sometimes safe, because the most probable implementation of `const’ objects will allow them to be read through any access path, and will diagnose attempts to change them by generating an access violation fault at run time. That is, in common implementations, adding or taking away the `const’ qualifier of a pointer can never create any bugs not implicit in the rule `do not modify a genuine const object through any access path.’ Nevertheless, I must emphasize that this is NOT the rule that X3J11 has written, and that its library is inconsistent with its language. Someone writing an interpreter using X3J11/88-001 is perfectly at liberty to (indeed, is advised to) carry with each pointer a `modifiable’ bit, that (following 3.3.4) remains off when a pointer to a const- qualified object is cast into a plain pointer. This implementation will prevent many of the real uses of strchr, for example. I’m thinking of things like if (p = strchr(q, ‘/’)) *p = ‘ ‘; which are common and innocuous in C, but undefined by X3J11’s language. A related observation is that string literals are not of type `array of const char.’ Indeed, the Rationale (88-004 version) says, `However, string literals do not have [this type], in order to avoid the problems of pointer type checking, particularly with library functions….’ Should this bald statement be considered anything other than an admission that X3J11’s rules are screwy? It is ludicrous that the committee introduces the `const’ qualifier, and also makes strings unwritable, yet is unable to connect the two conceptions. .... compilers will ignore, or only warn about, casts and assignments that X3J11 says are undefined, people will somehow survive 4. What to do? Noalias must go. This is non-negotiable. It must not be reworded, reformulated or reinvented. The draft’s description is badly flawed, but that is not the problem. The concept is wrong from start to finish. It negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) `the spirit of C.’ Const has two virtues: putting things in read-only memory, and expressing interface restrictions. For example, saying char *strchr(const char *s, int c); is a reasonable way of expressing that the routine cannot change the object referred to by its first argument. I think that minor changes in wording preserve the virtues, yet eliminate the contradictions in the current scheme. 1) Reword page 47, lines 3-5 of 3.3.4 (Cast operators), to remove the undefinedness of modifying pointed-to objects, or remove these lines altogether (since casting non-qualified to qualified isn’t discussed explicitly either.) 2) Rewrite the constraint on page 54, lines 14-15, to say that pointers may be assigned without taking qualifiers into account. 3) Preserve all current constraints against modifying non-modifiable lvalues, that is things of manifestlyconst-qualified type. 4) String literals have type `const char []’. 5) Add a constraint (or discussion or example) to assignment that makes clear the illegality of assigning to an object whose actual type is const-qualified, no matter what access path is used. There is a manifest constraint that is easy to check (left side is not const- qualified), but also a non-checkable constraint (left side is not secretly const-qualified). The effect should be that converting between pointers to const- qualified and plain objects is legal and well-defined; avoiding assignment through pointers that derive ultimately from `const’ objects is the programmer’s responsibility. These rules give up a certain amount of checking, but they save the consistency of the language. [Malcolm] I think there's an element of politicing in agreeing to const in the last section. His real object is to get rid of noalias.So he throws the committe a sop. They can have const, with a few provisos.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 11:14 +0200 |
| Message-ID | <uchoii$1kl9e$1@dont-email.me> |
| In reply to | #172952 |
On 28/08/2023 09:32, Malcolm McLean wrote: > On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because >>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie >>> almost certainly knows what he is talking about, and obvioulsy the committee >>> has shown their inferiority inm many other ways. But you have to look at the >>> arguments Ritchie used, not just say "Ritchie says so, so it is". >> I am sorry, I am a bit lazy today and cannot be bothered to do web >> searches. What exactly are Ritchie's arguments against "const"? >> >> I cannot think of any, but I have heard some that lend support >> to having, and properly using, "const". >> > He write them in a leter tot he committee many years ago. > I believe there was also apost to this newsgroup. > > His main focus of ire was "no alias", but he also criticised const. > > [Ritchie] > > Const has two virtues: putting things in read-only memory, and expressing interface restrictions. > For example, saying > > char *strchr(const char *s, int c); > > is a reasonable way of expressing that the routine cannot change the > object referred to by its first argument. > I think that minor changes in wording preserve the virtues, yet > eliminate the contradictions in the current scheme. > > [Malcolm] > I think there's an element of politicing in agreeing to const in the last section. His real > object is to get rid of noalias.So he throws the committe a sop. They can have const, > with a few provisos. It seems very clear to me from that letter that he found the concept of "const" to be good and useful - but it needed some changes to the wording in the standard and details of conversions involving "const". He pointed out the well-known issues with "const" in functions like "strchr" - but that "const" is useful despite being imperfect. I see no indication that he is "throwing the committee a sop" - his dislike of "noalias" is explicitly "non-negotiable", and entirely independent of his other points. Your interpretation of this letter is very strongly coloured by what you wish it said, rather than what he actually wrote.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-28 14:10 +0000 |
| Message-ID | <SV1HM.144950$ftCb.86751@fx34.iad> |
| In reply to | #172960 |
David Brown <david.brown@hesbynett.no> writes: >On 28/08/2023 09:32, Malcolm McLean wrote: >> On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because >>>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie >>>> almost certainly knows what he is talking about, and obvioulsy the committee >>>> has shown their inferiority inm many other ways. But you have to look at the >>>> arguments Ritchie used, not just say "Ritchie says so, so it is". >>> I am sorry, I am a bit lazy today and cannot be bothered to do web >>> searches. What exactly are Ritchie's arguments against "const"? >>> >>> I cannot think of any, but I have heard some that lend support >>> to having, and properly using, "const". >>> >> He write them in a leter tot he committee many years ago. >> I believe there was also apost to this newsgroup. "By way of introduction, the important thing about 'const' is that the current wording says, in section 3.3.4, that a pointer to a const-qualified object may be cast to a pointer to the plain object, but "If an attempt is made to modify the pointed-to object by means of the converted pointer, the behavior is undefined." Because function prototypes tend to convert your pointers to const-qualified pointers, difficulties arise.In discussion with various X3J11 members, I learned that this section is now regarded as an inadvertant error, and no one thinks that it will last in its current form. Nevertheless, it seemed wisest to keep my comments in their original strong form. The intentions of the committee are irrelevant; only their document matters. https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-analysis-in-the-c-programming-language-1988/
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-08-29 10:47 +0000 |
| Message-ID | <uckibm$27j1g$1@dont-email.me> |
| In reply to | #172960 |
David Brown <david.brown@hesbynett.no> wrote: > On 28/08/2023 09:32, Malcolm McLean wrote: >> On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because >>>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie >>>> almost certainly knows what he is talking about, and obvioulsy the committee >>>> has shown their inferiority inm many other ways. But you have to look at the >>>> arguments Ritchie used, not just say "Ritchie says so, so it is". >>> I am sorry, I am a bit lazy today and cannot be bothered to do web >>> searches. What exactly are Ritchie's arguments against "const"? >>> >>> I cannot think of any, but I have heard some that lend support >>> to having, and properly using, "const". >>> >> He write them in a leter tot he committee many years ago. >> I believe there was also apost to this newsgroup. >> >> His main focus of ire was "no alias", but he also criticised const. >> >> [Ritchie] >> >> Const has two virtues: putting things in read-only memory, and expressing interface restrictions. >> For example, saying >> >> char *strchr(const char *s, int c); >> >> is a reasonable way of expressing that the routine cannot change the >> object referred to by its first argument. >> I think that minor changes in wording preserve the virtues, yet >> eliminate the contradictions in the current scheme. >> >> [Malcolm] >> I think there's an element of politicing in agreeing to const in the last section. His real >> object is to get rid of noalias.So he throws the committe a sop. They can have const, >> with a few provisos. > > > It seems very clear to me from that letter that he found the concept of > "const" to be good and useful - but it needed some changes to the > wording in the standard and details of conversions involving "const". > He pointed out the well-known issues with "const" in functions like > "strchr" - but that "const" is useful despite being imperfect. > > I see no indication that he is "throwing the committee a sop" - his > dislike of "noalias" is explicitly "non-negotiable", and entirely > independent of his other points. > > Your interpretation of this letter is very strongly coloured by what you > wish it said, rather than what he actually wrote. Sorry for the long quote. I don't pretend to understand all of Ritchie's arguments, but I agree with David. Ritchie hated "noalias" and wanted it gone: Then it was made so, it was never accepted. He had some deep technical issues with the original "const" specification, but he also saw two virtues in "const". So "const" was modified and accepted. It has been a part of ISO C for a long time. br, KK
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-08-29 04:53 -0700 |
| Message-ID | <dd7ff828-f6b7-46ea-8f31-9a6690d203d4n@googlegroups.com> |
| In reply to | #173185 |
On Tuesday, August 29, 2023 at 1:47:34 PM UTC+3, Kalevi Kolttonen wrote: > David Brown <david...@hesbynett.no> wrote: > > On 28/08/2023 09:32, Malcolm McLean wrote: > >> On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: > >>>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because > >>>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie > >>>> almost certainly knows what he is talking about, and obvioulsy the committee > >>>> has shown their inferiority inm many other ways. But you have to look at the > >>>> arguments Ritchie used, not just say "Ritchie says so, so it is". > >>> I am sorry, I am a bit lazy today and cannot be bothered to do web > >>> searches. What exactly are Ritchie's arguments against "const"? > >>> > >>> I cannot think of any, but I have heard some that lend support > >>> to having, and properly using, "const". > >>> > >> He write them in a leter tot he committee many years ago. > >> I believe there was also apost to this newsgroup. > >> > >> His main focus of ire was "no alias", but he also criticised const. > >> > >> [Ritchie] > >> > >> Const has two virtues: putting things in read-only memory, and expressing interface restrictions. > >> For example, saying > >> > >> char *strchr(const char *s, int c); > >> > >> is a reasonable way of expressing that the routine cannot change the > >> object referred to by its first argument. > >> I think that minor changes in wording preserve the virtues, yet > >> eliminate the contradictions in the current scheme. > >> > >> [Malcolm] > >> I think there's an element of politicing in agreeing to const in the last section. His real > >> object is to get rid of noalias.So he throws the committe a sop. They can have const, > >> with a few provisos. > > > > > > It seems very clear to me from that letter that he found the concept of > > "const" to be good and useful - but it needed some changes to the > > wording in the standard and details of conversions involving "const". > > He pointed out the well-known issues with "const" in functions like > > "strchr" - but that "const" is useful despite being imperfect. > > > > I see no indication that he is "throwing the committee a sop" - his > > dislike of "noalias" is explicitly "non-negotiable", and entirely > > independent of his other points. > > > > Your interpretation of this letter is very strongly coloured by what you > > wish it said, rather than what he actually wrote. > > Sorry for the long quote. I don't pretend to understand all of > Ritchie's arguments, but I agree with David. Ritchie hated "noalias" > and wanted it gone: Then it was made so, it was never accepted. > > He had some deep technical issues with the original "const" > specification, but he also saw two virtues in "const". So "const" > was modified and accepted. It has been a part of ISO C for a long time. > > br, > KK So, when C99 accepted restrict, was it because it was radically better than noalias from C89 draft or just because the committee no longer cared about opinion of DMR?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-29 06:35 -0700 |
| Message-ID | <86o7iqug33.fsf@linuxsc.com> |
| In reply to | #173192 |
Michael S <already5chosen@yahoo.com> writes: > On Tuesday, August 29, 2023 at 1:47:34?PM UTC+3, Kalevi Kolttonen wrote: > >> [...] I don't pretend to understand all of Ritchie's arguments, >> but I [conclude] Ritchie hated "noalias" and wanted it gone: >> Then it was made so, it was never accepted. [...] > > So, when C99 accepted restrict, was it because it was radically > better than noalias from C89 draft or just because the committee > no longer cared about opinion of DMR? My understanding is that "noalias" was poorly defined, and to the extent that it was defined (often?) had program-wide implications that for all practical purposes made it unusable. The "restrict" qualifier added in C99 doesn't have either of these shortcomings. Clearly "restrict" was done with an eye towards addressing the issues raised by Ritchie in his critique of "noalias".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 16:12 -0700 |
| Message-ID | <86a5uawykr.fsf@linuxsc.com> |
| In reply to | #172892 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > >> No. Denis Ritchie didn't like const. But to say "const is a bad >> idea because Denis Ritchie didn't support it" is fallacious, though >> obvioulsy Denis Ritchie almost certainly knows what he is talking >> about, and obvioulsy the committee has shown their inferiority inm >> many other ways. But you have to look at the arguments Ritchie >> used, not just say "Ritchie says so, so it is". > > I am sorry, I am a bit lazy today and cannot be bothered to do web > searches. What exactly are Ritchie's arguments against "const"? > > I cannot think of any, but I have heard some that lend support > to having, and properly using, "const". Current thinking in programming language design tends to favor read-only being the default, with assignable variables needing an explicit indicator. I modestly suggest the keyword "prost" as a type qualifier to mean modifiable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 08:24 +0200 |
| Message-ID | <uchejm$1j7v3$1@dont-email.me> |
| In reply to | #172891 |
On 27/08/2023 20:18, Malcolm McLean wrote: > On Sunday, 27 August 2023 at 18:21:00 UTC+1, David Brown wrote: >> On 27/08/2023 01:44, Ben Bacarisse wrote: >>> >>> As it happens, I am not with David on this. There are many matters on >>> which I think an appeal to authority carries significant weight. I >>> don't know DMR's opinion of underscores (the code in K&R is indicative >>> but not exactly conclusive), but I would take more time considering it >>> than I would Kevin's or Barbara's. It's just one way to simplify life. >> Ah, now it is /your/ turn to misunderstand the "appeal to authority" >> fallacy - or at least, to Malcolm's use of it or my objection to his use. >> >> It's fine to "appeal to authority" as supporting evidence for a claim, >> and it is absolutely appropriate to view DMR's opinion on C style in >> higher standing than Kevin's or Barbara's. >> >> But it is fallacious to think of DMR's opinion as being proof that >> Malcolm's theories are correct - at best, they could be supporting >> evidence. (Even experts are wrong sometimes.) It is fallacious to >> appeal to DMR's authority when his coding and writing don't actually >> support Malcolm's ideas at all. It is fallacious to cherry-pick bits of >> code that appear to support it, rather than looking at a wider selection >> of his code. It is fallacious to consider his code written in different >> circumstances than code written now (his tools had very limited lengths >> of significant characters in identifiers). >> >> There's nothing wrong with using expert or authority opinion to bolster >> an argument, when it is not fallacious. >> > No. Denis Ritchie didn't like const. That may or may not be true - early C did not have const, but that is no evidence for saying he didn't like it. > But to say "const is a bad idea because > Denis Ritchie didn't support it" is fallacious, Correct. > though obvioulsy Denis Ritchie > almost certainly knows what he is talking about, That's an assumption, not an "obvious" fact. > and obvioulsy the committee > has shown their inferiority inm many other ways. That's an opinion (and a very unusual one at that), not an "obvious" fact. > But you have to look at the > arguments Ritchie used, not just say "Ritchie says so, so it is". Yes, looking at his reasoning would be helpful, if he explained his reasoning. I haven't personally read such reasoning, or even heard that he had written it down. (I read The C Programming Language, many years ago, but it does not mention "const", as far as I remember.) But no, you don't have to look at the reasoning behind an expert opinion to be able to use it appropriately in an argument. Equally, you can use the reasoning fallaciously. The reason behind an expert's opinions or comments is just another thing they said. Since none of your three heroes have made any comments that are relevant to your argument (and only two of them actually wrote anything at all), all your use of "appeal to authority" is fallacious. None of them were programming in modern languages with modern tools, and all had good reason to write in a compact way. And there are literally billions of other people who use word separators to make their writing clearer. (Most of them have not or do not write modern programming code either.) Can we please stop this now? You are looking more and more absurd with every word you post. It's embarrassing.
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web