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 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-28 22:17 +0100 |
| Message-ID | <87sf82n9xj.fsf@bsb.me.uk> |
| In reply to | #172951 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/08/2023 20:18, Malcolm McLean wrote:
>> 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.
Malcolm may have better sources (he does not cite them) but I suspect
the view that DMR did not like const comes from am essay he wrote to the
committee about type attributes in January of 1988[1].
A now defunct attribute (noalias -- an early attempt at restrict) was
his main target, but the draft definition of const was also unworkable.
Since the draft is not preserved (as far as I know) you have to work
backwards from the problems he describes and the changes he proposed to
see what's wrong, but it does sound broken.
However, he was prepared to say of const that is has
"two virtues: putting things in read-only memory, and expressing
interface restrictions"
which is, essentially, what const is now. The wording he objected to
was changed. Did DMR end up liking const? I don't think there is much
evidence either way, but the sematics, as it was eventually defined, had
what he considered to be some virtues.
He /really/ objected to the proposed noalias attribute. In the same
document he concludes "Noalias must go. This is non-negotiable." In
fact, let me quote more from the conclusion:
"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."
There follow 5 detailed changes that pretty much align const with what
it is today. So DMR's position on the final form of const would seem
to be that typical uses are reasonable and that its virtues have been
preserved.
And, in a salute to better days, I note that DMR posted the whole thing
on comp.lang.c (nntp:7753@alice.UUCP).
[1] https://www.lysator.liu.se/c/dmr-on-noalias.html
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-28 14:35 -0700 |
| Message-ID | <4474df0c-b2ea-41d5-94d2-faa6b239a5c1n@googlegroups.com> |
| In reply to | #173077 |
On Monday, 28 August 2023 at 22:17:59 UTC+1, Ben Bacarisse wrote: > David Brown <david...@hesbynett.no> writes: > > On 27/08/2023 20:18, Malcolm McLean wrote: > > >> 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. > > Malcolm may have better sources (he does not cite them) but I suspect > the view that DMR did not like const comes from am essay he wrote to the > committee about type attributes in January of 1988[1]. > > There follow 5 detailed changes that pretty much align const with what > it is today. So DMR's position on the final form of const would seem > to be that typical uses are reasonable and that its virtues have been > preserved. > > And, in a salute to better days, I note that DMR posted the whole thing > on comp.lang.c (nntp:77...@alice.UUCP). > In the introduction, Ritchie says "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." and then "Volatile', in particular, is a frill for esoteric applications, and much better expressed by other means. Its chief virtue is that nearly everyone can forget about it. `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." So this doesn't sound like a man greatly enamoured of const. There's an element of politiking - const is a fait accompli, and since his primary target is noalias, he can throw a sop to the committee, which is that he will accept const, with modifications. But essentially he shares my view that, yes, a rational argument can be made for const and there are some situations where it is helpful. But these reasons are not very strong, and it has disadvantages which haven't been acknowledged. However the main problem with const as it was proposed was that casting a const pointer to a non-const pointer was undefined, even if the const pointer was ultimately derived from a pointer to mutable data.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-28 14:38 -0700 |
| Message-ID | <87zg2ac0fg.fsf@nosuchdomain.example.com> |
| In reply to | #172891 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> No. Denis Ritchie didn't like const.
Perhaps there's some confusion about an article Dennis Ritchie (note
spelling) made to this newsgroup in 1988, reproducing an essay he had
sent to X3J11.
He acknowledges that his discussion about const and volatile was based
on wording that was later changed. (He even advocated giving string
literals type `const char[]`.)
https://www.lysator.liu.se/c/dmr-on-noalias.html
(This is the article where he wrote "Noalias must go. This is
non-negotiable.".)
Malcolm, consider not speaking for Dennis Ritchie.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-28 01:00 +0100 |
| Message-ID | <87y1hwm3xg.fsf@bsb.me.uk> |
| In reply to | #172889 |
David Brown <david.brown@hesbynett.no> writes: > 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. I did not refer to any supposed fallacy. > 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. That is all I was referring to and all I was commenting on in MM's post. > 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. Maybe you went further and were suggesting that he was constructing a logical argument based on the appeal to authority. If so, I missed that. I didn't think he was doing that. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 11:24 +0200 |
| Message-ID | <uchp46$1kl9e$2@dont-email.me> |
| In reply to | #172907 |
On 28/08/2023 02:00, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> 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. > > I did not refer to any supposed fallacy. > >> 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. > > That is all I was referring to and all I was commenting on in MM's post. > >> 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. > > Maybe you went further and were suggesting that he was constructing a > logical argument based on the appeal to authority. If so, I missed > that. I didn't think he was doing that. > I think he has been, in several cases, basing his argument on fallacious appeals to authority (to paraphrase - "God didn't use inter-word spacing, so clearly continuous text is always a good thing" and "DMR never used underscores, so they make identifiers harder to read and continuous text is more legible"). But you are right (I think) that he was not using it to further an argument in the particular part of a post that you quoted. Anyway, I wanted to make it clear that when you wrote "I am not with David on this", you in fact /are/ with me - because I fully agree that "There are many matters on which an appeal to authority carries significant weight". I have only been objecting to Malcolm's appeals to authority in which they do /not/ carry significant weight, or carry it contrary to what he has been claiming.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-28 03:29 -0700 |
| Message-ID | <f9e0f800-e704-4a93-b05f-95af343b650fn@googlegroups.com> |
| In reply to | #172961 |
On Monday, 28 August 2023 at 10:24:41 UTC+1, David Brown wrote: > On 28/08/2023 02:00, Ben Bacarisse wrote: > > David Brown <david...@hesbynett.no> writes: > > > >> 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. > > > > I did not refer to any supposed fallacy. > > > >> 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. > > > > That is all I was referring to and all I was commenting on in MM's post. > > > >> 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. > > > > Maybe you went further and were suggesting that he was constructing a > > logical argument based on the appeal to authority. If so, I missed > > that. I didn't think he was doing that. > > > I think he has been, in several cases, basing his argument on fallacious > appeals to authority (to paraphrase - "God didn't use inter-word > spacing, so clearly continuous text is always a good thing" and "DMR > never used underscores, so they make identifiers harder to read and > continuous text is more legible"). > > But you are right (I think) that he was not using it to further an > argument in the particular part of a post that you quoted. > The claim was that "The only thing /wrong/ - and pretty much everyone thinks it is wrong - would be to call it "multiplymatrixwithvector". So of course to refute this you have to provide a few counter-examples. Now it's not committing the fallacy of arguing from authority to choose counter-examples who are familiar, well-respected figures rather than those who wouldn't be familiar to most readers. > > Anyway, I wanted to make it clear that when you wrote "I am not with > David on this", you in fact /are/ with me - because I fully agree that > "There are many matters on which an appeal to authority carries > significant weight". I have only been objecting to Malcolm's appeals to > authority in which they do /not/ carry significant weight, or carry it > contrary to what he has been claiming. > Reality is that even sophisticated thinkers use appeals to authority all the time. For instance I quite frequently point out to scientists that peer review is an appeal to authority. Some of them get it. But a lot don't. These are highly educated, highly intelligent people who work in universities alongside professional philosophers, but they can't understand that they are making a basic logical error. There are two reasons. The first is that as a heuristic, authority is usually right, people who are not recognised authorities and dissent from the accepted consensus are usually wrong. The second reason is that when the fallacy is explained, the person doing the explaining doesn't really understand it himself, and does a a bad job. So he gives an example of where the authority isn't really an authority, and is in the wrong. "Homeopathy must be right because ing Charles believes in it". Ritchie is a real authority, probably the world's most capable person, at designing programming languages. But nothing he said is correct, because Denis Ritchie said it. It's correct because the arguments he used hold water.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 14:01 +0200 |
| Message-ID | <uci2a0$1meat$1@dont-email.me> |
| In reply to | #172965 |
On 28/08/2023 12:29, Malcolm McLean wrote: > On Monday, 28 August 2023 at 10:24:41 UTC+1, David Brown wrote: >> On 28/08/2023 02:00, Ben Bacarisse wrote: >>> David Brown <david...@hesbynett.no> writes: >>> >>>> 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. >>> >>> I did not refer to any supposed fallacy. >>> >>>> 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. >>> >>> That is all I was referring to and all I was commenting on in MM's post. >>> >>>> 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. >>> >>> Maybe you went further and were suggesting that he was constructing a >>> logical argument based on the appeal to authority. If so, I missed >>> that. I didn't think he was doing that. >>> >> I think he has been, in several cases, basing his argument on fallacious >> appeals to authority (to paraphrase - "God didn't use inter-word >> spacing, so clearly continuous text is always a good thing" and "DMR >> never used underscores, so they make identifiers harder to read and >> continuous text is more legible"). >> >> But you are right (I think) that he was not using it to further an >> argument in the particular part of a post that you quoted. >> > The claim was that "The only thing /wrong/ - and pretty much everyone > thinks it is wrong - would be to call it "multiplymatrixwithvector". > > So of course to refute this you have to provide a few counter-examples. > Now it's not committing the fallacy of arguing from authority to choose > counter-examples who are familiar, well-respected figures rather than > those who wouldn't be familiar to most readers. If DMR had supported your viewpoint, it would have been reasonable to show his opinion as a valid appeal to authority. But he did not support it (as far as I know, and as far as has been shown so far) - thus claiming he did is fallacious. Had you should code that he had written using names such as "multiplymatrixwithvector", then you would have had a point. >> >> Anyway, I wanted to make it clear that when you wrote "I am not with >> David on this", you in fact /are/ with me - because I fully agree that >> "There are many matters on which an appeal to authority carries >> significant weight". I have only been objecting to Malcolm's appeals to >> authority in which they do /not/ carry significant weight, or carry it >> contrary to what he has been claiming. >> > Reality is that even sophisticated thinkers use appeals to authority all the > time. So now we can add "whataboutism" to your list. It's another popular fallacy. > For instance I quite frequently point out to scientists that peer review > is an appeal to authority. No, it is not - or at least, it is not /fallacious/ appeals to authority. > Some of them get it. But a lot don't. These are highly > educated, highly intelligent people who work in universities alongside > professional philosophers, but they can't understand that they are making a > basic logical error. Peer review - done properly - is not a "basic logical error". > There are two reasons. The first is that as a heuristic, authority is usually > right, people who are not recognised authorities and dissent from the accepted > consensus are usually wrong. That is correct. (Getting expert opinion from qualified and knowledgable authorities is not an "appeal to authority" fallacy.) > The second reason is that when the fallacy is > explained, the person doing the explaining doesn't really understand it > himself, and does a a bad job. So he gives an example of where the authority > isn't really an authority, and is in the wrong. "Homeopathy must be right > because ing Charles believes in it". That last example is a good example of an appeal to authority fallacy. It is completely different from scientific peer review. So if a scientist does not agree with you when you claim they are the same, then that's good. > > Ritchie is a real authority, probably the world's most capable person, at > designing programming languages. He is a real authority on C. There's no doubt that he was capable of good programming language design. But it is completely unjustified to suggest he was "probably the world's most capable". There is no world cup for programming language design. There are no rankings, or scoring systems. > But nothing he said is correct, > because Denis Ritchie said it. It's correct because the arguments he used > hold water. Sure. But he did not say long identifiers are best without word breaks, or that underscores are bad, or that "const" is a terrible idea, or that "size_t" is horrible. He used underscores in long identifiers, he supported "const" (with different wording in the C standard than the original proposal), he created "size_t". So if /I/ were to write "Dennis Ritchie is arguably one of the most important original authorities on C, and he supports my points" it would be a valid appeal to authority. When /you/ write that he supports /your/ ideas, it is a fallacy because - regardless of whether Ritchie's thoughts here were right or wrong - he did not support your position.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-28 08:40 -0700 |
| Message-ID | <1827bc0b-31e5-49a9-a399-fad1d1062e3en@googlegroups.com> |
| In reply to | #172981 |
On Monday, 28 August 2023 at 13:01:19 UTC+1, David Brown wrote: > > So if /I/ were to write "Dennis Ritchie is arguably one of the most > important original authorities on C, and he supports my points" it would > be a valid appeal to authority. When /you/ write that he supports > /your/ ideas, it is a fallacy because - regardless of whether Ritchie's > thoughts here were right or wrong - he did not support your position. > No. You just haven't got it. The appeal to authority fallacy says "proposition X must be true, _because_ such and such supports it". It doesn't matter if such and such is Dennis Ritchie or David Brown. Or if the person genuinely supports proposition X or not. Or if the claim is highly controversial or something few people would disagree with. The appeal to authority fallacy is the fallacy that a statement is true because of the identity of the person making it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 19:11 +0200 |
| Message-ID | <ucg03q$18cb9$5@dont-email.me> |
| In reply to | #172807 |
On 26/08/2023 08:38, Malcolm McLean wrote:
> 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.
No, I see this style quite clearly fits exactly with the description I
gave. I see no evidence at all that the style used was avoiding
underscores - I only see evidence that in this piece of code, no
underscores were needed because all the identifiers were short. (It's
already been explained to you why identifiers were kept short in older
code.)
>>
>> Not that either of these appeals to authority have any relevance.
>>
> You don't really understand the "authority" fallacy.
Yes, I do. Perhaps you do too, but you failed to understand what you
wrote yourself and why it was an "appeal to 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?
I understand that fine.
But you didn't discuss Ritchie's style to say what he personally
preferred (which is good, because you haven't the faintest idea what
style he would have preferred given modern tools and doing modern coding).
You brought up his style as justification for your insane theory that
underscores make long identifiers harder to read. /That/ was an appeal
to authority - and a silly one, since you had no evidence that your
authority agrees with you in this case.
Do /you/ see the difference?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-25 14:49 +0100 |
| Message-ID | <ucabgk$2691$1@dont-email.me> |
| In reply to | #172738 |
On 25/08/2023 08:46, David Brown wrote:
> On 24/08/2023 16:50, Malcolm McLean wrote:
>> Languages that allow named parameters are nice, and if I was extending C
>> I would introduce that. The problem is that there are a few basic
>> mathematical
>> functions like tan() which are conventionally written tan(value), and
>> that was
>> then used a model for what other functions would be like. However only
>> a few
>> user-written functions calculate similar basic mathematical functions.
>> Generally it make sense to write payroll(employees=emp, Nemployees=N,
>> taxcode=1234), not payroll(emp, N, 1234);
>
> There are good historical reasons for why named parameters are not
> common in older languages, but are more common in newer ones. And there
> are good technical reasons why they would be difficult to introduce to C
> as an afterthought.
Which are?
> But I agree with you that they can be helpful and
> improve code readability, in languages that support them.
Actually, when I call functions defined via a C header via my FFI, I can
apply keyword parameters if I want, /and/ define default values for
missing arguments. They don't need to be written in one of those languages.
So whereas in C I have to write this:
MessageBox(NULL, "Hello, World", "Caption", 0)
from one of my languages I can do this if I don't care what the caption is:
messagebox(message:"Hello, World")
The advantages:
* I don't need to remember exact capitalisation (this is thanks to case
insensitivity)
* I don't need to remember the number, position and default values of
every parameter (default values are not part of the sig anyway;
there, I need to read the spec to discover what don't-care values to
provide
With this one, I always have trouble remembering if the caption comes
before or after the main text.
* There is less clutter and less typing
* The call is self-documenting
The only downside is needing to know the names of the parameters.
You will probably say: a good IDE can help with some of this. I will
then say that this is another advantage:
* You don't need an advanced IDE; low-techs tool will work too. You can
even sketch out code with pencil and paper on a beach!
The point really is that it's funny that any C function can be used with
keyword parameters if defined via a binding in another suitable
language, but not from C itself.
---------------
clang func "MessageBoxA" (
ref void hwnd = nil,
ichar message, caption = "Caption",
u32 flags = 0)i32
Note that 'MessageBox' is an alias for MessageBoxA in both languages.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 19:59 +0200 |
| Message-ID | <ucaq6u$4q0l$1@dont-email.me> |
| In reply to | #172760 |
On 25/08/2023 15:49, Bart wrote: > On 25/08/2023 08:46, David Brown wrote: >> On 24/08/2023 16:50, Malcolm McLean wrote: > >>> Languages that allow named parameters are nice, and if I was extending C >>> I would introduce that. The problem is that there are a few basic >>> mathematical >>> functions like tan() which are conventionally written tan(value), and >>> that was >>> then used a model for what other functions would be like. However >>> only a few >>> user-written functions calculate similar basic mathematical functions. >>> Generally it make sense to write payroll(employees=emp, Nemployees=N, >>> taxcode=1234), not payroll(emp, N, 1234); >> >> There are good historical reasons for why named parameters are not >> common in older languages, but are more common in newer ones. And >> there are good technical reasons why they would be difficult to >> introduce to C as an afterthought. > > Which are? They were not common in older languages because they make the compiler more complicated, and enforcing them means you need more information communicated between modules than you get with just a function name in an assembly file or object file. Thus you need a real "module" system, which is lacking in C. They are common in newer languages because they are useful, and we have fewer limitations on things like compiler sizes and complexity, and can be more flexible about modules and file formats. The key technical issue for making it an add-on to C is that C function declarations and definitions can have different parameter names (see my other reply on this one). > >> But I agree with you that they can be helpful and improve code >> readability, in languages that support them. > > Actually, when I call functions defined via a C header via my FFI, I can > apply keyword parameters if I want, /and/ define default values for > missing arguments. They don't need to be written in one of those languages. > Yes, that would seem reasonable - you have a wrapper in your own language, and use whatever features your own language supports. > So whereas in C I have to write this: > > MessageBox(NULL, "Hello, World", "Caption", 0) > > from one of my languages I can do this if I don't care what the caption is: > > messagebox(message:"Hello, World") > > The advantages: > > * I don't need to remember exact capitalisation (this is thanks to case > insensitivity) (That is not an advantage, IMHO - it is a disadvantage. But let's not get into that again - certainly it makes sense for the wrappers to use the same conventions as the rest of your language, not the conventions of the language being called.) > > * I don't need to remember the number, position and default values of > every parameter (default values are not part of the sig anyway; > there, I need to read the spec to discover what don't-care values to > provide > > With this one, I always have trouble remembering if the caption comes > before or after the main text. Yes, that's the point of named parameters. > > * There is less clutter and less typing Named parameters are /more/ typing, not less - but it is useful additional typing. > > * The call is self-documenting Ha! The myth of self-documenting code never dies - every programmer of every language thinks their own code is so clear it doesn't need additional documentation. But named parameters can certainly make code less cryptic. > > The only downside is needing to know the names of the parameters. > > You will probably say: a good IDE can help with some of this. I wasn't going to say it, but it is true :-) > I will > then say that this is another advantage: > > * You don't need an advanced IDE; low-techs tool will work too. You can > even sketch out code with pencil and paper on a beach! I agree - you don't /need/ a good IDE for any programming. But often it helps. > > The point really is that it's funny that any C function can be used with > keyword parameters if defined via a binding in another suitable > language, but not from C itself. That's not remotely surprising. But to be clear, I think it's nice that you support named parameters in your language. > > --------------- > clang func "MessageBoxA" ( > ref void hwnd = nil, > ichar message, caption = "Caption", > u32 flags = 0)i32 > > Note that 'MessageBox' is an alias for MessageBoxA in both languages.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-25 18:31 +0000 |
| Message-ID | <20230825110216.153@kylheku.com> |
| In reply to | #172773 |
On 2023-08-25, David Brown <david.brown@hesbynett.no> wrote: > On 25/08/2023 15:49, Bart wrote: >> On 25/08/2023 08:46, David Brown wrote: >>> On 24/08/2023 16:50, Malcolm McLean wrote: >>> >>> There are good historical reasons for why named parameters are not >>> common in older languages, but are more common in newer ones. And >>> there are good technical reasons why they would be difficult to >>> introduce to C as an afterthought. >> >> Which are? > > They were not common in older languages because they make the compiler > more complicated, and enforcing them means you need more information > communicated between modules than you get with just a function name in > an assembly file or object file. Thus you need a real "module" system, > which is lacking in C. Namde parameters are not common in older languages, because it didn't occur to people at the time. Functions are inspired by mathematics, and you don't encounter anything like named parameters in common math. It's always f(a, b) not f(x: a, y: b). Even if you hit upon the idea, it's not obvious that it's an improvement. You need to have had experience working in very large code bases with vast numbers of API's with mixed conventions. Even then, you might not find named arguments appealing due to the verbosity. You might not find naed arguments appealing due to real technical issues too. Suppose you have a language in which the model of a function call is that "expressions are evaluated in left to right order (or right to left) and pushed on the stack in that order". If you throw in named arguments into the mix, what happens to the eval order? Do you preserve the written order, or do you transform the function call according to the names into the function call that doesn't use names? Preserving the written order means temporary variables: you need a better compiler to eliminate them. Rearranging the order to match the underlying positiona argument order leads to surprising behaviors when the argument expressions have side effects. Specifically in C, we don't have a required evaluation order. But still, typically, it has been historically predictable in specific compilers. Speaking of layering, there is the fact that the underlying function call mechanism does not itself use the names. (There are languages with keyword arguments, like Common Lisp and Python, where the callee receives the keywords; I'm not writing about that.) The named arguments are transformed a function call which just passes the arguents by position. So any way you look at it, named arguments are an extra layer of fluff that is optional, and that is firmly understood in terms of a function call without named parameters. Named arguments can lead to the following unintended harm. Regular, unnamed positional arguments tend to discourage the proliferation of API's with large numbers of parameters. With named parameters (especially if some parameters can be optional) it's possible to abandon the pressure to reduce the number of parameters that makes for better API design. The named arguments become the API, and that API is no longer workable without named arguments. > The key technical issue for making it an add-on to C is that C function > declarations and definitions can have different parameter names (see my > other reply on this one). That is actually fine because the caller would just use the declaration that it has. It's just as syntactic sugar that plays out at the call site, that the callee has no knowledge about. When a function is redeclared, the names could be composed together as follows: if both declarations name a parameter, the most recent one wins. If only one of them names the parameter, that is the name. Here is the problem: if duplicat names result, it is a diagnosable error, e.g.: void foo(int x, int); void foo(int, int x); Since this is currently valid code, the rule would probably have to be that the most recent declaration completely replaces the name list; the name of the leftmost parameter becomes unavailable due to the second redeclaration. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 20:03 -0700 |
| Message-ID | <5e0128a0-507d-48a1-9fc3-04d7479068efn@googlegroups.com> |
| In reply to | #172760 |
On Friday, 25 August 2023 at 14:49:23 UTC+1, Bart wrote: > On 25/08/2023 08:46, David Brown wrote: > > On 24/08/2023 16:50, Malcolm McLean wrote: > > >> Languages that allow named parameters are nice, and if I was extending C > >> I would introduce that. The problem is that there are a few basic > >> mathematical > >> functions like tan() which are conventionally written tan(value), and > >> that was > >> then used a model for what other functions would be like. However only > >> a few > >> user-written functions calculate similar basic mathematical functions. > >> Generally it make sense to write payroll(employees=emp, Nemployees=N, > >> taxcode=1234), not payroll(emp, N, 1234); > > > > There are good historical reasons for why named parameters are not > > common in older languages, but are more common in newer ones. And there > > are good technical reasons why they would be difficult to introduce to C > > as an afterthought. > Which are? Thank you. You actually write compilers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-23 14:54 -0700 |
| Message-ID | <87zg2hfmqh.fsf@nosuchdomain.example.com> |
| In reply to | #172697 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> If you provide aboolean type then you encourage people to write functions
> that take boolean parameters. Of course intelligent people like you and I
> can see, as soon as the problem is pointed out, that this isn't a good idea,
> and will have the self-discipline to write enums. But a lot of people won't.
> So it's better not to have a boolean type. Of course they can still pass
> "1" or "0" in an int, but at least this isn't beign actively encouraged.
>> > So bool is pretty useless and we're better off without it.
>> No, bool is pretty useful and we are better off having it.
>>
> It's useful where a function returns a boolean true / false value whose
> meaning is obvious from the function definition. And it is useful in
> marking fields of structures which are logically true / false (though here
> it can be a rather extravagant use of memory and you might be better
> off with bitfields).
> But these are minor aids to readability, whilst boolean parameters are
> major impediments to readability.
Passing literal true or false as a function argument can be a problem
for legibility. It's still better than passing a literal 0 or 1 and
letting the reader guess whether it's logically a Boolean or a count.
Some languages address that with named parameter associations.
C doesn't, and I don't expect it to any time soon.
But the idea that we shouldn't have a Boolean type just because some
function calls are unclear is extremely silly. I won't try to guess
whether you're being serious. Yes, `func(some_arg, true, false)`
can be difficult to read, but there are plenty of solutions.
> The there's the if (value == true) problem.
Which has a trivial solution: Don't do that.
>> Are you /seriously/ suggesting that "readfilefromdisk" is easy to read?
>> Better than, say, "read_file_from_disk" or "readFileFromDisk" ? (Not
>> that I think the camel-case version is particularly easy to read here -
>> but it is a world better than your choice of jumble.)
>>
> In programs, yes. Because you have many identifiers all jostling for
> attention.
Please explain how "many identifiers all jostling for attention" implies
that readfilefromdisk is easier to read than read_file_from_disk or
readFileFromDisk.
[...]
> I'm not arguing that text without spaces is easier to read than text
> with spaces. However spaces in C identifiers are not allowed. The fact
> that for many hundereds of years people wrote text without spaces
> tells you that, though it's less readable than text with spaces, it's
> not that difficult to read.
The fact that we stopped doing that suggests that separating words is
better than not separating words.
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-22 14:57 +0000 |
| Message-ID | <014FM.455986$U3w1.419742@fx09.iad> |
| In reply to | #172662 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, 22 August 2023 at 13:10:11 UTC+1, David Brown wrote: >> You are talking about a very rare situation. The issue does arise - it >> is the reason for the "mutable" keyword in C++. But it is rare, and >> certainly not a rational justification for not using "const". >> >It's rare "in the small".A function to calculate the employees' average salary can take >a const * and it's most unlikely to be rewritten to use the array as scratch memory >space. It's unlikely to use an array at all. In the real world, it would likely just be a programmatic SQL query to the employee database.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 14:10 +0100 |
| Message-ID | <uc2c4m$2du20$1@dont-email.me> |
| In reply to | #172660 |
On 22/08/2023 13:09, David Brown wrote:
> On 22/08/2023 08:03, Malcolm McLean wrote:
>> On Monday, 21 August 2023 at 14:17:16 UTC+1, David Brown wrote:
>>>
>>> If the function in question might change the data, it should be
>>> non-const. If it will not change the data, it should be a const
>>> pointer. That gives the user vital information.
>>>
>> We have to document what the function does and what the parameters
>> mean anyway. const can help, but it isn't the main source of information,
>> and it isn't "vital". If it was "vital" then K and R C wouldn't have
>> been a
>> viable programming language.
>
> C90 was a vast improvement over K&R C (and C99 another huge improvement
> - changes after that have been relatively minor).
>
> You can argue that every programming feature that is not in a Turing
> Machine is not "vital". The reality, however, is that some features are
> very useful for helping writing clear and correct programs. "const" is
> one of these. It is no surprise that many modern languages make
> everything "const" by default and require explicit keywords to support
> modifiable data.
It is a rather unique feature in that you can take any working C
program, take out all the 'const's, and it will still compile and still
work.
But the downside of const is:
* It generates more clutter, making it harder to spot real problems
* Some people go mad with it, often pointlessly so
* It can give a false sense of security (or you can also stick
'const' in the wrong place)
* You can waste time tying yourself up in knots trying to get around
a 'const' in a data structure that seemed a good idea at first
> Arguing that you could get by without "const" when programming 35 years
> ago is just nonsense.
>
> This is, of course, your program and your decision - all I can do is
> give you advice, and it is up to you to take it or leave it.
And using it is your decision.
>> A function called strtoupper() pretty obviously
>> is designed to change the string passed to it.
>
> I disagree - it would depend on the signature and the way your API
> works. If you have a type "String" that is a managed string type, and
> you had a signature :
>
> String strtoupper(String s);
>
> then I would expect it to return a new String and leave all the caller's
> data unaffected. (It would be a "Malcolm-function".)
>
> If it were declared :
>
> const char * strtoupper(const char * s);
>
> then I would again expect the function to allocate new space and leave
> the original string unchanged.
>
> But if it were declared :
>
> void strtoupper(char * s);
>
> /then/ I would expect it to change the original string.
>
> Mistakenly assuming that users will make correct "obvious assumptions"
> about behaviour based on function names is a recipe for disaster.
There'all poor names IMO. In a language where you can routinely pass and
return object by value, then
strtoupper(s)
sounds like it will return a modified copy of s (no matter what the
signature is). I would use:
istrtoupper(s)
Using a leading 'i' is a prefix I tend to add to functions performing
in-place updates.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-21 13:46 +0100 |
| Message-ID | <87fs4csgv2.fsf@bsb.me.uk> |
| In reply to | #172617 |
David Brown <david.brown@hesbynett.no> writes: > On 21/08/2023 01:05, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> > >>> Apparently it opens a can of worms because it makes the string a >>> char8_t * instead of a char *. >> Is the can of worms really there? The "apparently" makes me worry it's >> hearsay and FUD. In C11 it's a char[], but in C23 just cast to char * >> or unsigned char *. Where are the worms? >> But if I were writing such a program, I'd put effort into allowing >> different C standard outputs rather than dealing with EBCDIC source >> code. Someone who uses C23 will prefer >> char8_t *cdata = u8"CDATA"; >> > > Is there any reason not to write : > > const char8_t * cdata = u8"CDATA"; > > ? Not for me, but Malcolm does not like const. I'd use it, or I'd write char8_t cdata[] = u8"CDATA"; -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-08-16 17:32 -0700 |
| Message-ID | <1d587f1a-6958-4dd2-bc02-45b47f535278n@googlegroups.com> |
| In reply to | #172359 |
środa, 16 sierpnia 2023 o 12:14:20 UTC+2 Bart napisał(a): > On 16/08/2023 08:31, Malcolm McLean wrote: > > Some people here are interested in Haskell. > > They might be interested in this: > > > > https://chrisdone.com/posts/fast-haskell-c-parsing-xml/ > > > > Of course it's written from a pro-Haskell point of view, and writing an improved version when you've got the C in front of you isn't really a fair test. But he does match C for speed. > > > "Portability (i.e. Windows) is a pain in the arse with C." > > I wonder what makes them say that? > > Reading from a file must be the world's most portable kind of program. > While issues with filenames and paths will be the same whatever the > language. > > So what is it? ponys have special areas of ponys trash talking "portability" is one of that areas, other are for example "standard/undefined behaviour" or "dont diccover a wheel" or "oop is good" etc...its pony world full of belifs myths lies and general bulshit
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-08-16 17:47 -0700 |
| Message-ID | <101175be-f5e7-46d5-8369-64278ec9a3b9n@googlegroups.com> |
| In reply to | #172428 |
czwartek, 17 sierpnia 2023 o 02:32:15 UTC+2 fir napisał(a): > środa, 16 sierpnia 2023 o 12:14:20 UTC+2 Bart napisał(a): > > On 16/08/2023 08:31, Malcolm McLean wrote: > > > Some people here are interested in Haskell. > > > They might be interested in this: > > > > > > https://chrisdone.com/posts/fast-haskell-c-parsing-xml/ > > > > > > Of course it's written from a pro-Haskell point of view, and writing an improved version when you've got the C in front of you isn't really a fair test. But he does match C for speed. > > > > > "Portability (i.e. Windows) is a pain in the arse with C." > > > > I wonder what makes them say that? > > > > Reading from a file must be the world's most portable kind of program. > > While issues with filenames and paths will be the same whatever the > > language. > > > > So what is it? > ponys have special areas of ponys trash talking "portability" is one of that areas, other are for example "standard/undefined behaviour" or "dont diccover a wheel" or "oop is good" etc...its pony world full of belifs myths lies and general bulshit this pony areas list is ofc longer and it grows depending of how many things soem inspects itself the more myths pony lives in shows..this way reading pony articles that propagate myths is somewhat rather a negative value
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-17 00:37 +0000 |
| Message-ID | <20230816173214.630@kylheku.com> |
| In reply to | #172359 |
On 2023-08-16, Bart <bc@freeuk.com> wrote: > On 16/08/2023 08:31, Malcolm McLean wrote: >> Some people here are interested in Haskell. >> They might be interested in this: >> >> https://chrisdone.com/posts/fast-haskell-c-parsing-xml/ >> >> Of course it's written from a pro-Haskell point of view, and writing an improved version when you've got the C in front of you isn't really a fair test. But he does match C for speed. >> > > "Portability (i.e. Windows) is a pain in the arse with C." > > I wonder what makes them say that? > > Reading from a file must be the world's most portable kind of program. > While issues with filenames and paths will be the same whatever the > language. > > So what is it? Portability of advanced programs that go beyond the standard C library. For instance, say, a program that opens a serial device and sets the baud rate, framing/parity bits and hardware handshaking, and then reads from it --- with timeouts. POSIX is quite different from Win32 in every way. Everything is done differently: ranging from a bit differently, to radically. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web