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 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-30 15:03 +0000 |
| Message-ID | <HSIHM.817959$AsA.222853@fx18.iad> |
| In reply to | #173302 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>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:
>>>>
>
>> 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".
Not sure about the assertion, but Unixware 2.1 make has:
static char makefile[] = "makefile",
Makefile[] = "Makefile",
Makeflags[] = "MAKEFLAGS",
RELEASE[] = "RELEASE";
And Unix v8:
$ strings /work/reference/usl/unix/v8/bin/make | grep Makefile
Makefile
s.Makefile
And Unix v7 tries 'makefile' first, if not found, then tries 'Makefile'.
if( !descset )
#ifdef unix
if( rddescf("makefile") ) rddescf("Makefile");
#endif
#ifdef gcos
rddescf("makefile");
#endif
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-30 12:00 -0700 |
| Message-ID | <87fs409wyq.fsf@nosuchdomain.example.com> |
| In reply to | #173302 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 29 Aug 2023 19:22:09 +0000, Kaz Kylheku wrote:
[...]
>> 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".
I wouldn't necessarily call this definitive, but the manual for GNU make
says:
Normally you should call your makefile either `makefile' or
`Makefile'. (We recommend `Makefile' because it appears prominently
near the beginning of a directory listing, right near other important
files such as `README'.) The first name checked, `GNUmakefile', is not
recommended for most makefiles. You should use this name if you have a
makefile that is specific to GNU `make', and will not be understood by
other versions of `make'. Other `make' programs look for `makefile' and
`Makefile', but not `GNUmakefile'.
That's from GNU make 3.75, released in 1996.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-30 20:50 -0700 |
| Message-ID | <86msy7uayk.fsf@linuxsc.com> |
| In reply to | #173302 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > 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. [...] CamelCase is consistent with C syntax; it feels out of place though in terms of common usage. ISTM that CamelCase was never used in C until C++ started using it, which I think started happening because Smalltalk uses camelCase (and CamelCase), and C++ has Smalltalk envy. Feel free to take the above either as just statements of personal opinion or as unsubstantiated beliefs.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 08:12 +0000 |
| Message-ID | <20230831004230.649@kylheku.com> |
| In reply to | #173369 |
On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > >> 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. [...] > > CamelCase is consistent with C syntax; it feels out of place > though in terms of common usage. It isn't "euphonic". "White and black" is also valid English syntax; we prefer to hear "black and white". When we hear "white and black", we wonder, is it a proper name? "White and Black, Barristers and Solicitors" or something? > ISTM that CamelCase was never > used in C until C++ started using it, which I think started > happening because Smalltalk uses camelCase (and CamelCase), and > C++ has Smalltalk envy. Even if the Smalltalk connection is true, the influence is probably by way of the Pascal family languages. These use CamelCase. For instance see the "Turbo Pascal® - Reference Guide" on bitsavers.org. Was the Pascal world afflicted with SmallTalk envy? It's hard to say. But Niklaus Wirth's Pascal report from 1970 already shows hints of the nucleation of CamelCase; it contains instances of capitalized identifiers like Boolean, Power, and whatnot. CamelCase was used in implementing Microsoft Windows, and also MIT XWindow, and in Apple operating systems. Apple notably used Pascal in the 1980s an important systems language. Microsoft's AFX, later renamed MFC, uses CamelCase. This helps it blend in with Win32. ISO C++ doesn't use CamelCase; it has snake case like std::basic_string<>, and static_cast. I don't recall seeing CamelCase in Stroustrup's books like the _C++ Annotated Reference Manual_ (ARM "brown book" co-authored with Margaret Ellis or his other books). I'm looking (in Google Books) inside _C++ Primer_ by Stanley Lippman, Barbara Moo, et al, fifth ed with C++11. All I see is snake_case, though I managed to spy an instance of Camel_snake. In Andrew Koenig's _Accelerated C++_ I see things like Vec, Number and Student_info. But not Student_Info or StudentInfo. Aha! C++ influencer Scott Meyers appears to be a culprit in spreading the practice. Looking into _Effective C++_, I see that it is teeming with Dromedaries and BacTrians. -- 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-01 11:51 -0700 |
| Message-ID | <86jzt9sp61.fsf@linuxsc.com> |
| In reply to | #173381 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >> >>> 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. [...] >> >> CamelCase is consistent with C syntax; it feels out of place >> though in terms of common usage. >> ISTM that CamelCase was never >> used in C until C++ started using it, which I think started >> happening because Smalltalk uses camelCase (and CamelCase), and >> C++ has Smalltalk envy. [various bits of esoterica about C++ and CamelCase] The key point is that CamelCase tends to be relatively common in C++, and not nearly as common in C. All the C++ esoterica is just noise.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-27 00:55 +0100 |
| Message-ID | <87wmxhnyub.fsf@bsb.me.uk> |
| In reply to | #172810 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > 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. Thank you. But I don't really qualify anymore (I indeed I ever did). And, in fact, I was actually thinking rhetorically -- how would I word it to tip the result? I was considering: "is size_t a sound engineering compromise or a dog's breakfast?". > "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. I refer you to David's excellent reply. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 16:17 -0700 |
| Message-ID | <865y4ywycj.fsf@linuxsc.com> |
| In reply to | #172842 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: [..regarding the naming of size_t..] > And, in fact, I was actually thinking rhetorically -- how would > I word it to tip the result? I was considering: "is size_t a > sound engineering compromise or a dog's breakfast?". STOP! You're /both/ right!!! The name size_t is a sound engineering compromise AND a dog's breakfast.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 04:31 -0700 |
| Message-ID | <87h6onfje9.fsf@nosuchdomain.example.com> |
| In reply to | #172742 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
[...]
>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>> would be to call it "multiplymatrixwithvector".
>>
> Well Caesar disagreed.
Let's drop the lengthy discussions of ancient writing systems, shall we?
(And David, please stop encouraging them.)
> Denis Ritchie disagreed.
I doubt that. Dennis Ritchie worked in environments that limited
external identifiers to 6 characters. That's why we have "strcpy",
not because it's easier to read.
[...]
--
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-25 14:06 +0000 |
| Message-ID | <lz2GM.463340$U3w1.382970@fx09.iad> |
| In reply to | #172756 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>[...]
>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>> would be to call it "multiplymatrixwithvector".
>>>
>> Well Caesar disagreed.
>
>Let's drop the lengthy discussions of ancient writing systems, shall we?
>(And David, please stop encouraging them.)
>
>> Denis Ritchie disagreed.
>
>I doubt that. Dennis Ritchie worked in environments that limited
>external identifiers to 6 characters. That's why we have "strcpy",
>not because it's easier to read.
IIRC it was eight characters. The Oracle RDBMS when I worked on
it in the 90's limited all function names to 8 characters for
compatability with the older compilers/linkers. Which made for very
cryptic names.
v7 ld.c:
/* symbol management */
struct symbol {
char sname[8];
char stype;
char spare;
int svalue;
};
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2023-08-25 15:35 +0000 |
| Message-ID | <ucahoo$1a6u$1@dont-email.me> |
| In reply to | #172764 |
On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: >>[...] >>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong - >>>> would be to call it "multiplymatrixwithvector". >>>> >>> Well Caesar disagreed. >> >>Let's drop the lengthy discussions of ancient writing systems, shall we? >>(And David, please stop encouraging them.) >> >>> Denis Ritchie disagreed. >> >>I doubt that. Dennis Ritchie worked in environments that limited >>external identifiers to 6 characters. That's why we have "strcpy", >>not because it's easier to read. > > IIRC it was eight characters. In Chapter 2 of K&R's "The C Programing Language" (1st edition), the authors discuss the size of names: "Only the first eight characters of an internal name are significant, although more may be used. For external names, such a function names and external variables, the number may be less than eight, because external names are used by various assemblers and loaders." They go on to list (in Appendix A, "C Reference Manual") the limits (by implementation) of external identifiers: "DEC PDP-11 7 characters, 2 cases Honeywell 6600 6 characters, 1 case IBM 360/370 7 characters, 1 case Interdata 8/32 8 characters, 2 cases" and reiterate that "No more than the first eight characters are significant, although more may be used." So, eight characters was the max for K&R C, with implementations limiting it to less in many cases. HTH -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 11:45 -0700 |
| Message-ID | <87cyzbezaz.fsf@nosuchdomain.example.com> |
| In reply to | #172766 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>>>[...]
>>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>>>> would be to call it "multiplymatrixwithvector".
>>>>>
>>>> Well Caesar disagreed.
>>>
>>>Let's drop the lengthy discussions of ancient writing systems, shall we?
>>>(And David, please stop encouraging them.)
>>>
>>>> Denis Ritchie disagreed.
>>>
>>>I doubt that. Dennis Ritchie worked in environments that limited
>>>external identifiers to 6 characters. That's why we have "strcpy",
>>>not because it's easier to read.
>>
>> IIRC it was eight characters.
>
> In Chapter 2 of K&R's "The C Programing Language" (1st edition),
> the authors discuss the size of names:
> "Only the first eight characters of an internal name are
> significant, although more may be used. For external names,
> such a function names and external variables, the number may
> be less than eight, because external names are used by various
> assemblers and loaders."
>
> They go on to list (in Appendix A, "C Reference Manual") the
> limits (by implementation) of external identifiers:
> "DEC PDP-11 7 characters, 2 cases
> Honeywell 6600 6 characters, 1 case
> IBM 360/370 7 characters, 1 case
> Interdata 8/32 8 characters, 2 cases"
> and reiterate that
> "No more than the first eight characters are significant,
> although more may be used."
>
> So, eight characters was the max for K&R C, with implementations
> limiting it to less in many cases.
For K&R C, the limit was 8 for *internal* identifiers. The limit for
external identifiers (like strcpy) was what we'd now call
implementation-defined, with at least one implementation imposing a
limit of 6 (and not distinguishing between foobar and FOOBAR).
--
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 | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2023-08-25 20:06 +0000 |
| Message-ID | <ucb1ji$4q37$1@dont-email.me> |
| In reply to | #172778 |
On Fri, 25 Aug 2023 11:45:24 -0700, Keith Thompson wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Fri, 25 Aug 2023 14:06:09 +0000, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>>>>[...]
>>>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>>>>> would be to call it "multiplymatrixwithvector".
>>>>>>
>>>>> Well Caesar disagreed.
>>>>
>>>>Let's drop the lengthy discussions of ancient writing systems, shall we?
>>>>(And David, please stop encouraging them.)
>>>>
>>>>> Denis Ritchie disagreed.
>>>>
>>>>I doubt that. Dennis Ritchie worked in environments that limited
>>>>external identifiers to 6 characters. That's why we have "strcpy",
>>>>not because it's easier to read.
>>>
>>> IIRC it was eight characters.
>>
>> In Chapter 2 of K&R's "The C Programing Language" (1st edition),
>> the authors discuss the size of names:
>> "Only the first eight characters of an internal name are
>> significant, although more may be used. For external names,
>> such a function names and external variables, the number may
>> be less than eight, because external names are used by various
>> assemblers and loaders."
>>
>> They go on to list (in Appendix A, "C Reference Manual") the
>> limits (by implementation) of external identifiers:
>> "DEC PDP-11 7 characters, 2 cases
>> Honeywell 6600 6 characters, 1 case
>> IBM 360/370 7 characters, 1 case
>> Interdata 8/32 8 characters, 2 cases"
>> and reiterate that
>> "No more than the first eight characters are significant,
>> although more may be used."
>>
>> So, eight characters was the max for K&R C, with implementations
>> limiting it to less in many cases.
>
> For K&R C, the limit was 8 for *internal* identifiers.
I believe that the limit was 8 for /all/ identifiers, with two caveats
1) names could be longer, but only the first 8 characters were
significant, and
2) extern identifiers were often limited by the operating environment
(likely the limits of the assembler[1] or linker) to less than the 8
significant characters that the parser recognized.
> The limit for
> external identifiers (like strcpy) was what we'd now call
> implementation-defined, with at least one implementation imposing a
> limit of 6 (and not distinguishing between foobar and FOOBAR).
While I agree that the length of extern identifiers would have been
called "implementation defined", I don't think that the lengths could
exceed the 8 significant character maximum imposed by the compiler.
In other words, a K&R C compiler wouldn't allow (for instance) a 10
significant character extern identifier.
[1] Section 2.1 "Identifiers" of the "UNIX Assembler Reference Manual"
says that
"An identifier consists of a sequence of alphanumeric characters
... of which the first may not be numeric. Only the first eight
characters are significant."
The toolchain was source -> compile -> assemble -> link -> binary
and the assembler was (and usually still is) a critical part of
that chain. If the /assembler/ limits labels to 8 significant
characters, then the language has to either accomodate that
limitation, or find a kluge around it. It looks like Ritchie
et al stuck with the assembler limits here.
Just my 2 cents worth.
--
Lew Pitcher
"In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 19:35 -0700 |
| Message-ID | <a196bf8d-9613-4ff3-ac60-6c8e192b8c7an@googlegroups.com> |
| In reply to | #172756 |
On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: > [...] > >> The only thing /wrong/ - and pretty much everyone thinks it is wrong - > >> would be to call it "multiplymatrixwithvector". > >> > > Well Caesar disagreed. > Let's drop the lengthy discussions of ancient writing systems, shall we? > (And David, please stop encouraging them.) > > > Denis Ritchie disagreed. > > I doubt that. Dennis Ritchie worked in environments that limited > external identifiers to 6 characters. That's why we have "strcpy", > not because it's easier to read. > However that's not the explanation for isdigit() rather than is_digit().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 19:55 -0700 |
| Message-ID | <87v8d2eclx.fsf@nosuchdomain.example.com> |
| In reply to | #172796 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>> [...]
>> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>> >> would be to call it "multiplymatrixwithvector".
>> >>
>> > Well Caesar disagreed.
>> Let's drop the lengthy discussions of ancient writing systems, shall we?
>> (And David, please stop encouraging them.)
>>
>> > Denis Ritchie disagreed.
>>
>> I doubt that. Dennis Ritchie worked in environments that limited
>> external identifiers to 6 characters. That's why we have "strcpy",
>> not because it's easier to read.
>>
> However that's not the explanation for isdigit() rather than is_digit().
I should have said 6 *significant* characters, so is_digit and
is_digest might be treated as the same identifier. The early limits
on external identifiers forced terse names for library functions.
Adding underscores for only some function names would not have been
helpful. (I haven't checked whether any standard library function
names in C90 have underscores, because I don't care that much.)
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 20:26 -0700 |
| Message-ID | <353beb7c-0502-44de-8a2b-4890d6efe8cdn@googlegroups.com> |
| In reply to | #172797 |
On Saturday, 26 August 2023 at 03:55:53 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > However that's not the explanation for isdigit() rather than is_digit(). > I should have said 6 *significant* characters, so is_digit and > is_digest might be treated as the same identifier. The early limits > on external identifiers forced terse names for library functions. > Adding underscores for only some function names would not have been > helpful. (I haven't checked whether any standard library function > names in C90 have underscores, because I don't care that much.) > What I said to David Brown was that standard library functions were the most commonly called functions in C code, and were all written in the style I am recommending. He responded by pointing out that some rarely used non-function identiifers, not I think in Ritchie's original version of C, have underscores. So only half understanding the point. Underscores have been introduced for a handful of new time and date fucntions which have "restart" options, indicated y a "_r" suffix. Terseness due to the limitations of compilers and linkers at the time is part of the explanation, of course. But it could easily have been is_digit() rather than "isdigit", and my point stands.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-26 19:24 +0200 |
| Message-ID | <ucdcfu$mj8h$2@dont-email.me> |
| In reply to | #172802 |
On 26/08/2023 05:26, Malcolm McLean wrote: > On Saturday, 26 August 2023 at 03:55:53 UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> However that's not the explanation for isdigit() rather than is_digit(). >> I should have said 6 *significant* characters, so is_digit and >> is_digest might be treated as the same identifier. The early limits >> on external identifiers forced terse names for library functions. >> Adding underscores for only some function names would not have been >> helpful. (I haven't checked whether any standard library function >> names in C90 have underscores, because I don't care that much.) >> > What I said to David Brown was that standard library functions were the > most commonly called functions in C code, and were all written in the > style I am recommending. He responded by pointing out that some > rarely used non-function identiifers, not I think in Ritchie's original > version of C, have underscores. So only half understanding the point. I'm sure Keith read my post, and so was better able to understand it than your inaccurate summary. > > Underscores have been introduced for a handful of new time and date > fucntions which have "restart" options, indicated y a "_r" suffix. > > Terseness due to the limitations of compilers and linkers at the time > is part of the explanation, of course. But it could easily have been > is_digit() rather than "isdigit", and my point stands. Ifyousaysoitmustbecorrectbecauseitisclearlyeasiertoreadwhentherearenowordbreaks.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-26 02:52 -0700 |
| Message-ID | <66653005-66fa-4a89-8b1f-0b415fb7e8ean@googlegroups.com> |
| In reply to | #172756 |
On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: > [...] > >> The only thing /wrong/ - and pretty much everyone thinks it is wrong - > >> would be to call it "multiplymatrixwithvector". > >> > > Well Caesar disagreed. > Let's drop the lengthy discussions of ancient writing systems, shall we? > (And David, please stop encouraging them.) > For about two thousand years, text was written without spaces. Any rational person, to whom this was pointed out, would accept that that is prima facie evidence that it is not that difficult to read. However David Brown has got to try to make out that the reason the style was adopted was to make it harder for slaves to read confidential documents. It's beyond absurd.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-26 14:10 +0000 |
| Message-ID | <yJnGM.142651$ftCb.40495@fx34.iad> |
| In reply to | #172809 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: >> [...] >> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong - >> >> would be to call it "multiplymatrixwithvector". >> >> >> > Well Caesar disagreed. >> Let's drop the lengthy discussions of ancient writing systems, shall we? >> (And David, please stop encouraging them.) >> >For about two thousand years, text was written without spaces. Any rational >person, to whom this was pointed out, would accept that that is prima facie >evidence that it is not that difficult to read. The sources I found indicate that it wasn't intended to be read by anyone other than the person who wrote it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-26 22:54 -0700 |
| Message-ID | <03a4b2f0-92a7-4652-86f6-66f7d5cf8853n@googlegroups.com> |
| In reply to | #172813 |
On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > >On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: > >> [...] > >> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong - > >> >> would be to call it "multiplymatrixwithvector". > >> >> > >> > Well Caesar disagreed. > >> Let's drop the lengthy discussions of ancient writing systems, shall we? > >> (And David, please stop encouraging them.) > >> > >For about two thousand years, text was written without spaces. Any rational > >person, to whom this was pointed out, would accept that that is prima facie > >evidence that it is not that difficult to read. > The sources I found indicate that it wasn't intended to be read by anyone > other than the person who wrote it. > Just goes to show that you can believe everything you read. Do you think that is remotely plausible?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 18:39 +0200 |
| Message-ID | <ucfu89$18cb9$1@dont-email.me> |
| In reply to | #172861 |
On 27/08/2023 07:54, Malcolm McLean wrote: > On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: >>>> [...] >>>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong - >>>>>> would be to call it "multiplymatrixwithvector". >>>>>> >>>>> Well Caesar disagreed. >>>> Let's drop the lengthy discussions of ancient writing systems, shall we? >>>> (And David, please stop encouraging them.) >>>> >>> For about two thousand years, text was written without spaces. Any rational >>> person, to whom this was pointed out, would accept that that is prima facie >>> evidence that it is not that difficult to read. >> The sources I found indicate that it wasn't intended to be read by anyone >> other than the person who wrote it. >> > Just goes to show that you can believe everything you read. That's a non-sequitur, as well as almost certainly a typo, making your non-grammatical almost-sentence say the opposite of what you intended. Wikipedia has a list of logical fallacies used in arguments. You've gone through quite a few of them so far - are you trying to get them all ticked off in one thread? > Do you think that is remotely plausible? Often, but certainly not always, things were written with the intention of being read by the author. This, of course, still applies today - much of what is written is notes for your own benefit, thus it is not a problem that many people's handwriting is practically illegible to others. Second on the list of perspective readers is probably teachers, and third would be "nobody" (we all know that most likely no one will ever really read the documentation we write for our software). Writing things that are actually read by anyone else has always been a minority of writing (even though it is, obviously, a very important part of writing).
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web