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 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
| From | candycane@f172.n1.z21.fsxnet (candycane) |
|---|---|
| Date | 2023-08-26 00:45 +1300 |
| Message-ID | <670468524@f172.n1.z21.fsxnet> |
| In reply to | #172763 |
SL> I'd wager that most C programmers don't even think about it, much SL> less care. I personally kinda like the _t, it makes it stand out a bit because i name vars stuff like "size" all the time. ----------------------------------- user is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-25 19:50 +0100 |
| Message-ID | <87pm3bot1n.fsf@bsb.me.uk> |
| In reply to | #172744 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >> > Of course size_t has an underscore. Everyone knows that. And most people >> > agree that it is horrible. >> "Most people" meaning you made it up. >> > We could do a straw poll. > How many people like the underscore in size_t and how many think it is > horrible? Did you really just set up a false dichotomy to try to tip the results? The question should be simply whether you agree that it's horrible or not. You don't have to actually like it to not agree that it's horrible. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-26 02:55 -0700 |
| Message-ID | <7a9b3883-ee9f-4d46-944c-c11d4f0354d5n@googlegroups.com> |
| In reply to | #172779 |
On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: > >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) > >> Malcolm McLean <malcolm.ar...@gmail.com> wrote: > >> > Of course size_t has an underscore. Everyone knows that. And most people > >> > agree that it is horrible. > >> "Most people" meaning you made it up. > >> > > We could do a straw poll. > > How many people like the underscore in size_t and how many think it is > > horrible? > Did you really just set up a false dichotomy to try to tip the results? > The question should be simply whether you agree that it's horrible or > not. You don't have to actually like it to not agree that it's > horrible. > That's a mathematician thinking. "Not horrible" is the complentary set to "horrible" and thus should be the other choice. It doesn't work like that. Bascially "horrible" is a word, whilst "not horrible" is not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-26 19:21 +0200 |
| Message-ID | <ucdcaf$mj8h$1@dont-email.me> |
| In reply to | #172810 |
On 26/08/2023 11:55, Malcolm McLean wrote: > On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>>>> Of course size_t has an underscore. Everyone knows that. And most people >>>>> agree that it is horrible. >>>> "Most people" meaning you made it up. >>>> >>> We could do a straw poll. >>> How many people like the underscore in size_t and how many think it is >>> horrible? >> Did you really just set up a false dichotomy to try to tip the results? >> The question should be simply whether you agree that it's horrible or >> not. You don't have to actually like it to not agree that it's >> horrible. >> > That's a mathematician thinking. Do you realise that this is a compliment? You write as though you meant it as criticism, but Ben's rational and logical thinking is a good thing - it's certainly far better than your politician "thinking". > "Not horrible" is the complentary set to > "horrible" and thus should be the other choice. No. The opposite of "think it is horrible" is "do not think it is horrible". It is not "think it is not horrible". But even that is vastly closer than "like it". > It doesn't work like that. I have no idea what you think "it" is, or how you think "it" might or might not work - but I strongly suspect you are wrong nonetheless. > Bascially "horrible" is a word, whilst "not horrible" is not. And the relevance of that is ... absolutely nothing. Please try again to answer Ben's question (or mine in an earlier post, which was much the same). Do you know what a false dichotomy is? Do you understand that your "straw poll" is a false dichotomy? Do you realise that false dichotomies are used to try to provoke an answer that appears to support a particular position, but does not represent a real model of viewpoints? Yes/no answers will do - but if you want to elaborate, please at least attempt to answer the questions.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-27 03:05 -0700 |
| Message-ID | <627cbd87-75d6-49e9-b2e0-733ca17b7cean@googlegroups.com> |
| In reply to | #172822 |
On Saturday, 26 August 2023 at 18:21:37 UTC+1, David Brown wrote: > On 26/08/2023 11:55, Malcolm McLean wrote: > > On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > >>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: > >>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) > >>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: > >>>>> Of course size_t has an underscore. Everyone knows that. And most people > >>>>> agree that it is horrible. > >>>> "Most people" meaning you made it up. > >>>> > >>> We could do a straw poll. > >>> How many people like the underscore in size_t and how many think it is > >>> horrible? > >> Did you really just set up a false dichotomy to try to tip the results? > >> The question should be simply whether you agree that it's horrible or > >> not. You don't have to actually like it to not agree that it's > >> horrible. > >> > > That's a mathematician thinking. > Do you realise that this is a compliment? You write as though you meant > it as criticism, but Ben's rational and logical thinking is a good thing > - it's certainly far better than your politician "thinking". > > "Not horrible" is the complentary set to > > "horrible" and thus should be the other choice. > No. > > The opposite of "think it is horrible" is "do not think it is horrible". > It is not "think it is not horrible". But even that is vastly closer > than "like it". > > It doesn't work like that. > I have no idea what you think "it" is, or how you think "it" might or > might not work - but I strongly suspect you are wrong nonetheless. > > Bascially "horrible" is a word, whilst "not horrible" is not. > And the relevance of that is ... absolutely nothing. > > > Please try again to answer Ben's question (or mine in an earlier post, > which was much the same). Do you know what a false dichotomy is? Do > you understand that your "straw poll" is a false dichotomy? Do you > realise that false dichotomies are used to try to provoke an answer that > appears to support a particular position, but does not represent a real > model of viewpoints? > > Yes/no answers will do - but if you want to elaborate, please at least > attempt to answer the questions. > Let's take probaly the most famous false dichotomy of all. "Is it or is it not permissible to pay taxes to Caesar?" According to Ben, this isn't a false dichotomy at all. Its either one or the other. But of course that's a totally inadequate way of looking at it. Then take "who likes it"? In. Ben's world, there is a small class of people in the "like" world, and a larger class of people who are not in this class, but not in the "horrible" class either. But yesterday my little niece said "I don't like dinosaurs".So was she saying "I am not in the class of children who like dinosaurs?". Not really. What she was saying was "I actively dislike dinosaurs. They offend me. Please take them away." Then as you yourself pointed out, there's a difference between thinking it is "not horrible" and not thinking that it is horrible. Logically. But that's hardly helpful. There's far more to it than you think. If you were correct and language worked like that, it would be easy to get computers to talk by applying a bit of simple set theory. And of course that approach doesn't work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 18:28 +0200 |
| Message-ID | <ucftjs$186cs$1@dont-email.me> |
| In reply to | #172873 |
On 27/08/2023 12:05, Malcolm McLean wrote: > On Saturday, 26 August 2023 at 18:21:37 UTC+1, David Brown wrote: >> On 26/08/2023 11:55, Malcolm McLean wrote: >>> On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >>>>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>>>>>> Of course size_t has an underscore. Everyone knows that. And most people >>>>>>> agree that it is horrible. >>>>>> "Most people" meaning you made it up. >>>>>> >>>>> We could do a straw poll. >>>>> How many people like the underscore in size_t and how many think it is >>>>> horrible? >>>> Did you really just set up a false dichotomy to try to tip the results? >>>> The question should be simply whether you agree that it's horrible or >>>> not. You don't have to actually like it to not agree that it's >>>> horrible. >>>> >>> That's a mathematician thinking. >> Do you realise that this is a compliment? You write as though you meant >> it as criticism, but Ben's rational and logical thinking is a good thing >> - it's certainly far better than your politician "thinking". >>> "Not horrible" is the complentary set to >>> "horrible" and thus should be the other choice. >> No. >> >> The opposite of "think it is horrible" is "do not think it is horrible". >> It is not "think it is not horrible". But even that is vastly closer >> than "like it". >>> It doesn't work like that. >> I have no idea what you think "it" is, or how you think "it" might or >> might not work - but I strongly suspect you are wrong nonetheless. >>> Bascially "horrible" is a word, whilst "not horrible" is not. >> And the relevance of that is ... absolutely nothing. >> >> >> Please try again to answer Ben's question (or mine in an earlier post, >> which was much the same). Do you know what a false dichotomy is? Do >> you understand that your "straw poll" is a false dichotomy? Do you >> realise that false dichotomies are used to try to provoke an answer that >> appears to support a particular position, but does not represent a real >> model of viewpoints? >> >> Yes/no answers will do - but if you want to elaborate, please at least >> attempt to answer the questions. >> > Let's take probaly the most famous false dichotomy of all. No, let's not. Let's try to answer the questions at hand. Should I assume you can't answer them? > "Is it or is it not permissible to pay taxes to Caesar?" > According to Ben, this isn't a false dichotomy at all. Its either one or > the other. I haven't noticed Ben making any comment on that question. Would you like to give a reference to his post? Or an accurate quotation? And of course it has absolutely nothing to do with the fact that what /you/ asked as your "straw poll" was absolutely and clearly a false dichotomy. > But of course that's a totally inadequate way of looking at it. > > Then take "who likes it"? In. Ben's world, there is a small class of people > in the "like" world, and a larger class of people who are not in this class, > but not in the "horrible" class either. Again, you are inventing things that Ben did not say. But /I/ said something to that effect. And since there are undoubtedly three classes here (lots of people have put themselves in the "like" group, you and Bart are in the "horrible" group, while Scott has, I think, placed himself in the "don't care" group), then there is no doubt that your question was a false dichotomy. > > There's far more to it than you think. If you were correct and language > worked like that, it would be easy to get computers to talk by applying a bit > of simple set theory. And of course that approach doesn't work. Making vague and useless comments about how complicated human language can be (as if it were something that you knew, and the rest of us do not) does not let you off the hook for getting things wrong, trying to con people with fallacious arguments, and being unable to own up to it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-28 14:01 +0000 |
| Message-ID | <gN1HM.144949$ftCb.130257@fx34.iad> |
| In reply to | #172882 |
David Brown <david.brown@hesbynett.no> writes: >On 27/08/2023 12:05, Malcolm McLean wrote: <discussion regarding use of underscore characters in identifiers> > >But /I/ said something to that effect. And since there are undoubtedly >three classes here (lots of people have put themselves in the "like" >group, you and Bart are in the "horrible" group, while Scott has, I >think, placed himself in the "don't care" group), then there is no doubt >that your question was a false dichotomy. Yes, "don't care" is an accurate summation of my position. It's a legal character in identifiers - there is no intrinsic goodness or badness to it. That said, I will use it in preference to CamelCase, which I dislike primarily because of the impact on my typing speed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 16:07 -0700 |
| Message-ID | <86il8ywyu5.fsf@linuxsc.com> |
| In reply to | #173000 |
scott@slp53.sl.home (Scott Lurndal) writes: > I will use [underscore] in preference to CamelCase, which I dislike > primarily because of the impact on my typing speed. In most cases I find CamelCase harder to read than using underscores, especially when using mono-spaced fonts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-29 09:16 +0200 |
| Message-ID | <uck607$2563l$1@dont-email.me> |
| In reply to | #173116 |
On 29/08/2023 01:07, Tim Rentsch wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > >> I will use [underscore] in preference to CamelCase, which I dislike >> primarily because of the impact on my typing speed. > > In most cases I find CamelCase harder to read than using > underscores, especially when using mono-spaced fonts. I used to use camelCase for most of my identifiers - now I find I am using underscores much more, precisely because I find it easier to read. I strongly suspect it is age-related - camelCase was more appealing when my eyes were younger.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 19:22 +0000 |
| Message-ID | <20230829121430.516@kylheku.com> |
| In reply to | #173158 |
On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote: > On 29/08/2023 01:07, Tim Rentsch wrote: >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> I will use [underscore] in preference to CamelCase, which I dislike >>> primarily because of the impact on my typing speed. >> >> In most cases I find CamelCase harder to read than using >> underscores, especially when using mono-spaced fonts. > > I used to use camelCase for most of my identifiers - now I find I am > using underscores much more, precisely because I find it easier to read. > I strongly suspect it is age-related - camelCase was more appealing > when my eyes were younger. CamelCase is at odds with the C language. It is not used in the standard library, and it's not used in the related POSIX standard which comes from the same birthplace. It's not used, or rarely used, in Unix file naming conventions, or for naming anything in the shell environment. Makefile has an M just to put it ahead of lower-cased filenames in the lexicographic listing (which would not work if files had names like Parser.c and UserInterface.c.) I have always avoided that naming convention in C programming, unless it was required by the coding style of the code base. I might have used CamelCase in Modula 2 and Pascal programming once; alas, I do not remember this detail. Look at this: https://www.modula2.org/reference/isomodules/ Modula 2's standard library is all CamelCase, so it makes sense to do that in Modula 2 programs for consistency with the language. I probably did that. When I write Lisp FFI definitions for Win32 functions, I use the CamelCase and UPPER_CASE identifiers. The reason is that this makes the code readable to someone familiar with that naming, rather than inundating them with a translation scheme. When I write Lisp FFI definitions for snake_case, I use kebob-case on the Lisp side. This is a very minor translation which brings a nice benefit that the identifiers follow the native Lisp convention. 1> (sizeof size-t) ;; not size_t 4 2> (ffi size-t) #<ffi-type uint> -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-29 19:38 +0000 |
| Message-ID | <COrHM.561036$U3w1.379355@fx09.iad> |
| In reply to | #173210 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote: >> On 29/08/2023 01:07, Tim Rentsch wrote: > >Makefile has an M just to put it ahead of lower-cased filenames >in the lexicographic listing (which would not work if files had names >like Parser.c and UserInterface.c.) It also won't work with EBCDIC encoding.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 20:11 +0000 |
| Message-ID | <20230829130827.803@kylheku.com> |
| In reply to | #173212 |
On 2023-08-29, Scott Lurndal <scott@slp53.sl.home> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >>On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote: >>> On 29/08/2023 01:07, Tim Rentsch wrote: > >> >>Makefile has an M just to put it ahead of lower-cased filenames >>in the lexicographic listing (which would not work if files had names >>like Parser.c and UserInterface.c.) > > It also won't work with EBCDIC encoding. Not just that but some locales other than "C", where the alphabetical order puts A and a together. A Unix based on EBCDIC would probably sprout some locale that simulates ASCII sorting to the extent possible. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-29 21:59 +0200 |
| Message-ID | <uclinu$2cs9n$1@dont-email.me> |
| In reply to | #173210 |
On 29/08/2023 21:22, Kaz Kylheku wrote: > On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote: >> On 29/08/2023 01:07, Tim Rentsch wrote: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> I will use [underscore] in preference to CamelCase, which I dislike >>>> primarily because of the impact on my typing speed. >>> >>> In most cases I find CamelCase harder to read than using >>> underscores, especially when using mono-spaced fonts. >> >> I used to use camelCase for most of my identifiers - now I find I am >> using underscores much more, precisely because I find it easier to read. >> I strongly suspect it is age-related - camelCase was more appealing >> when my eyes were younger. > > CamelCase is at odds with the C language. It is not used in the standard > library, and it's not used in the related POSIX standard which comes > from the same birthplace. > Nonsense. Just because it is not used in the C standard library or POSIX does not make it "at odds with the C language". It might be more common in other languages than C, but it's fine for identifiers in C.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-30 00:43 -0700 |
| Message-ID | <62855ccd-0d2c-431f-b776-f8f84eb58a4an@googlegroups.com> |
| In reply to | #173214 |
On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote: > On 29/08/2023 21:22, Kaz Kylheku wrote: > > On 2023-08-29, David Brown <david...@hesbynett.no> wrote: > >> On 29/08/2023 01:07, Tim Rentsch wrote: > >>> sc...@slp53.sl.home (Scott Lurndal) writes: > >>> > >>>> I will use [underscore] in preference to CamelCase, which I dislike > >>>> primarily because of the impact on my typing speed. > >>> > >>> In most cases I find CamelCase harder to read than using > >>> underscores, especially when using mono-spaced fonts. > >> > >> I used to use camelCase for most of my identifiers - now I find I am > >> using underscores much more, precisely because I find it easier to read. > >> I strongly suspect it is age-related - camelCase was more appealing > >> when my eyes were younger. > > > > CamelCase is at odds with the C language. It is not used in the standard > > library, and it's not used in the related POSIX standard which comes > > from the same birthplace. > > > Nonsense. Just because it is not used in the C standard library or > POSIX does not make it "at odds with the C language". It might be more > common in other languages than C, but it's fine for identifiers in C. > It's not in itself a knockdown, conclusive argument. But it's a good argument. Match the standard library house style.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-30 12:30 +0200 |
| Message-ID | <ucn5ni$2mv5b$1@dont-email.me> |
| In reply to | #173250 |
On 30/08/2023 09:43, Malcolm McLean wrote: > On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote: >> On 29/08/2023 21:22, Kaz Kylheku wrote: >>> On 2023-08-29, David Brown <david...@hesbynett.no> wrote: >>>> On 29/08/2023 01:07, Tim Rentsch wrote: >>>>> sc...@slp53.sl.home (Scott Lurndal) writes: >>>>> >>>>>> I will use [underscore] in preference to CamelCase, which I dislike >>>>>> primarily because of the impact on my typing speed. >>>>> >>>>> In most cases I find CamelCase harder to read than using >>>>> underscores, especially when using mono-spaced fonts. >>>> >>>> I used to use camelCase for most of my identifiers - now I find I am >>>> using underscores much more, precisely because I find it easier to read. >>>> I strongly suspect it is age-related - camelCase was more appealing >>>> when my eyes were younger. >>> >>> CamelCase is at odds with the C language. It is not used in the standard >>> library, and it's not used in the related POSIX standard which comes >>> from the same birthplace. >>> >> Nonsense. Just because it is not used in the C standard library or >> POSIX does not make it "at odds with the C language". It might be more >> common in other languages than C, but it's fine for identifiers in C. >> > It's not in itself a knockdown, conclusive argument. > But it's a good argument. Match the standard library house style. It is not even remotely close to being a good argument. Consistency of style within a project, library, team, etc., is important and makes the code easier to write, easier to read, and easier to use. That's why projects or teams often have style guides. But there are no advantages in following a style from a different project. If you are contributing to the C standards, or an extended version of the C standard library, then follow the style for the C standard library - no word separators for short function names, underscores for long function names and macros, _t for types, etc. Most people, however, are /not/ writing code for the C standard library, and thus the style of the C standard library should not influence style for their own code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-30 05:04 -0700 |
| Message-ID | <fb65da9e-a175-4e9d-8749-b5d45e5ceeb3n@googlegroups.com> |
| In reply to | #173261 |
On Wednesday, 30 August 2023 at 11:30:26 UTC+1, David Brown wrote: > On 30/08/2023 09:43, Malcolm McLean wrote: > > On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote: > >> On 29/08/2023 21:22, Kaz Kylheku wrote: > >>> On 2023-08-29, David Brown <david...@hesbynett.no> wrote: > >>>> On 29/08/2023 01:07, Tim Rentsch wrote: > >>>>> sc...@slp53.sl.home (Scott Lurndal) writes: > >>>>> > >>>>>> I will use [underscore] in preference to CamelCase, which I dislike > >>>>>> primarily because of the impact on my typing speed. > >>>>> > >>>>> In most cases I find CamelCase harder to read than using > >>>>> underscores, especially when using mono-spaced fonts. > >>>> > >>>> I used to use camelCase for most of my identifiers - now I find I am > >>>> using underscores much more, precisely because I find it easier to read. > >>>> I strongly suspect it is age-related - camelCase was more appealing > >>>> when my eyes were younger. > >>> > >>> CamelCase is at odds with the C language. It is not used in the standard > >>> library, and it's not used in the related POSIX standard which comes > >>> from the same birthplace. > >>> > >> Nonsense. Just because it is not used in the C standard library or > >> POSIX does not make it "at odds with the C language". It might be more > >> common in other languages than C, but it's fine for identifiers in C. > >> > > It's not in itself a knockdown, conclusive argument. > > But it's a good argument. Match the standard library house style. > It is not even remotely close to being a good argument. > > Consistency of style within a project, library, team, etc., is important > and makes the code easier to write, easier to read, and easier to use. > That's why projects or teams often have style guides. > > But there are no advantages in following a style from a different > project. If you are contributing to the C standards, or an extended > version of the C standard library, then follow the style for the C > standard library - no word separators for short function names, > underscores for long function names and macros, _t for types, etc. Most > people, however, are /not/ writing code for the C standard library, and > thus the style of the C standard library should not influence style for > their own code. > You call the standard library in most C projects. So the argument is that you should match the standard library style. The alternative argument is that you should deliberately not match the standard library style, to make it obvious which calls are standard library calls and which are not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-30 17:50 +0200 |
| Message-ID | <ucnogj$2povs$1@dont-email.me> |
| In reply to | #173293 |
On 30/08/2023 14:04, Malcolm McLean wrote: > On Wednesday, 30 August 2023 at 11:30:26 UTC+1, David Brown wrote: >> On 30/08/2023 09:43, Malcolm McLean wrote: >>> On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote: >>>> On 29/08/2023 21:22, Kaz Kylheku wrote: >>>>> On 2023-08-29, David Brown <david...@hesbynett.no> wrote: >>>>>> On 29/08/2023 01:07, Tim Rentsch wrote: >>>>>>> sc...@slp53.sl.home (Scott Lurndal) writes: >>>>>>> >>>>>>>> I will use [underscore] in preference to CamelCase, which I dislike >>>>>>>> primarily because of the impact on my typing speed. >>>>>>> >>>>>>> In most cases I find CamelCase harder to read than using >>>>>>> underscores, especially when using mono-spaced fonts. >>>>>> >>>>>> I used to use camelCase for most of my identifiers - now I find I am >>>>>> using underscores much more, precisely because I find it easier to read. >>>>>> I strongly suspect it is age-related - camelCase was more appealing >>>>>> when my eyes were younger. >>>>> >>>>> CamelCase is at odds with the C language. It is not used in the standard >>>>> library, and it's not used in the related POSIX standard which comes >>>>> from the same birthplace. >>>>> >>>> Nonsense. Just because it is not used in the C standard library or >>>> POSIX does not make it "at odds with the C language". It might be more >>>> common in other languages than C, but it's fine for identifiers in C. >>>> >>> It's not in itself a knockdown, conclusive argument. >>> But it's a good argument. Match the standard library house style. >> It is not even remotely close to being a good argument. >> >> Consistency of style within a project, library, team, etc., is important >> and makes the code easier to write, easier to read, and easier to use. >> That's why projects or teams often have style guides. >> >> But there are no advantages in following a style from a different >> project. If you are contributing to the C standards, or an extended >> version of the C standard library, then follow the style for the C >> standard library - no word separators for short function names, >> underscores for long function names and macros, _t for types, etc. Most >> people, however, are /not/ writing code for the C standard library, and >> thus the style of the C standard library should not influence style for >> their own code. >> > You call the standard library in most C projects. You do not /write/ the standard library for most C projects. > So the argument is that you should match the standard library style. The argument is worthless. > The alternative argument is that you should deliberately not match > the standard library style, to make it obvious which calls are standard > library calls and which are not. > That is equally worthless as an argument.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-30 19:41 +0000 |
| Message-ID | <20230830122002.133@kylheku.com> |
| In reply to | #173307 |
On 2023-08-30, David Brown <david.brown@hesbynett.no> wrote: > On 30/08/2023 14:04, Malcolm McLean wrote: >> You call the standard library in most C projects. > > You do not /write/ the standard library for most C projects. > >> So the argument is that you should match the standard library style. > > The argument is worthless. > >> The alternative argument is that you should deliberately not match >> the standard library style, to make it obvious which calls are standard >> library calls and which are not. > > That is equally worthless as an argument. Coding conventions are arbitrarily chosen, an enforced not by arguments but authority: ranging from "your patch is rejected" to "write like this or find work somewhere else". But there exists a consistency argument: if you don't conform to the coding convention, then code becomes harder to work with. (As real experience with mixed style codebases informs us.) If the naming recommended by the coding convention is at odds with the language, then that prevents maximal consistency from being reached. If consistency is good, globally maximal consistency is better than locally maximal consistency. Thus there is exists a consistency argument against choosing a CamelCase naming convention in a brand new C project with zero legacy code. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-31 11:18 +0200 |
| Message-ID | <ucplsh$36a8s$1@dont-email.me> |
| In reply to | #173342 |
On 30/08/2023 21:41, Kaz Kylheku wrote: > On 2023-08-30, David Brown <david.brown@hesbynett.no> wrote: >> On 30/08/2023 14:04, Malcolm McLean wrote: >>> You call the standard library in most C projects. >> >> You do not /write/ the standard library for most C projects. >> >>> So the argument is that you should match the standard library style. >> >> The argument is worthless. >> >>> The alternative argument is that you should deliberately not match >>> the standard library style, to make it obvious which calls are standard >>> library calls and which are not. >> >> That is equally worthless as an argument. > > Coding conventions are arbitrarily chosen, an enforced not by arguments > but authority: ranging from "your patch is rejected" to "write like this > or find work somewhere else". > Coding conventions should certainly /not/ be chosen arbitrarily. But once chosen, it is usually important to follow them (or to justify cases where you deviate from them). Considerations when choosing a coding convention include branch norms, application area, existing projects, team makeup (including experience levels), enforceability, and compatibility with other languages. Sometimes price is a factor too - there are commercially available coding standards. The details of coding conventions themselves should be take into account readability, maintainability, safety, tool options, and target details, amongst other things. Some coding conventions are very loose and cover only a few points, others are detailed and rigid. As much as possible, all choices involved should be active decisions based on good arguments - not arbitrarily chosen. > But there exists a consistency argument: if you don't conform to the > coding convention, then code becomes harder to work with. (As real > experience with mixed style codebases informs us.) Yes. > > If the naming recommended by the coding convention is at odds with the > language, then that prevents maximal consistency from being reached. > Yes. That is an issue for some languages, where there are restrictions on the identifiers. If your project involves several languages, and some have specific requirements (such as types start with capitals, or variables must start with a lower case letter), consistency can be hard. Fortunately, C has no conventions or rules (other than the characters allowed), so you will never be "at odds" with the C language. > If consistency is good, globally maximal consistency is better than > locally maximal consistency. > No, not necessarily. Or at least, the consistency is not a major factor compared to other concerns. > Thus there is exists a consistency argument against choosing > a CamelCase naming convention in a brand new C project with zero > legacy code. > I agree there is such an argument - and it is worth considering. After due consideration, I think it is a worthless argument. There is no standard in C in regards to naming convention except for having macros named in all-caps. (And I think that convention is a bad one, and do not follow it because I rate other factors as more important than consistency with a poor choice.) Now, if you want to argue that you find CamelCase (or camelCase) harder to read, then that is a /good/ argument. Again, it might not be the overriding factor - but it is a far better reason than "global consistency" with some pure imaginary "global C standard".
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2023-08-30 14:40 +0000 |
| Message-ID | <ucnkde$2op2r$1@dont-email.me> |
| In reply to | #173210 |
On Tue, 29 Aug 2023 19:22:09 +0000, Kaz Kylheku wrote:
> On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote:
>> On 29/08/2023 01:07, Tim Rentsch wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> I will use [underscore] in preference to CamelCase, which I dislike
>>>> primarily because of the impact on my typing speed.
>>>
>>> In most cases I find CamelCase harder to read than using
>>> underscores, especially when using mono-spaced fonts.
>>
>> I used to use camelCase for most of my identifiers - now I find I am
>> using underscores much more, precisely because I find it easier to read.
>> I strongly suspect it is age-related - camelCase was more appealing
>> when my eyes were younger.
>
> CamelCase is at odds with the C language.
I would disagree. CamelCase (as in identifiers consisting of a mix of
upper and lower case characters) is inherent in the definition of an
identifier, and has been since K&R C. The /language/ imposes no
restriction on the use of CamelCase (although, in "The C Programming
Language", K&R did note that "the underscore ... is useful for improving
the readability of long variable names").
> It is not used in the standard
> library, and it's not used in the related POSIX standard which comes
> from the same birthplace.
That may be more because of the compilation environment than because
of the language standards.
Remember, when the code that we now call the C standard library, and
the facilities that we now call the POSIX standard were initially
developed, the C language /implementations/ were limited by the
underlying host environment's restrictions on external names.
Some environments imposed a single case on external names (usually,
upper case only), so Strcmp() and strcmp(), while naming different
functions, would both resolve to the external name STRCMP. Kernighan,
Plauger, Ritchie, et al likely avoided mixed case external names
in the C and UNIX libraries for this reason alone.
> It's not used, or rarely used, in Unix file naming conventions,
> or for naming anything in the shell environment.
But, /not/ discouraged or forbidden.
> Makefile has an M just to put it ahead of lower-cased filenames
> in the lexicographic listing
Can you provide a definitive reference for that assertion?
I note that the 1978 Bell Labs version of make(1) read it's
dependency list from a file called "makefile"[1]. I do not
know when that changed to "Makefile".
> (which would not work if files had names
> like Parser.c and UserInterface.c.)
[snip]
[1] "Make - A Program for Maintaining Computer Programs"
S. I. Feldman, Bell Laboratories, August 15, 1978
--
Lew Pitcher
"In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
Page 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web