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 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 18:41 +0200 |
| Message-ID | <ucfuck$18cb9$2@dont-email.me> |
| In reply to | #172862 |
On 27/08/2023 08:08, Malcolm McLean wrote: > On Saturday, 26 August 2023 at 18:31:21 UTC+1, David Brown wrote: >> I enjoy talking about history, and I happen to know a bit about writing >> systems - modern and outdated. I had hoped, since you know a bit of >> Hebrew and have looked at old texts, that I might have learned something >> new. But I was wrong - you have some basic knowledge combined with some >> flat-earth ideas, and you haven't actually bothered reading what I >> wrote. So time to stop, I think. >> > I know. But it irritates Keith. And it's very tangential to C, so he has a case. I fully agree. I expect it annoys more than just Keith, though he is often the one open enough to talk about it. So let's stop talking about it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 13:38 +0200 |
| Message-ID | <uca3sh$p9c$1@dont-email.me> |
| In reply to | #172742 |
On 25/08/2023 10:37, Malcolm McLean wrote:
> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>> On 24/08/2023 16:50, Malcolm McLean wrote:
>>> On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote:
>>>> On 24/08/2023 05:53, Malcolm McLean wrote:
>>>>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote:
>>>>>>
>>
>> There are good historical reasons for why named parameters are not
>> common in older languages, but are more common in newer ones. And there
>> are good technical reasons why they would be difficult to introduce to C
>> as an afterthought. But I agree with you that they can be helpful and
>> improve code readability, in languages that support them.
>>
> I don't really see what the technical problem is. The header would have to
> contain the names of the parameters (most do already). Then instead
> of putting parameter 1 into register a and parameter 2 into register b,
> the compiler matches them up. If its void foo(int x, int y) and the
> call is foo(y=1, x=2), then the compiler puts a 2 into register a and a 1
> into register b.
> I haven't tried to modify a compiler to do this so there might be something I
> haven't thought of. But it would be a fairly simple, contained change with no
> implications for the linker.
The key technical problem for C is that the parameter names are not part
of the signature of the function. It is not uncommon for declarations
to have missing parameter names, or different names from those uses in
the definition of the function. (Sometimes there are good reasons for
this, sometimes it is laziness.) If a function is defined as "void
foo(int a, int b) { .. }", but the declaration used to call it has "void
foo(int b, int a);", then how should named parameters be resolved?
Any resolution here would place restrictions on which functions could
support named parameters - such as consistent declarations and
definitions, but it would be impossible (in general) to check them.
>>>>> Standard library functions are the most commonly called functions in C code,
>>>>> and are always named in my style.
>>>> No, they are not. Names with all lower case and no word separation are
>>>> common in the C standard library for short identifiers (like "strlen"),
>>>> while underscores are common for longer identifiers (like
>>>> "memory_order_relaxed").
>>>>
>>>> It would be nice if you were to check this kind of thing before making
>>>> pointlessly incorrect claims.
>>>>
>>> Ok. So I checked. Every single function in the standard library is written in
>>> my style, with the exception of a handful which take an _r suffix (e.g. asctime_r).
>>> I think these are recent additions.
>> I am looking at Annex B of the C standards. There are lots of short
>> identifiers without word breaks, as I said - such as "isdigit". This is
>> especially true of older function names, which come from a background of
>> the days of assemblers and linkers with very limited characters and
>> identifier lengths. This is part of the reason for some abbreviations
>> being shorter than you (or I) might have liked. (We should be grateful
>> that they use small letters and not all-caps!) There are maybe a dozen
>> at most that have more than 10 characters, such as "isgreaterequal".
>>
>> Once you get to longer names, they are split with underscore - it is
>> "atomic_flag_clear_explicit", not "atomicflagclearexplicit", which would
>> be illegible. The type identifiers have underscores, the macros for
>> limits, atomic memory access types, file IO constants - all have
>> underscores. They are all over the place!
>>
>> No, you have /not/ checked - unless you think I was talking about K&R C
>> and restricting identifiers to function names only.
>>
> I said every function. You were talking about identifiers.
I was always talking about identifiers - why on earth would we be
restricting the kind of identifier? Function names are not the only
identifiers that need to be read!
> Of course size_t has
> an underscore. Everyone knows that. And most people agree that it is horrible.
No, most people do /not/ agree that. /Some/ people think it is
horrible, others like it, and others don't really care.
> And it wasn't part of C as orginally designed.
This is a C group, for people who program in C. History can be
fascinating - both you and I are interested in it. People program in
C99 or C11, not pre-K&R C. History is only of relevance when comparing
older identifiers that had no underscores with newer ones that /have/
underscores to improve readability.
It is incomprehensible to me that you still don't understand this. Even
if you were right (which you are not) in your belief that the C standard
does not use underscores, it would not change the very simple fact that
long run-together names are harder to read than those with clear word
divisions. They are so much easier to read that it totally outweighs
any real or imagined thoughts of consistency.
>>
>> And the clear pattern of underscores being more common in newer
>> identifiers should be a clue to you - just as the world moved on and
>> embraced word divisions in Latin prose, so the programming world moved
>> on and embraced word divisions in identifier names. We no longer
>> restrict our filenames to 8.3 patterns - we no longer write highly
>> condensed identifiers without word divisions.
>>
> Ritchie was a genius who knew how to design a programming language.
> The people who came after him were lesser men.
Hero worship is almost always a sign that you haven't thought things
through yourself.
Ritchie made a pretty good language for his needs at the time, with the
technology of the time, the understanding of programming at the time,
and the fads and habits of the time. A combination of good design,
luck, and the work of people afterwards, means that we still use the
distant descendent of his original language. C has never been, and
never will be, a "perfect" language, for any purpose. It succeeds
because it is good enough for many things, maintaining its usefulness
today through momentum despite alternative languages that are better for
at least some purposes.
>>
>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>> would be to call it "multiplymatrixwithvector".
>>
> Well Caesar disagreed.
Caesar didn't write programs.
> Denis Ritchie disagreed.
Ritchie didn't use long identifiers much - and when he did, he used
underscores.
Not that either of these appeals to authority have any relevance.
> Unfortunately I can't find it, but some reasearch on human-readable urls disagreed.
You'll not find it, because long URLs without any breaks are not
human-readable. And even if they were, they are not program identifiers.
It's true that there are some domain names that have longer run-together
names (some have dots or hyphens as word separators). For the most
part, you don't type these - you click on them. And even if you type
them once, your browser remembers them for later. They are generally
considered risky if the site is popular, because they are easy prey for
scammers and malware peddlers to register domains that are a typo away.
>
> Whilst all you can offer is "I disagree". But you automatically disagree with things
> some people say. So how much weight should we give to that?
I don't automatically disagree with other people. But I rarely write
"me too!" posts about things that are generally agreed upon -
discussions thrive on disagreement. Would you rather we chatted about
the weather or the price of bread, or complained about the youth of today?
>>
>> Think of it as an optimisation problem - different characteristics are
>> given different weights, and your job as programmer is to pick the
>> identifier that gives the best total outcome. Consistency has weight 1,
>> readability has weight 10.
>>
> Cnsistency aids readability. Readbility of a single identifier aids readability of
> that identifier, but may damage the readability of the text as a whole, largely
> because it breaks consistency.
> But consistency isn't an absolute, I agree there.
>>
>>> Yes. What I am saying is that for the idea that the letters were God-given
>>> whilst the spaces were man-made to take root, the society must have been
>>> familiar with text written continuously.
>>>
>> No - again, you have no basis for that conclusion.
>>
>> And you could equally logically have concluded that society must have
>> been familiar with text written without letters, only with spaces. When
>> the same logic can be used to "prove" something that silly, you should
>> be suspicious of your arguments.
>>
> Are you advancing an objection that weak?
I am throwing out your weak reasoning.
>>
>> I think part of your confusion comes from your idea that the Torah is a
>> written work, and that written works consist of letters and spaces.
>> This is wrong on both accounts.
>>
>> First, the Torah is a spoken work. It was spoken long before it was
>> written down. Rabbis memorize it - they read the scrolls as a memory
>> aid. The letters of the Torah come from the spoken word, and spoken
>> word does not have space characters. Kabbalah comes from the oral
>> tradition, not the written version of the Torah (though it moved and
>> adapted to the written work).
>>
> What was important to the Jews was that it was written.
No, it was originally an oral tradition. /Then/ it was written down,
and the writings became the way to ensure the oral versions did not
change (much) over time.
> God's word, written
> down.
Given /orally/ by God, to Moses. (This is according to Jewish tradition
and theology, rather than reality.) It was written down later (in
different bits, at different times).
> Of course modern scholars are sceptical of that. But Jews themselves
> didn't believe that Torah had come about by a process of redaction by scribes
> working from oral tradtions in Babylon.
Jewish tradition says the Torah as we know it today was put together by
Ezra from previous writings.
And none of the written Torah, as far as anyone knows, was written
without word separation.
>>
>> Secondly, the writing consists of putting the letters down on the page.
>> Spacing is like the manuscript material and ink, or the script - it is
>> not the text, but it is other things needed to make the text legible.
>> Indeed, spacing is "lower" than the paper and ink, because it consists
>> of nothing at all.
>>
>> You do not need to have read texts with no nothingness in order to think
>> that added nothingness is not of mystical importance. There are not
>> aspects of the Torah scrolls divided into "God-given" and "man-made" -
>> that is a false dichotomy. There is the "God-given" words and letters,
>> and who cares about any of the rest of it?
>>
> The letters are given by God, the spaces added by man. So yes, there is a
> distinction. It doesn't matter much, but it does matter. As you yourself
> pointed out, when searching for "Torah codes" the spaces are excluded.
> Since they were not given by God, a similar search which included spaces
> would be invalid.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 11:59 -0700 |
| Message-ID | <878r9zeynn.fsf@nosuchdomain.example.com> |
| In reply to | #172757 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/08/2023 10:37, Malcolm McLean wrote:
>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
[...]
>>> There are good historical reasons for why named parameters are not
>>> common in older languages, but are more common in newer ones. And there
>>> are good technical reasons why they would be difficult to introduce to C
>>> as an afterthought. But I agree with you that they can be helpful and
>>> improve code readability, in languages that support them.
>>>
>> I don't really see what the technical problem is. The header would have to
>> contain the names of the parameters (most do already). Then instead
>> of putting parameter 1 into register a and parameter 2 into register b,
>> the compiler matches them up. If its void foo(int x, int y) and the
>> call is foo(y=1, x=2), then the compiler puts a 2 into register a and a 1
>> into register b.
>> I haven't tried to modify a compiler to do this so there might be something I
>> haven't thought of. But it would be a fairly simple, contained change with no
>> implications for the linker.
>
> The key technical problem for C is that the parameter names are not
> part of the signature of the function. It is not uncommon for
> declarations to have missing parameter names, or different names from
> those uses in the definition of the function. (Sometimes there are
> good reasons for this, sometimes it is laziness.) If a function is
> defined as "void foo(int a, int b) { .. }", but the declaration used
> to call it has "void foo(int b, int a);", then how should named
> parameters be resolved?
>
> Any resolution here would place restrictions on which functions could
> support named parameters - such as consistent declarations and
> definitions, but it would be impossible (in general) to check them.
Any parameter names in a call would just have to be consistent with the
names in the visible prototype. I don't see a problem.
Using the "name=value" syntax would conflict with the use of an
assignment expression as an argument, so some new syntax would have to
be invented.
I know, we could reuse the "static" keyword! 8-)}
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-25 19:34 -0400 |
| Message-ID | <AUaGM.174236$JG_b.91752@fx39.iad> |
| In reply to | #172781 |
On 8/25/23 2:59 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/08/2023 10:37, Malcolm McLean wrote:
>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
> [...]
>>>> There are good historical reasons for why named parameters are not
>>>> common in older languages, but are more common in newer ones. And there
>>>> are good technical reasons why they would be difficult to introduce to C
>>>> as an afterthought. But I agree with you that they can be helpful and
>>>> improve code readability, in languages that support them.
>>>>
>>> I don't really see what the technical problem is. The header would have to
>>> contain the names of the parameters (most do already). Then instead
>>> of putting parameter 1 into register a and parameter 2 into register b,
>>> the compiler matches them up. If its void foo(int x, int y) and the
>>> call is foo(y=1, x=2), then the compiler puts a 2 into register a and a 1
>>> into register b.
>>> I haven't tried to modify a compiler to do this so there might be something I
>>> haven't thought of. But it would be a fairly simple, contained change with no
>>> implications for the linker.
>>
>> The key technical problem for C is that the parameter names are not
>> part of the signature of the function. It is not uncommon for
>> declarations to have missing parameter names, or different names from
>> those uses in the definition of the function. (Sometimes there are
>> good reasons for this, sometimes it is laziness.) If a function is
>> defined as "void foo(int a, int b) { .. }", but the declaration used
>> to call it has "void foo(int b, int a);", then how should named
>> parameters be resolved?
>>
>> Any resolution here would place restrictions on which functions could
>> support named parameters - such as consistent declarations and
>> definitions, but it would be impossible (in general) to check them.
>
> Any parameter names in a call would just have to be consistent with the
> names in the visible prototype. I don't see a problem.
>
> Using the "name=value" syntax would conflict with the use of an
> assignment expression as an argument, so some new syntax would have to
> be invented.
>
> I know, we could reuse the "static" keyword! 8-)}
>
> [...]
>
As far as I know, C could still adopt the use of : for this purpose,
like Bart's language does.
I can't think of anything that this would get confused with.
I think the biggest thing this would require is that every standard
library function would need to have the name used for its parameter
defined (or the standard say you can't portably use them with the
standard library functions.
I think the biggest issue there is that the names would need to be
somewhat ugle as they would need to be in the implementation reserved
namespace, as anything in the user namespace might be a macro
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 17:12 -0700 |
| Message-ID | <874jkmfyqp.fsf@nosuchdomain.example.com> |
| In reply to | #172787 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/25/23 2:59 PM, Keith Thompson wrote:
[...]
>> Any parameter names in a call would just have to be consistent with
>> the names in the visible prototype. I don't see a problem. Using
>> the "name=value" syntax would conflict with the use of an assignment
>> expression as an argument, so some new syntax would have to be
>> invented.
>>
>> I know, we could reuse the "static" keyword! 8-)}
>> [...]
>>
>
> As far as I know, C could still adopt the use of : for this purpose,
> like Bart's language does.
>
> I can't think of anything that this would get confused with.
Nor can I.
> I think the biggest thing this would require is that every standard
> library function would need to have the name used for its parameter
> defined (or the standard say you can't portably use them with the
> standard library functions.
The standard already shows parameter names for library functions, though
they're not currently semantically meaningful. If this feature were
added in a future standard, the same names could be used.
> I think the biggest issue there is that the names would need to be
> somewhat ugle as they would need to be in the implementation reserved
> namespace, as anything in the user namespace might be a macro
I'm not sure that would be much of a problem. For example, given
char *strcpy(char * restrict s1,
const char * restrict s2);
and a call like:
strcpy(s1: foo, s2: bar);
the lookup for the names s1 and s2 would refer only to the named
parameters of the called function. If you define a macro "s1", you
simply get whatever it expands to.
Another issue is that library functions can additionally be defined as
macros. One solution would be to say that if you use a named parameter
association, it bypasses the macro and calls the function -- which could
break some contrived macro invocations. Another would be to allow named
parameter associations for macro invocations as well as function calls.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-26 01:44 +0100 |
| Message-ID | <878r9ypr8v.fsf@bsb.me.uk> |
| In reply to | #172788 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Another issue is that library functions can additionally be defined as > macros. One solution would be to say that if you use a named parameter > association, it bypasses the macro and calls the function -- which could > break some contrived macro invocations. Another would be to allow named > parameter associations for macro invocations as well as function > calls. Or, if you implement it for macros, you don't need to implement it for functions. It's probably best to do both, but one can image a trial implementation using just the pre-processor. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-25 22:18 -0400 |
| Message-ID | <yhdGM.457100$xMqa.361350@fx12.iad> |
| In reply to | #172788 |
On 8/25/23 8:12 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/25/23 2:59 PM, Keith Thompson wrote: > [...] >>> Any parameter names in a call would just have to be consistent with >>> the names in the visible prototype. I don't see a problem. Using >>> the "name=value" syntax would conflict with the use of an assignment >>> expression as an argument, so some new syntax would have to be >>> invented. >>> >>> I know, we could reuse the "static" keyword! 8-)} >>> [...] >>> >> >> As far as I know, C could still adopt the use of : for this purpose, >> like Bart's language does. >> >> I can't think of anything that this would get confused with. > > Nor can I. > >> I think the biggest thing this would require is that every standard >> library function would need to have the name used for its parameter >> defined (or the standard say you can't portably use them with the >> standard library functions. > > The standard already shows parameter names for library functions, though > they're not currently semantically meaningful. If this feature were > added in a future standard, the same names could be used. > >> I think the biggest issue there is that the names would need to be >> somewhat ugle as they would need to be in the implementation reserved >> namespace, as anything in the user namespace might be a macro > > I'm not sure that would be much of a problem. For example, given > char *strcpy(char * restrict s1, > const char * restrict s2); > and a call like: > strcpy(s1: foo, s2: bar); > the lookup for the names s1 and s2 would refer only to the named > parameters of the called function. If you define a macro "s1", you > simply get whatever it expands to. > > Another issue is that library functions can additionally be defined as > macros. One solution would be to say that if you use a named parameter > association, it bypasses the macro and calls the function -- which could > break some contrived macro invocations. Another would be to allow named > parameter associations for macro invocations as well as function calls. > The problem would be needing to completely throw out the existing phases of translation. For instance, a translation unit is allowed to have defined something like: #define s1 x+y( before including the system headers. so to ignore that macro in that context, would need a complete change in how the preprocessor works. The fact that s1 is in the user namespace says the header can't actually have used that name. This is why actual headers are filled with names that begin with underscores
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 19:58 -0700 |
| Message-ID | <87r0nqecgu.fsf@nosuchdomain.example.com> |
| In reply to | #172794 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/25/23 8:12 PM, Keith Thompson wrote:
[...]
>> Another issue is that library functions can additionally be defined
>> as macros. One solution would be to say that if you use a named
>> parameter association, it bypasses the macro and calls the function
>> -- which could break some contrived macro invocations. Another would
>> be to allow named parameter associations for macro invocations as
>> well as function calls.
>
> The problem would be needing to completely throw out the existing
> phases of translation.
>
> For instance, a translation unit is allowed to have defined something like:
>
> #define s1 x+y(
>
> before including the system headers. so to ignore that macro in that
> context, would need a complete change in how the preprocessor works.
>
> The fact that s1 is in the user namespace says the header can't
> actually have used that name.
>
> This is why actual headers are filled with names that begin with underscores
My suggestion is that if you define s1 as a macro, something like
strcpy(s1: dst, s2: src);
would simply expand the macro, and very likely fail to compile. I don't
think it's likely to be a problem in practice. No existing code uses
the new feature, so in that sense it would be backward compatible.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-25 23:07 -0400 |
| Message-ID | <f0eGM.457102$xMqa.276001@fx12.iad> |
| In reply to | #172798 |
On 8/25/23 10:58 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/25/23 8:12 PM, Keith Thompson wrote: > [...] >>> Another issue is that library functions can additionally be defined >>> as macros. One solution would be to say that if you use a named >>> parameter association, it bypasses the macro and calls the function >>> -- which could break some contrived macro invocations. Another would >>> be to allow named parameter associations for macro invocations as >>> well as function calls. >> >> The problem would be needing to completely throw out the existing >> phases of translation. >> >> For instance, a translation unit is allowed to have defined something like: >> >> #define s1 x+y( >> >> before including the system headers. so to ignore that macro in that >> context, would need a complete change in how the preprocessor works. >> >> The fact that s1 is in the user namespace says the header can't >> actually have used that name. >> >> This is why actual headers are filled with names that begin with underscores > > My suggestion is that if you define s1 as a macro, something like > strcpy(s1: dst, s2: src); > would simply expand the macro, and very likely fail to compile. I don't > think it's likely to be a problem in practice. No existing code uses > the new feature, so in that sense it would be backward compatible. > The problem is that the standard way the system header is defined, is that it will also use that name, and the system header won't compile, which isn't conforming behavior. While the implementtion doesn't need to store the system headers as normal include files, it is a very common way to define them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 21:17 -0700 |
| Message-ID | <87il92e8tr.fsf@nosuchdomain.example.com> |
| In reply to | #172800 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/25/23 10:58 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 8/25/23 8:12 PM, Keith Thompson wrote:
>> [...]
>>>> Another issue is that library functions can additionally be defined
>>>> as macros. One solution would be to say that if you use a named
>>>> parameter association, it bypasses the macro and calls the function
>>>> -- which could break some contrived macro invocations. Another would
>>>> be to allow named parameter associations for macro invocations as
>>>> well as function calls.
>>>
>>> The problem would be needing to completely throw out the existing
>>> phases of translation.
>>>
>>> For instance, a translation unit is allowed to have defined something like:
>>>
>>> #define s1 x+y(
>>>
>>> before including the system headers. so to ignore that macro in that
>>> context, would need a complete change in how the preprocessor works.
>>>
>>> The fact that s1 is in the user namespace says the header can't
>>> actually have used that name.
>>>
>>> This is why actual headers are filled with names that begin with underscores
>> My suggestion is that if you define s1 as a macro, something like
>> strcpy(s1: dst, s2: src);
>> would simply expand the macro, and very likely fail to compile. I don't
>> think it's likely to be a problem in practice. No existing code uses
>> the new feature, so in that sense it would be backward compatible.
>>
>
> The problem is that the standard way the system header is defined, is
> that it will also use that name, and the system header won't compile,
> which isn't conforming behavior.
>
> While the implementtion doesn't need to store the system headers as
> normal include files, it is a very common way to define them.
Hmm. The standard could say that if you define a parameter name as an
object-like macro before including a header that declares a function
with that parameter, the behavior is undefined. In other words,
standard parameter names would be reserved, but in fewer contexts than
standard function names. Since parameter names are lowercase, there
shouldn't be a lot of code using them as macros.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 10:12 -0400 |
| Message-ID | <eLnGM.170688$8_8a.16135@fx48.iad> |
| In reply to | #172804 |
On 8/26/23 12:17 AM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/25/23 10:58 PM, Keith Thompson wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >>>> On 8/25/23 8:12 PM, Keith Thompson wrote: >>> [...] >>>>> Another issue is that library functions can additionally be defined >>>>> as macros. One solution would be to say that if you use a named >>>>> parameter association, it bypasses the macro and calls the function >>>>> -- which could break some contrived macro invocations. Another would >>>>> be to allow named parameter associations for macro invocations as >>>>> well as function calls. >>>> >>>> The problem would be needing to completely throw out the existing >>>> phases of translation. >>>> >>>> For instance, a translation unit is allowed to have defined something like: >>>> >>>> #define s1 x+y( >>>> >>>> before including the system headers. so to ignore that macro in that >>>> context, would need a complete change in how the preprocessor works. >>>> >>>> The fact that s1 is in the user namespace says the header can't >>>> actually have used that name. >>>> >>>> This is why actual headers are filled with names that begin with underscores >>> My suggestion is that if you define s1 as a macro, something like >>> strcpy(s1: dst, s2: src); >>> would simply expand the macro, and very likely fail to compile. I don't >>> think it's likely to be a problem in practice. No existing code uses >>> the new feature, so in that sense it would be backward compatible. >>> >> >> The problem is that the standard way the system header is defined, is >> that it will also use that name, and the system header won't compile, >> which isn't conforming behavior. >> >> While the implementtion doesn't need to store the system headers as >> normal include files, it is a very common way to define them. > > Hmm. The standard could say that if you define a parameter name as an > object-like macro before including a header that declares a function > with that parameter, the behavior is undefined. In other words, > standard parameter names would be reserved, but in fewer contexts than > standard function names. Since parameter names are lowercase, there > shouldn't be a lot of code using them as macros. > Yes, they could, and break the backwards compatibility rule that has been a fundamental rule for the history of the standard. Yes, the common coding practice of UPPER CASE for macros limits the damage, that common coding practice is NOT a "rule", so can't be relied on. The problem is that there are people who don't follow that rule, and their code could get broken.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-26 15:13 -0700 |
| Message-ID | <87a5ude9kw.fsf@nosuchdomain.example.com> |
| In reply to | #172814 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/26/23 12:17 AM, Keith Thompson wrote:
[...]
>> Hmm. The standard could say that if you define a parameter name as
>> an object-like macro before including a header that declares a
>> function with that parameter, the behavior is undefined. In other
>> words, standard parameter names would be reserved, but in fewer
>> contexts than standard function names. Since parameter names are
>> lowercase, there shouldn't be a lot of code using them as macros.
>
> Yes, they could, and break the backwards compatibility rule that has
> been a fundamental rule for the history of the standard.
No major edition of the standard has strictly followed that rule.
`main() { printf("hello world); }` -- broken by C99
`int restrict;` -- broken by C11
`typedef int bool;` -- broken by C23
And so on.
> Yes, the common coding practice of UPPER CASE for macros limits the
> damage, that common coding practice is NOT a "rule", so can't be
> relied on.
>
> The problem is that there are people who don't follow that rule, and
> their code could get broken.
With carefully chosen parameter names, I'm skeptical that there's *any*
existing code that would be broken.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 19:47 -0400 |
| Message-ID | <cawGM.170690$8_8a.28739@fx48.iad> |
| In reply to | #172837 |
On 8/26/23 6:13 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/26/23 12:17 AM, Keith Thompson wrote:
> [...]
>>> Hmm. The standard could say that if you define a parameter name as
>>> an object-like macro before including a header that declares a
>>> function with that parameter, the behavior is undefined. In other
>>> words, standard parameter names would be reserved, but in fewer
>>> contexts than standard function names. Since parameter names are
>>> lowercase, there shouldn't be a lot of code using them as macros.
>>
>> Yes, they could, and break the backwards compatibility rule that has
>> been a fundamental rule for the history of the standard.
>
> No major edition of the standard has strictly followed that rule.
>
> `main() { printf("hello world); }` -- broken by C99
> `int restrict;` -- broken by C11
> `typedef int bool;` -- broken by C23
>
> And so on.
And each of those created debate, and was carefully considered.
The removal of implicit int in C99 was a deliberate decision, based on
the agreement that the "feature" was actually a bad idea, and it is easy
to fix the code, as you just need to add the int at the point where you
get the syntax error.
C11 reserving restrict was a single identifier, so limited impact on
programs. And again, should be simple to fix, as you will get a syntex
error. As I remember, there was a strong push from people working on
optimization, as it can have significant impact in some situations.
For bool, bool was added as a conditionally restricted name in C99, so
24 years later, code (that will be updated to C23) has almost certainly
removed other usage of the symbol.
It is a rule "proven" by the limited exceptions to it. The rule is to
take careful consideration of the breakage, not a total prohibition.
>
>> Yes, the common coding practice of UPPER CASE for macros limits the
>> damage, that common coding practice is NOT a "rule", so can't be
>> relied on.
>>
>> The problem is that there are people who don't follow that rule, and
>> their code could get broken.
>
> With carefully chosen parameter names, I'm skeptical that there's *any*
> existing code that would be broken.
>
I am not so sure. Yes, it will be rare, but not zero. More
problematically not sure you will always get a error if the header use
"user" names for parameters to be "pretty", and not implementation names
to be safe.
I suppose one option to make thing prettier would be to say that if the
prototype used a __ type name, that in the call, you are also allowed to
use a name without those two underscores (as long as that doesn't match
another parameter name).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-26 19:09 -0700 |
| Message-ID | <871qfpdyn6.fsf@nosuchdomain.example.com> |
| In reply to | #172841 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/26/23 6:13 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 8/26/23 12:17 AM, Keith Thompson wrote:
>> [...]
>>>> Hmm. The standard could say that if you define a parameter name as
>>>> an object-like macro before including a header that declares a
>>>> function with that parameter, the behavior is undefined. In other
>>>> words, standard parameter names would be reserved, but in fewer
>>>> contexts than standard function names. Since parameter names are
>>>> lowercase, there shouldn't be a lot of code using them as macros.
>>>
>>> Yes, they could, and break the backwards compatibility rule that has
>>> been a fundamental rule for the history of the standard.
>> No major edition of the standard has strictly followed that rule.
>> `main() { printf("hello world); }` -- broken by C99
>> `int restrict;` -- broken by C11
>> `typedef int bool;` -- broken by C23
>> And so on.
>
> And each of those created debate, and was carefully considered.
As this should be.
[...]
>> With carefully chosen parameter names, I'm skeptical that there's
>> *any* existing code that would be broken.
>
> I am not so sure. Yes, it will be rare, but not zero. More
> problematically not sure you will always get a error if the header use
> "user" names for parameters to be "pretty", and not implementation
> names to be safe.
You'd get an error for a source file that defines a (lower case)
parameter name as a macro *before including the header*. How common is
that? (I'm guessing the most common case for that would be a
"-Dfoo=bar" command-line option.)
Suppose fopen's first parameter is named "filename". If I #define
filename after "#include <stdio.h>", that's fine. It only means that I
can't use a named argument when calling fopen -- but I've already
decided I want to use the identifier "filename" for my own purposes.
If there's real-world code that would break, either because it defines a
lowercase macro before including a standard header or because of
something I've missed, I'd be interested in seeing it.
> I suppose one option to make thing prettier would be to say that if
> the prototype used a __ type name, that in the call, you are also
> allowed to use a name without those two underscores (as long as that
> doesn't match another parameter name).
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 22:27 -0400 |
| Message-ID | <1wyGM.118100$O8ab.63790@fx40.iad> |
| In reply to | #172853 |
On 8/26/23 10:09 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/26/23 6:13 PM, Keith Thompson wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>> On 8/26/23 12:17 AM, Keith Thompson wrote:
>>> [...]
>>>>> Hmm. The standard could say that if you define a parameter name as
>>>>> an object-like macro before including a header that declares a
>>>>> function with that parameter, the behavior is undefined. In other
>>>>> words, standard parameter names would be reserved, but in fewer
>>>>> contexts than standard function names. Since parameter names are
>>>>> lowercase, there shouldn't be a lot of code using them as macros.
>>>>
>>>> Yes, they could, and break the backwards compatibility rule that has
>>>> been a fundamental rule for the history of the standard.
>>> No major edition of the standard has strictly followed that rule.
>>> `main() { printf("hello world); }` -- broken by C99
>>> `int restrict;` -- broken by C11
>>> `typedef int bool;` -- broken by C23
>>> And so on.
>>
>> And each of those created debate, and was carefully considered.
>
> As this should be.
>
> [...]
>
>>> With carefully chosen parameter names, I'm skeptical that there's
>>> *any* existing code that would be broken.
>>
>> I am not so sure. Yes, it will be rare, but not zero. More
>> problematically not sure you will always get a error if the header use
>> "user" names for parameters to be "pretty", and not implementation
>> names to be safe.
>
> You'd get an error for a source file that defines a (lower case)
> parameter name as a macro *before including the header*. How common is
> that? (I'm guessing the most common case for that would be a
> "-Dfoo=bar" command-line option.)
Yes, that is the most like case, a -D option, perhaps from an IDE
configuration.
>
> Suppose fopen's first parameter is named "filename". If I #define
> filename after "#include <stdio.h>", that's fine. It only means that I
> can't use a named argument when calling fopen -- but I've already
> decided I want to use the identifier "filename" for my own purposes.
>
> If there's real-world code that would break, either because it defines a
> lowercase macro before including a standard header or because of
> something I've missed, I'd be interested in seeing it.
I've seen code with lower case name macros as a result of converting run
time configuration to fixed configuration, provide at build time.
filename is a likely parameter for something like this.
>
>> I suppose one option to make thing prettier would be to say that if
>> the prototype used a __ type name, that in the call, you are also
>> allowed to use a name without those two underscores (as long as that
>> doesn't match another parameter name).
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 18:55 +0200 |
| Message-ID | <ucfv6n$18cb9$4@dont-email.me> |
| In reply to | #172788 |
On 26/08/2023 02:12, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/25/23 2:59 PM, Keith Thompson wrote: > [...] >>> Any parameter names in a call would just have to be consistent with >>> the names in the visible prototype. I don't see a problem. Using >>> the "name=value" syntax would conflict with the use of an assignment >>> expression as an argument, so some new syntax would have to be >>> invented. >>> >>> I know, we could reuse the "static" keyword! 8-)} >>> [...] >>> >> >> As far as I know, C could still adopt the use of : for this purpose, >> like Bart's language does. >> >> I can't think of anything that this would get confused with. > > Nor can I. > >> I think the biggest thing this would require is that every standard >> library function would need to have the name used for its parameter >> defined (or the standard say you can't portably use them with the >> standard library functions. > > The standard already shows parameter names for library functions, though > they're not currently semantically meaningful. If this feature were > added in a future standard, the same names could be used. > The parameter names are not reserved identifiers - so someone could write: #define s1 Surprise! #define s2 This is going to cause trouble... #include <string.h> A declaration of "strcpy" that used parameter names "s1" and "s2" would then be problematic. I wonder if it would be possible for compilers to have a pre-processor directive to turn off user-defined macros while processing system headers? That would solve this issue. (It would probably be easier to wait until the C++ has had some practice with modules and worked out the kinks, then copy modules into C.) >> I think the biggest issue there is that the names would need to be >> somewhat ugle as they would need to be in the implementation reserved >> namespace, as anything in the user namespace might be a macro > > I'm not sure that would be much of a problem. For example, given > char *strcpy(char * restrict s1, > const char * restrict s2); > and a call like: > strcpy(s1: foo, s2: bar); > the lookup for the names s1 and s2 would refer only to the named > parameters of the called function. If you define a macro "s1", you > simply get whatever it expands to. > > Another issue is that library functions can additionally be defined as > macros. One solution would be to say that if you use a named parameter > association, it bypasses the macro and calls the function -- which could > break some contrived macro invocations. Another would be to allow named > parameter associations for macro invocations as well as function calls. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 02:16 +0100 |
| Message-ID | <ucbjph$96fa$1@dont-email.me> |
| In reply to | #172787 |
On 26/08/2023 00:34, Richard Damon wrote:
> On 8/25/23 2:59 PM, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 25/08/2023 10:37, Malcolm McLean wrote:
>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>> [...]
>>>>> There are good historical reasons for why named parameters are not
>>>>> common in older languages, but are more common in newer ones. And
>>>>> there
>>>>> are good technical reasons why they would be difficult to introduce
>>>>> to C
>>>>> as an afterthought. But I agree with you that they can be helpful and
>>>>> improve code readability, in languages that support them.
>>>>>
>>>> I don't really see what the technical problem is. The header would
>>>> have to
>>>> contain the names of the parameters (most do already). Then instead
>>>> of putting parameter 1 into register a and parameter 2 into register b,
>>>> the compiler matches them up. If its void foo(int x, int y) and the
>>>> call is foo(y=1, x=2), then the compiler puts a 2 into register a
>>>> and a 1
>>>> into register b.
>>>> I haven't tried to modify a compiler to do this so there might be
>>>> something I
>>>> haven't thought of. But it would be a fairly simple, contained
>>>> change with no
>>>> implications for the linker.
>>>
>>> The key technical problem for C is that the parameter names are not
>>> part of the signature of the function. It is not uncommon for
>>> declarations to have missing parameter names, or different names from
>>> those uses in the definition of the function. (Sometimes there are
>>> good reasons for this, sometimes it is laziness.) If a function is
>>> defined as "void foo(int a, int b) { .. }", but the declaration used
>>> to call it has "void foo(int b, int a);", then how should named
>>> parameters be resolved?
>>>
>>> Any resolution here would place restrictions on which functions could
>>> support named parameters - such as consistent declarations and
>>> definitions, but it would be impossible (in general) to check them.
>>
>> Any parameter names in a call would just have to be consistent with the
>> names in the visible prototype. I don't see a problem.
>>
>> Using the "name=value" syntax would conflict with the use of an
>> assignment expression as an argument, so some new syntax would have to
>> be invented.
>>
>> I know, we could reuse the "static" keyword! 8-)}
>>
>> [...]
>>
>
> As far as I know, C could still adopt the use of : for this purpose,
> like Bart's language does.
"." is already used by C for designated initialisers for structs. Why
not just use that?
>
> I can't think of anything that this would get confused with.
>
> I think the biggest thing this would require is that every standard
> library function would need to have the name used for its parameter
> defined (or the standard say you can't portably use them with the
> standard library functions.
>
> I think the biggest issue there is that the names would need to be
> somewhat ugle as they would need to be in the implementation reserved
> namespace, as anything in the user namespace might be a macro
So, if a function uses x and y parameters, they can clash with
user-defined macros called 'x' and 'y'?
But, this is already going to be a problem with arbitrarily named
functions in a library, plus variables, types, enums and macros exported
from that library.
If every such parameter name is to be uglified, then there seems little
point.
One possible answer might be a new kind of token which is
".alphanumeric", where the alphanumeric part is not checked for macro
expansion.
BTW I hadn't considered the macro angle. I tried the example below (in
my language), and it worked as expected, but then my macros are expanded
at a later stage than in C, so in the context of the keyword:value pair
'x:37', 'x' is a not a candidate for expansion.
A potentially bigger problem in C is how to deal with default parameter
values which is an essential part of keyword parameters. Especially
regarding the lexical scope of the names used in the default value
expression.
-----------------------------
macro x=999
proc bill(int x=10)=
println x
end
proc main=
bill() # output 10
bill(x:37) # output 37
bill(x) # output 999
bill(x:x) # output 999
end
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-25 18:39 -0700 |
| Message-ID | <87zg2eeg4u.fsf@nosuchdomain.example.com> |
| In reply to | #172792 |
Bart <bc@freeuk.com> writes:
> On 26/08/2023 00:34, Richard Damon wrote:
[...]
>> As far as I know, C could still adopt the use of : for this purpose,
>> like Bart's language does.
>
> "." is already used by C for designated initialisers for structs. Why
> not just use that?
It would probably work, but I dislike it. In a designated initializer,
the ".foo = 42" syntax mirrors the "obj.foo" syntax for referring to a
member of a struct object, just as "[0] = 42" mirrors the "obj[0]"
syntax.
Using ":" IMHO looks nice, and doesn't clash with anything else.
Ada uses "=>", which could also work. (Python uses "=", which it can do
because it doesn't use "=" for assignment expressions.)
Not a huge deal either way.
For that matter, a future C *could* use "=" as long as it disallowed
assigment expressions as arguments. That would be in some sense
cleaner, since it would suggest the assignment of an argument value to a
parameter, but it would break some existing code, and could even change
the meaning of some code that's currently valid but contrived.
[...]
> One possible answer might be a new kind of token which is
> ".alphanumeric", where the alphanumeric part is not checked for macro
> expansion.
But ".alphanumeric" is already two tokens that can appear together.
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-25 22:26 -0400 |
| Message-ID | <ipdGM.457101$xMqa.238959@fx12.iad> |
| In reply to | #172792 |
On 8/25/23 9:16 PM, Bart wrote:
> On 26/08/2023 00:34, Richard Damon wrote:
>> On 8/25/23 2:59 PM, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 25/08/2023 10:37, Malcolm McLean wrote:
>>>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>>> [...]
>>>>>> There are good historical reasons for why named parameters are not
>>>>>> common in older languages, but are more common in newer ones. And
>>>>>> there
>>>>>> are good technical reasons why they would be difficult to
>>>>>> introduce to C
>>>>>> as an afterthought. But I agree with you that they can be helpful and
>>>>>> improve code readability, in languages that support them.
>>>>>>
>>>>> I don't really see what the technical problem is. The header would
>>>>> have to
>>>>> contain the names of the parameters (most do already). Then instead
>>>>> of putting parameter 1 into register a and parameter 2 into
>>>>> register b,
>>>>> the compiler matches them up. If its void foo(int x, int y) and the
>>>>> call is foo(y=1, x=2), then the compiler puts a 2 into register a
>>>>> and a 1
>>>>> into register b.
>>>>> I haven't tried to modify a compiler to do this so there might be
>>>>> something I
>>>>> haven't thought of. But it would be a fairly simple, contained
>>>>> change with no
>>>>> implications for the linker.
>>>>
>>>> The key technical problem for C is that the parameter names are not
>>>> part of the signature of the function. It is not uncommon for
>>>> declarations to have missing parameter names, or different names from
>>>> those uses in the definition of the function. (Sometimes there are
>>>> good reasons for this, sometimes it is laziness.) If a function is
>>>> defined as "void foo(int a, int b) { .. }", but the declaration used
>>>> to call it has "void foo(int b, int a);", then how should named
>>>> parameters be resolved?
>>>>
>>>> Any resolution here would place restrictions on which functions could
>>>> support named parameters - such as consistent declarations and
>>>> definitions, but it would be impossible (in general) to check them.
>>>
>>> Any parameter names in a call would just have to be consistent with the
>>> names in the visible prototype. I don't see a problem.
>>>
>>> Using the "name=value" syntax would conflict with the use of an
>>> assignment expression as an argument, so some new syntax would have to
>>> be invented.
>>>
>>> I know, we could reuse the "static" keyword! 8-)}
>>>
>>> [...]
>>>
>>
>> As far as I know, C could still adopt the use of : for this purpose,
>> like Bart's language does.
>
> "." is already used by C for designated initialisers for structs. Why
> not just use that?
That could work too.
It still have the macro problem (at least for standard headers)
>
>>
>> I can't think of anything that this would get confused with.
>>
>> I think the biggest thing this would require is that every standard
>> library function would need to have the name used for its parameter
>> defined (or the standard say you can't portably use them with the
>> standard library functions.
>>
>> I think the biggest issue there is that the names would need to be
>> somewhat ugle as they would need to be in the implementation reserved
>> namespace, as anything in the user namespace might be a macro
>
> So, if a function uses x and y parameters, they can clash with
> user-defined macros called 'x' and 'y'?
Of course, C macros are global substitutes.
>
> But, this is already going to be a problem with arbitrarily named
> functions in a library, plus variables, types, enums and macros exported
> from that library.
If the header defines that the indentifies are reserved for its us, then
the user code won't (or shouldn't) define macros for them.
>
> If every such parameter name is to be uglified, then there seems little
> point.
Yes, that was my point for system headers. You would need something like:
strcpy(_Src: p1, _Dst: p2);
since those are reserved names for the implementation.
>
> One possible answer might be a new kind of token which is
> ".alphanumeric", where the alphanumeric part is not checked for macro
> expansion.
except that would impact something like x.y where you may WANT to have a
macro for the y part.
>
>
> BTW I hadn't considered the macro angle. I tried the example below (in
> my language), and it worked as expected, but then my macros are expanded
> at a later stage than in C, so in the context of the keyword:value pair
> 'x:37', 'x' is a not a candidate for expansion.
>
> A potentially bigger problem in C is how to deal with default parameter
> values which is an essential part of keyword parameters. Especially
> regarding the lexical scope of the names used in the default value
> expression.
>
> -----------------------------
>
> macro x=999
>
> proc bill(int x=10)=
> println x
> end
>
> proc main=
> bill() # output 10
> bill(x:37) # output 37
> bill(x) # output 999
> bill(x:x) # output 999
> end
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 11:07 +0100 |
| Message-ID | <uccitk$hhuj$1@dont-email.me> |
| In reply to | #172795 |
On 26/08/2023 03:26, Richard Damon wrote:
> On 8/25/23 9:16 PM, Bart wrote:
>> "." is already used by C for designated initialisers for structs. Why
>> not just use that?
>
> That could work too.
>
> It still have the macro problem (at least for standard headers)
Why only standard headers? People also use third party headers, which
can be massively more expansive that the standard ones. (Standard
headers might be 3-5K lines of code; GTK is 350K lines.)
>> So, if a function uses x and y parameters, they can clash with
>> user-defined macros called 'x' and 'y'?
>
> Of course, C macros are global substitutes.
>
>>
>> But, this is already going to be a problem with arbitrarily named
>> functions in a library, plus variables, types, enums and macros
>> exported from that library.
>
> If the header defines that the indentifies are reserved for its us, then
> the user code won't (or shouldn't) define macros for them.
>
>>
>> If every such parameter name is to be uglified, then there seems
>> little point.
>
> Yes, that was my point for system headers. You would need something like:
>
> strcpy(_Src: p1, _Dst: p2);
>
> since those are reserved names for the implementation.
>
>>
>> One possible answer might be a new kind of token which is
>> ".alphanumeric", where the alphanumeric part is not checked for macro
>> expansion.
>
> except that would impact something like x.y where you may WANT to have a
> macro for the y part.
Actually, in my language I also wanted to have the 'y' in 'x.y' be a macro.
I couldn't make it work. Then I realised that it couldn't work:
* There might be dozens of different record (struct) definitions with
a field called 'y'.
* Creating a global or even module-local macro called 'y' would change
the interpretation of every term 'x.y' where x could be any of those
multiple struct types
*This also applies to C now*. It is exactly the same problem as the
parameter names.
Struct member names ought to be in their own protected namespace. But
global macros can override all them:
#include <stdio.h>
typedef struct {int x,y;} Point;
int main(void) {
Point p = {100, 200};
printf("%d\n", p.y);
}
This program displays "200". Now introduce a macro like this:
#define y "Why"
and every .y member designation is screwed up.
As I said, exactly the same as might happen with keyword parameter
names, but somehow it works.
Mostly because macro names tend to be in capitals.
Conclusion: for C it is a non-issue. Just another of the many quirks and
gotchas that people already work around.
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web