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 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 10:33 -0400 |
| Message-ID | <H2oGM.827787$TPw2.680260@fx17.iad> |
| In reply to | #172811 |
On 8/26/23 6:07 AM, Bart wrote:
> 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.)
Because that isn't a problem the standard needs to solve, but the third
party.
The standard has well defined rules of what is each namespace, and there
policy is to follow that as much as possible.
It would be a major backwards incompatible change to suddenly remove a
large number of symbols out of the user macro namespace for parameter names.
"Third party" libraries have always been in a awkward place of not being
allowed to use the "implementation" name space, because, they are not
part of the implementation, so they need to establish their own rules
about what part of user names space they will try to reserve.
>
>>> 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'.
Which means that you don't use that for common field names, but would
only be able to use it for something more unique.
>
> * 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:
>
They do, its just that macros, because of when they are processed, don't
respect it.
> #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.
And this is why namespace rules are important.
If the standard defines that a header will define a struture with a
field with a given name, that name can not be a macro when that header
is included. That is part of the rules of the languge.
If the standard doesn't DEFINE the use of that name, then all the names
in the user namespace might be a macro.
If the user messes themselves up by doing it to themselves, its their
own fault, and not the standards. So y would be a bad name for a macro,
as it is so commonly used in code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 16:27 +0100 |
| Message-ID | <ucd5kt$kl1p$1@dont-email.me> |
| In reply to | #172815 |
On 26/08/2023 15:33, Richard Damon wrote: > On 8/26/23 6:07 AM, Bart wrote: >> 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. > > > And this is why namespace rules are important. > > If the standard defines that a header will define a struture with a > field with a given name, that name can not be a macro when that header > is included. That is part of the rules of the languge. > > If the standard doesn't DEFINE the use of that name, then all the names > in the user namespace might be a macro. > > If the user messes themselves up by doing it to themselves, its their > own fault, and not the standards. So y would be a bad name for a macro, > as it is so commonly used in code. My point is that this bug in the language already exists. Macro names have module-wide scope, and can be program-wide when used in a shared header file. The can override: * Member names used struct declarations (int y) * Member names used for access (x.y) * Member names used for designated initialisers (.y = x) * Parameter names used in function declarations and definitions * Local variables names * Label names * Struct and enum tags * Enum names * Keywords * Standard type names * Function names ... In short, they can already override everything, in a bad way, across scopes and even reaching into tag and label namespaces. I hadn't even realised this before, as I was concentrating on x.y. So, there is no really big deal with using parameter names in declarations, which are already affected now, for keyword parameters. The problem affects all code, the majority of which is going to be user code not system headers. This then can't be a factor in deciding whether to add keyword parameters.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 11:57 -0400 |
| Message-ID | <JhpGM.631626$SuUf.416528@fx14.iad> |
| In reply to | #172817 |
On 8/26/23 11:27 AM, Bart wrote: > On 26/08/2023 15:33, Richard Damon wrote: >> On 8/26/23 6:07 AM, Bart wrote: > >>> 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. >> >> >> And this is why namespace rules are important. >> >> If the standard defines that a header will define a struture with a >> field with a given name, that name can not be a macro when that header >> is included. That is part of the rules of the languge. >> >> If the standard doesn't DEFINE the use of that name, then all the >> names in the user namespace might be a macro. >> >> If the user messes themselves up by doing it to themselves, its their >> own fault, and not the standards. So y would be a bad name for a >> macro, as it is so commonly used in code. > > My point is that this bug in the language already exists. > > Macro names have module-wide scope, and can be program-wide when used in > a shared header file. > > The can override: > > * Member names used struct declarations (int y) > > * Member names used for access (x.y) > > * Member names used for designated initialisers (.y = x) > > * Parameter names used in function declarations and definitions > > * Local variables names > > * Label names > > * Struct and enum tags > > * Enum names > > * Keywords > > * Standard type names > > * Function names > > ... > > In short, they can already override everything, in a bad way, across > scopes and even reaching into tag and label namespaces. I hadn't even > realised this before, as I was concentrating on x.y. > > So, there is no really big deal with using parameter names in > declarations, which are already affected now, for keyword parameters. > > The problem affects all code, the majority of which is going to be user > code not system headers. > > This then can't be a factor in deciding whether to add keyword parameters. No, it means it MUST be a factor in deciding on wheter to add keyword parameters. You just don't seem to understand the concept of divided namespaces and maintaining backwards compatibility. By the rules of engagement the Standards Committe has established, the standard CAN NOT just appropriate a large portion of a user name space for the implementation. One defined namespace is what can a macro name be, and since that includes sequences of lower case letters (except for names specifically called out for THAT header as for the implementation, or defined as keywords), the Standard can't just make "parameter names" use those sort of identifiers. The fact that this namespace ignores most of the rest of the language, so is truely global within a file gives some problems, but is fundamental to the nature of how the preprocessor works, and is part of what gives it some of its power.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 17:11 +0100 |
| Message-ID | <ucd871$l3b5$1@dont-email.me> |
| In reply to | #172818 |
On 26/08/2023 16:57, Richard Damon wrote:
> On 8/26/23 11:27 AM, Bart wrote:
>> On 26/08/2023 15:33, Richard Damon wrote:
>>> On 8/26/23 6:07 AM, Bart wrote:
>>
>>>> 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.
>>>
>>>
>>> And this is why namespace rules are important.
>>>
>>> If the standard defines that a header will define a struture with a
>>> field with a given name, that name can not be a macro when that
>>> header is included. That is part of the rules of the languge.
>>>
>>> If the standard doesn't DEFINE the use of that name, then all the
>>> names in the user namespace might be a macro.
>>>
>>> If the user messes themselves up by doing it to themselves, its their
>>> own fault, and not the standards. So y would be a bad name for a
>>> macro, as it is so commonly used in code.
>>
>> My point is that this bug in the language already exists.
>>
>> Macro names have module-wide scope, and can be program-wide when used
>> in a shared header file.
>>
>> The can override:
>>
>> * Member names used struct declarations (int y)
>>
>> * Member names used for access (x.y)
>>
>> * Member names used for designated initialisers (.y = x)
>>
>> * Parameter names used in function declarations and definitions
>>
>> * Local variables names
>>
>> * Label names
>>
>> * Struct and enum tags
>>
>> * Enum names
>>
>> * Keywords
>>
>> * Standard type names
>>
>> * Function names
>>
>> ...
>>
>> In short, they can already override everything, in a bad way, across
>> scopes and even reaching into tag and label namespaces. I hadn't even
>> realised this before, as I was concentrating on x.y.
>>
>> So, there is no really big deal with using parameter names in
>> declarations, which are already affected now, for keyword parameters.
>>
>> The problem affects all code, the majority of which is going to be
>> user code not system headers.
>>
>> This then can't be a factor in deciding whether to add keyword
>> parameters.
>
> No, it means it MUST be a factor in deciding on wheter to add keyword
> parameters.
>
> You just don't seem to understand the concept of divided namespaces and
> maintaining backwards compatibility.
>
> By the rules of engagement the Standards Committe has established, the
> standard CAN NOT just appropriate a large portion of a user name space
> for the implementation.
>
> One defined namespace is what can a macro name be, and since that
> includes sequences of lower case letters (except for names specifically
> called out for THAT header as for the implementation, or defined as
> keywords), the Standard can't just make "parameter names" use those sort
> of identifiers.
>
> The fact that this namespace ignores most of the rest of the language,
> so is truely global within a file gives some problems, but is
> fundamental to the nature of how the preprocessor works, and is part of
> what gives it some of its power.
>
So what would happen if this feature was introduced overnight? That is,
instead of doing this which is valid C code now:
void fred(int a, int b, int c);
fred(10, 20, 30);
you were able to do:
fred(10, c:30, b:20);
Bear mind that defining either b or c as non-function-like macros can
already cause problems now, especially if the macro expansion is not a
valid parameter name.
If you say, you wouldn't use parameter names in a declaration, then the
problem occurs here too:
void fred(int a, int b, int c) { ... }
...
fred(10, 20, 30);
As I see it, nothing much changes. How would it affect backwards
compatibility?
Adding a parameter name 'b' in a program that already defines 'b' as a
macro that will be expanded, will cause an immediate problem. Then you
fix that.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 12:35 -0400 |
| Message-ID | <3RpGM.755540$AsA.124161@fx18.iad> |
| In reply to | #172819 |
On 8/26/23 12:11 PM, Bart wrote:
> On 26/08/2023 16:57, Richard Damon wrote:
>> On 8/26/23 11:27 AM, Bart wrote:
>>> On 26/08/2023 15:33, Richard Damon wrote:
>>>> On 8/26/23 6:07 AM, Bart wrote:
>>>
>>>>> 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.
>>>>
>>>>
>>>> And this is why namespace rules are important.
>>>>
>>>> If the standard defines that a header will define a struture with a
>>>> field with a given name, that name can not be a macro when that
>>>> header is included. That is part of the rules of the languge.
>>>>
>>>> If the standard doesn't DEFINE the use of that name, then all the
>>>> names in the user namespace might be a macro.
>>>>
>>>> If the user messes themselves up by doing it to themselves, its
>>>> their own fault, and not the standards. So y would be a bad name for
>>>> a macro, as it is so commonly used in code.
>>>
>>> My point is that this bug in the language already exists.
>>>
>>> Macro names have module-wide scope, and can be program-wide when used
>>> in a shared header file.
>>>
>>> The can override:
>>>
>>> * Member names used struct declarations (int y)
>>>
>>> * Member names used for access (x.y)
>>>
>>> * Member names used for designated initialisers (.y = x)
>>>
>>> * Parameter names used in function declarations and definitions
>>>
>>> * Local variables names
>>>
>>> * Label names
>>>
>>> * Struct and enum tags
>>>
>>> * Enum names
>>>
>>> * Keywords
>>>
>>> * Standard type names
>>>
>>> * Function names
>>>
>>> ...
>>>
>>> In short, they can already override everything, in a bad way, across
>>> scopes and even reaching into tag and label namespaces. I hadn't even
>>> realised this before, as I was concentrating on x.y.
>>>
>>> So, there is no really big deal with using parameter names in
>>> declarations, which are already affected now, for keyword parameters.
>>>
>>> The problem affects all code, the majority of which is going to be
>>> user code not system headers.
>>>
>>> This then can't be a factor in deciding whether to add keyword
>>> parameters.
>>
>> No, it means it MUST be a factor in deciding on wheter to add keyword
>> parameters.
>>
>> You just don't seem to understand the concept of divided namespaces
>> and maintaining backwards compatibility.
>>
>> By the rules of engagement the Standards Committe has established, the
>> standard CAN NOT just appropriate a large portion of a user name space
>> for the implementation.
>>
>> One defined namespace is what can a macro name be, and since that
>> includes sequences of lower case letters (except for names
>> specifically called out for THAT header as for the implementation, or
>> defined as keywords), the Standard can't just make "parameter names"
>> use those sort of identifiers.
>>
>> The fact that this namespace ignores most of the rest of the language,
>> so is truely global within a file gives some problems, but is
>> fundamental to the nature of how the preprocessor works, and is part
>> of what gives it some of its power.
>>
>
> So what would happen if this feature was introduced overnight? That is,
> instead of doing this which is valid C code now:
The effect would be that the parameter names for functions defined in
standard headers would need to be names in spaces that the user was not
allowed to define macros for.
Thus, if your "fred" below was a function defined by the standard, the
parameter names could NOT be "a", "b", or "c", but something like:
void fred(int _A, int _B, int _C);
since names that begin with an underscore, and followed by an upper case
leter are reserved for the implementation, including in macro namespace.
>
>
> void fred(int a, int b, int c);
>
> fred(10, 20, 30);
>
> you were able to do:
>
> fred(10, c:30, b:20);
>
> Bear mind that defining either b or c as non-function-like macros can
> already cause problems now, especially if the macro expansion is not a
> valid parameter name.
And for user code, the user needed to have taken care of that already.
>
> If you say, you wouldn't use parameter names in a declaration, then the
> problem occurs here too:
>
> void fred(int a, int b, int c) { ... }
> ...
>
> fred(10, 20, 30);
>
> As I see it, nothing much changes. How would it affect backwards
> compatibility?
>
> Adding a parameter name 'b' in a program that already defines 'b' as a
> macro that will be expanded, will cause an immediate problem. Then you
> fix that.
>
You just don't seem to understand the difference between implementation
code and user code.
The user has always had the requirement not to break his own code, and
had rules to follow to keep them from breaking implementation code, or
for implementation code from breaking theirs. That is what the
identifier namespace rules provide.
The side affect of this, is that adding a new use of identifier (the
names of parameters) means the system functions defined by the
implementation must use names that belong to the implementation.
Thus, a function like strcpy CAN'T have "parameter names" like src, as
those are user space names.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 18:24 +0100 |
| Message-ID | <ucdcg8$mi31$1@dont-email.me> |
| In reply to | #172821 |
On 26/08/2023 17:35, Richard Damon wrote: > On 8/26/23 12:11 PM, Bart wrote: > > The side affect of this, is that adding a new use of identifier (the > names of parameters) means the system functions defined by the > implementation must use names that belong to the implementation. > > Thus, a function like strcpy CAN'T have "parameter names" like src, as > those are user space names. I'm sorry, I don't understand why you keep going on about system functions. You don't need to touch the system headers. Nobody is forcing those functions to have parameter names at all, or if they have, needing those leading underscores removed. This is a new feature of most use for functions in user-code. If someone wants to use it for system functions, then they'll need to use those underscore names. But then, introducing default values for missing arguments will have a bigger impact. The names are a non-issue.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 13:35 -0400 |
| Message-ID | <_JqGM.129929$QQFb.65959@fx38.iad> |
| In reply to | #172824 |
On 8/26/23 1:24 PM, Bart wrote: > On 26/08/2023 17:35, Richard Damon wrote: >> On 8/26/23 12:11 PM, Bart wrote: >> >> The side affect of this, is that adding a new use of identifier (the >> names of parameters) means the system functions defined by the >> implementation must use names that belong to the implementation. >> >> Thus, a function like strcpy CAN'T have "parameter names" like src, as >> those are user space names. > > I'm sorry, I don't understand why you keep going on about system functions. Because that was the question I was answering about. > > You don't need to touch the system headers. Nobody is forcing those > functions to have parameter names at all, or if they have, needing those > leading underscores removed. But the comment was that the "names" of the paramaters for system functions WAS defined, by the prototypes listed in the standard itself. In the standard, every function parameter is given a name so it can be discussed in the standard. The problem is that these names in the standard, because currently they don't actually matter, since they don't need to be the names used in the actual header/implementation of the functions, aren't reserved for the implementaiton or from the namespace so reserved. > > This is a new feature of most use for functions in user-code. Says who? > > If someone wants to use it for system functions, then they'll need to > use those underscore names. But then, introducing default values for > missing arguments will have a bigger impact. The names are a non-issue. > The issue is how likely is a feature to be added that has only "unacceptable" usage for system functions. I think you can already sort of do this for user functions. Make your function take a structure as its one and only parameter, and use structure initialization to assign the values of the parameters.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 20:11 +0100 |
| Message-ID | <ucdip0$nn0q$1@dont-email.me> |
| In reply to | #172826 |
On 26/08/2023 18:35, Richard Damon wrote: > On 8/26/23 1:24 PM, Bart wrote: >> On 26/08/2023 17:35, Richard Damon wrote: >>> On 8/26/23 12:11 PM, Bart wrote: >>> >>> The side affect of this, is that adding a new use of identifier (the >>> names of parameters) means the system functions defined by the >>> implementation must use names that belong to the implementation. >>> >>> Thus, a function like strcpy CAN'T have "parameter names" like src, >>> as those are user space names. >> >> I'm sorry, I don't understand why you keep going on about system >> functions. > > Because that was the question I was answering about. > >> >> You don't need to touch the system headers. Nobody is forcing those >> functions to have parameter names at all, or if they have, needing >> those leading underscores removed. > > But the comment was that the "names" of the paramaters for system > functions WAS defined, by the prototypes listed in the standard itself. > > In the standard, every function parameter is given a name so it can be > discussed in the standard. Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have parameter names, but they are 'filename' and 'mode'; I can't see any underscores. Are you saying they would need underscores /added/? If so then I've misunderstood. Even so, is that really a problem? No current code will be using those names. And if I look inside stdio.h belonging to MingW, the names it uses are already _Filename and _Mode. The problem then is more, getting standard headers to use the same consistent names, if they don't already do so. If so, /then/ what is the problem; that the names are ugly? That seems to be par for the course for C's standard names. > The problem is that these names in the standard, because currently they > don't actually matter, since they don't need to be the names used in the > actual header/implementation of the functions, aren't reserved for the > implementaiton or from the namespace so reserved. > >> >> This is a new feature of most use for functions in user-code. > > Says who? Says the fact that most code in an application is going to consist of user-functions. >> >> If someone wants to use it for system functions, then they'll need to >> use those underscore names. But then, introducing default values for >> missing arguments will have a bigger impact. The names are a non-issue. >> > > The issue is how likely is a feature to be added that has only > "unacceptable" usage for system functions. I don't care about system functions with 2 arguments. I care about ones like CreateWindowEx() with 14 arguments. I don't want to lose a jolly useful feature because of some hiccup with system functions. > I think you can already sort of do this for user functions. Make your > function take a structure as its one and only parameter, and use > structure initialization to assign the values of the parameters. Come on, that is not a feature, it would be an incredibly ugly and inconvenient hack. Imagine defining 9000 structs to match the 9000 functions of GTK. It also doesn't address the issue of default values. And it will be inefficient: structs are usually passed by reference to a block of memory, so the arguments are not passed in registers. True keyword parameters are exactly as efficient as regular argument passing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 17:07 -0400 |
| Message-ID | <pQtGM.261905$uLJb.8744@fx41.iad> |
| In reply to | #172829 |
On 8/26/23 3:11 PM, Bart wrote: > On 26/08/2023 18:35, Richard Damon wrote: >> On 8/26/23 1:24 PM, Bart wrote: >>> On 26/08/2023 17:35, Richard Damon wrote: >>>> On 8/26/23 12:11 PM, Bart wrote: >>>> >>>> The side affect of this, is that adding a new use of identifier (the >>>> names of parameters) means the system functions defined by the >>>> implementation must use names that belong to the implementation. >>>> >>>> Thus, a function like strcpy CAN'T have "parameter names" like src, >>>> as those are user space names. >>> >>> I'm sorry, I don't understand why you keep going on about system >>> functions. >> >> Because that was the question I was answering about. >> >>> >>> You don't need to touch the system headers. Nobody is forcing those >>> functions to have parameter names at all, or if they have, needing >>> those leading underscores removed. >> >> But the comment was that the "names" of the paramaters for system >> functions WAS defined, by the prototypes listed in the standard itself. >> >> In the standard, every function parameter is given a name so it can be >> discussed in the standard. > > Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have > parameter names, but they are 'filename' and 'mode'; I can't see any > underscores. Right, because currently, to document the function, since the names don't actually mean anything, they can use whatever is desired to document the behavior of the function. In fact, the name used in a prototype, if names are used at all, are meaningless to the actual function definition > > Are you saying they would need underscores /added/? If so then I've > misunderstood. If they wanted the documentation to provide the names that could be used to call the function with "named parameters" they would. > > Even so, is that really a problem? No current code will be using those > names. But the program might have the statement #define filename "Foobar" before included the header, which would break the prototype given in the header. > > And if I look inside stdio.h belonging to MingW, the names it uses are > already _Filename and _Mode. The problem then is more, getting standard > headers to use the same consistent names, if they don't already do so. "Getting" isn't the issue, if they were docuemented that way, the implementation MUST update (if needed) to the now "standard" name for the prototype. > > If so, /then/ what is the problem; that the names are ugly? That seems > to be par for the course for C's standard names. Yes, it says that to used named parameters to standard library functions, code would be filled with the "ugly" names. > >> The problem is that these names in the standard, because currently >> they don't actually matter, since they don't need to be the names used >> in the actual header/implementation of the functions, aren't reserved >> for the implementaiton or from the namespace so reserved. >> >>> >>> This is a new feature of most use for functions in user-code. >> >> Says who? > > Says the fact that most code in an application is going to consist of > user-functions. Maybe for you, but a lot of code calls the standard library a lot, and one cost to implementing the feature is deciding on how to handle the standard library, because you really only get one change. Once you define what the name of the parameters are, it gets much harder to change it later. If they take many user names, they will get complaints of broken code. If they keep them ugly, they will get complaints that they are ugly. Being committees, this sort of thing goes slow. > >>> >>> If someone wants to use it for system functions, then they'll need to >>> use those underscore names. But then, introducing default values for >>> missing arguments will have a bigger impact. The names are a non-issue. >>> >> >> The issue is how likely is a feature to be added that has only >> "unacceptable" usage for system functions. > > I don't care about system functions with 2 arguments. I care about ones > like CreateWindowEx() with 14 arguments. Many of my IDEs, will prompt me with the name from the prototype as I type the call (some even show it inline in the code of the call) Then you hit the fact that > > I don't want to lose a jolly useful feature because of some hiccup with > system functions. Well, are you doing anything to actually make it happen? Ideas don't just happen, but someone needs to take on the job of doing the groundwork to make it happen, > > >> I think you can already sort of do this for user functions. Make your >> function take a structure as its one and only parameter, and use >> structure initialization to assign the values of the parameters. > > Come on, that is not a feature, it would be an incredibly ugly and > inconvenient hack. I never said it was pretty, just possible. Possible but ugly beats can't be done yet. > > Imagine defining 9000 structs to match the 9000 functions of GTK. Yep, but doesn't actually add that many lines of code (relative to the current code side. > > It also doesn't address the issue of default values. It doesn't have default values for function calls either. It could adopt C++'s concept of default values for structures as a very limited version of constructiors. > > And it will be inefficient: structs are usually passed by reference to a > block of memory, so the arguments are not passed in registers. Depends on the API. some pass "small" structures in registers, so that could still work. If you have more than can be held in registers, it isn't that less efficent, > > True keyword parameters are exactly as efficient as regular argument > passing. > > Yes, IF you have it. C doesn't, so a non-existent capability has ZERO efficiency.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 22:40 +0100 |
| Message-ID | <ucdrgl$p9lu$1@dont-email.me> |
| In reply to | #172832 |
On 26/08/2023 22:07, Richard Damon wrote: > On 8/26/23 3:11 PM, Bart wrote: >> I don't want to lose a jolly useful feature because of some hiccup >> with system functions. > > Well, are you doing anything to actually make it happen? > > Ideas don't just happen, but someone needs to take on the job of doing > the groundwork to make it happen, I'm sure there are plenty of people about adding all sorts of extensions to C, such as with gnu C. They would be better qualified to get things happening, and better motivated. For my part, I first used keyword params in a scripting language in the 90s, and added them to my systems language in the last decade. I have experience of implementation problems and how well the feature works in practice. I suppose I could add them to my C compiler as proof of concept, but I don't have that motivation, and past experience tells me that nobody cares what I do there; they don't take my stuff seriously. Besides changes in C take decades to achieve; I will be long dead. Meanwhile my everyday language has that feature amongst dozens of others. I've already done the work! Solving obscure and possibly imaginary problems of backwards compatibility is not interesting to me. If you want the feature, find a way around it, or work out a compromise. But I can tell you that you will want default function arguments as a feature first. > [using structs for a row of arguments] I never said it was pretty, just possible. Another major shortcoming is that it will only work for specially written functions. You can't can't for example modify a declaration of an imported function to retrofit keyword parameters and default values via a 'struct method'; the call mechanism must be unchanged. Or you need to wrap each function with a new one.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-26 23:32 -0700 |
| Message-ID | <17e4272c-47f8-427b-8fd6-21b1108b573dn@googlegroups.com> |
| In reply to | #172832 |
On Saturday, 26 August 2023 at 22:07:49 UTC+1, Richard Damon wrote: > On 8/26/23 3:11 PM, Bart wrote: > > > Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have > > parameter names, but they are 'filename' and 'mode'; I can't see any > > underscores. > Right, because currently, to document the function, since the names > don't actually mean anything, they can use whatever is desired to > document the behavior of the function. > > In fact, the name used in a prototype, if names are used at all, are > meaningless to the actual function definition > Underscores make text hard to read. And the parameter name isn't part of the standard. So when discussing the function, people use an easy-to-read identifier, like "filename". If provided, the paramter name has to be surrounded with underscores to put it into the implementation's namespace. > > > If so, /then/ what is the problem; that the names are ugly? That seems > > to be par for the course for C's standard names. > Yes, it says that to used named parameters to standard library > functions, code would be filled with the "ugly" names. > That's a problem. In fact if you said that code which #defined identifiers like "x" or "theta" would invade implementation namespace, you would break very few sanely written programs. But it would be a fairly big theoretical change. But with the contract as it is, it's got to be __x or _X. However named parameters aren't really a big help for standard library functions. Most of them take only one or two parameters, and it's usually easy to remember which is which. The one I can think of where it would really help is qsort(), where it's not always easy to remember which is N and which is width. > > > And it will be inefficient: structs are usually passed by reference to a > > block of memory, so the arguments are not passed in registers. > Depends on the API. some pass "small" structures in registers, so that > could still work. If you have more than can be held in registers, it > isn't that less efficent, > Microsoft use structures to pass large numbers of parameters to certain functions, like ones to open a file dialog. In reality I find that you wrap the call. You write a function which consists of setting up the structure and assigning the fields, then calling the Microsoft function.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-27 03:02 -0700 |
| Message-ID | <87wmxgdcre.fsf@nosuchdomain.example.com> |
| In reply to | #172864 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> However named parameters aren't really a big help for standard library
> functions. Most of them take only one or two parameters, and it's usually
> easy to remember which is which. The one I can think of where it would
> really help is qsort(), where it's not always easy to remember which is N
> and which is width.
[...]
Another example: the size and nmemb parameters of fread() and fwrite().
calloc() is almost another example, but the order of the arguments
doesn't actually matter.
--
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-27 13:25 +0100 |
| Message-ID | <87ledwoeox.fsf@bsb.me.uk> |
| In reply to | #172864 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > However named parameters aren't really a big help for standard library > functions. Most of them take only one or two parameters, and it's usually > easy to remember which is which. The one I can think of where it would > really help is qsort(), where it's not always easy to remember which is N > and which is width. Also fread, fwrite and the largely forgotten bsearch. To make matters worse, fread and fwrite go the other way to qsort and bsearch, and you don't get any diagnostics since the types of the two counts are the same. You might, for example, get the position of the 'end pointer' argument to strtol wrong, but you'll usually get a warning about it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-26 14:37 -0700 |
| Message-ID | <87edjpeb8u.fsf@nosuchdomain.example.com> |
| In reply to | #172829 |
Bart <bc@freeuk.com> writes:
> On 26/08/2023 18:35, Richard Damon wrote:
>> On 8/26/23 1:24 PM, Bart wrote:
[...]
>>> You don't need to touch the system headers. Nobody is forcing those
>>> functions to have parameter names at all, or if they have, needing
>>> those leading underscores removed.
>> But the comment was that the "names" of the paramaters for system
>> functions WAS defined, by the prototypes listed in the standard itself.
>> In the standard, every function parameter is given a name so it can
>> be discussed in the standard.
>
> Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have
> parameter names, but they are 'filename' and 'mode'; I can't see any
> underscores.
Right, but the names in the standard might as well be comments. They
have no meaning for client code; they're there only for documentation.
(I'm not sure that the standard states this explicitly.)
> Are you saying they would need underscores /added/? If so then I've
> misunderstood.
>
> Even so, is that really a problem? No current code will be using those
> names.
In the implementation I'm currently using, <stdio.h> has:
extern FILE *fopen (const char *__restrict __filename,
const char *__restrict __modes)
__attribute_malloc__ __attr_dealloc_fclose __wur;
Presumably the __restrict is so that the header can be used with pre-C99
compilers, where "restrict" is not a keyword. We can ignore the third
line.
The declaration shown in the standard (as of N1570) is:
FILE *fopen(const char * restrict filename,
const char * restrict mode);
But a conforming implementation can't use that exact declaration.
This is a (contrived) strictly conforming program for a hosted
implementation:
#define filename (
#define mode )
#include <stdio.h>
int main(void) {
puts filename "Hello, world" mode;
}
but it would fail with a syntax error if <stdio.h> used those parameter
names. That's why conforming implementations use different parameter
names (or possibly none).
What's being proposed is to add named function arguments to a future
version of C. With such a change, the parameter names in the standard
headers would become significant. (And perhaps some of them could be
changed; for example strcpy() might use dst and src rather than s1 and
s2.)
The problem is that such a change would break existing strictly
conforming code (unless the standard library headers use reserved names
like __filename and __mode in all parameter declarations, or the feature
is tweaked in some way that would likely make it less useful and/or
harder to implement.
I think that very little actual code would be broken. Most macros in
user code have all-caps names. Still, it's something the committee
would have to consider very seriously.
I don't think any edition of the C standard has completely avoided
breaking existing code. C99 broke all code that depends on implicit
int. C11 broke all code that uses "restrict" as an identifier. C23
breaks all code that uses "bool", "false", or "true" as an identifier.
And so on.
It's likely that named function arguments will not be added to C any
time soon, because nobody has seriously proposed it (this discussion is
not a formal proposal), because it would probably be seen as too big a
change, and because as far as I know no C compilers have implemented it
as an extension. And it would probably require changes to the
preprocessor as well, since library functions can be defined as macros.
But in my opinion (which doesn't count for much), *if* there were a
decision to add named function arguments to a future edition of the C
standard, the fact that some contrived strictly conforming code would
break should not prevent it.
--
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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-26 19:49 +0000 |
| Message-ID | <20230826123929.770@kylheku.com> |
| In reply to | #172817 |
On 2023-08-26, Bart <bc@freeuk.com> wrote: > My point is that this bug in the language already exists. > > Macro names have module-wide scope, and can be program-wide when used in > a shared header file. The pitfalls of a token-level preprocessor are thoroughly understood, hopefully by everyone here. > > The can override: > > * Member names used struct declarations (int y) etc. .. yes; that doesn't improve anyone's understanding. > In short, they can already override everything, in a bad way, across > scopes and even reaching into tag and label namespaces. I hadn't even > realised this before, as I was concentrating on x.y. Yes. According to ISO C, if you define certain kinds of macros before including a standard header, the behavior is undefined. > So, there is no really big deal with using parameter names in > declarations, which are already affected now, for keyword parameters. Library headers tend to put all private identifiers in the __* or _[A-Z]* namespace. This includes all undocumented structure members; such as char __padding0[16]; // for binary compatibility and function parameter names (if they are at all present): int puts(char *__str); if named parameters are suddenly supported on library functions, they have to be public. It's just an influx of names, and those names have to be simple in order to be effective. They cannot be put into some prefixed namespace, because that would make them cumbersome. For instance, for memcpy in <string.h>, you might want nice short names like: void memcpy(void *dest, const void *source, size_t size); So now "dest", "source" and "size" have become reserved in the macro namespace. Perhaps "dst" and "src" would be nicer. It might be possible to restrict the vocabulary to just a couple dozen words that are reused. Anything with a format string uses "format", anything with a destination buffer "dest", size is always "size" and so on; a filename can always be "path", string argument always "str" if there is only one. If it's just twenty-something new identifiers, it doesn't seem like a big deal. -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 22:00 +0100 |
| Message-ID | <ucdp4i$ot46$1@dont-email.me> |
| In reply to | #172830 |
On 26/08/2023 20:49, Kaz Kylheku wrote: > On 2023-08-26, Bart <bc@freeuk.com> wrote: >> My point is that this bug in the language already exists. >> >> Macro names have module-wide scope, and can be program-wide when used in >> a shared header file. > > The pitfalls of a token-level preprocessor are thoroughly understood, > hopefully by everyone here. >> >> The can override: >> >> * Member names used struct declarations (int y) > > etc. .. yes; that doesn't improve anyone's understanding. > >> In short, they can already override everything, in a bad way, across >> scopes and even reaching into tag and label namespaces. I hadn't even >> realised this before, as I was concentrating on x.y. > > Yes. According to ISO C, if you define certain kinds of macros > before including a standard header, the behavior is undefined. > >> So, there is no really big deal with using parameter names in >> declarations, which are already affected now, for keyword parameters. > > Library headers tend to put all private identifiers in the > __* or _[A-Z]* namespace. > > This includes all undocumented structure members; such as > > char __padding0[16]; // for binary compatibility > > and function parameter names (if they are at all present): > > int puts(char *__str); > > if named parameters are suddenly supported on library functions, > they have to be public. I assume the reason for the underscope (I don't know why there are two and not one), is so that 'str' is not shadowed by a global macro name 'str' if that happens to be defined before 'puts'. If 'str' expands to something that isn't an identifier, it can cause a syntax error. OK, use a prefix then, if the alternative is not to have the feature at all. Note that somebody can still define a macro called 'puts'. Note also that gcc headers (that is, the headers that are associated with my gcc installation, in case somebody wants to bring that up again), use "_Str" for the parameter name, with one underscore and a capital letter. It's not clear what the purpose of these names is, unless they had keyword parameters already in mind. > > It's just an influx of names, and those names have to be simple in order > to be effective. They cannot be put into some prefixed namespace, > because that would make them cumbersome. > > For instance, for memcpy in <string.h>, you might want nice > short names like: > > void memcpy(void *dest, const void *source, size_t size); > > So now "dest", "source" and "size" have become reserved in the > macro namespace. Perhaps "dst" and "src" would be nicer. With the feature in place, people can create their own wrapper functions and make their own choices.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-26 17:31 -0400 |
| Message-ID | <WauGM.261906$uLJb.253016@fx41.iad> |
| In reply to | #172831 |
On 8/26/23 5:00 PM, Bart wrote: > On 26/08/2023 20:49, Kaz Kylheku wrote: >> On 2023-08-26, Bart <bc@freeuk.com> wrote: >>> My point is that this bug in the language already exists. >>> >>> Macro names have module-wide scope, and can be program-wide when used in >>> a shared header file. >> >> The pitfalls of a token-level preprocessor are thoroughly understood, >> hopefully by everyone here. >>> >>> The can override: >>> >>> * Member names used struct declarations (int y) >> >> etc. .. yes; that doesn't improve anyone's understanding. >> >>> In short, they can already override everything, in a bad way, across >>> scopes and even reaching into tag and label namespaces. I hadn't even >>> realised this before, as I was concentrating on x.y. >> >> Yes. According to ISO C, if you define certain kinds of macros >> before including a standard header, the behavior is undefined. >> >>> So, there is no really big deal with using parameter names in >>> declarations, which are already affected now, for keyword parameters. >> >> Library headers tend to put all private identifiers in the >> __* or _[A-Z]* namespace. >> >> This includes all undocumented structure members; such as >> >> char __padding0[16]; // for binary compatibility >> >> and function parameter names (if they are at all present): >> >> int puts(char *__str); >> >> if named parameters are suddenly supported on library functions, >> they have to be public. > > I assume the reason for the underscope (I don't know why there are two > and not one), is so that 'str' is not shadowed by a global macro name > 'str' if that happens to be defined before 'puts'. > > If 'str' expands to something that isn't an identifier, it can cause a > syntax error. > > OK, use a prefix then, if the alternative is not to have the feature at > all. yes, the parameters need either a double underscore prefix, or an underscore + upper case letter to be in the implementation name space, and usable there. > > Note that somebody can still define a macro called 'puts'. Note also > that gcc headers (that is, the headers that are associated with my gcc > installation, in case somebody wants to bring that up again), use "_Str" > for the parameter name, with one underscore and a capital letter. Not an include the header. If you include a header that defines puts, then the identifer puts becomes reserved for the implementation and the user can not define a macro by that name (without causeing undefined behavior). > > It's not clear what the purpose of these names is, unless they had > keyword parameters already in mind. The biggest purpose of the names is for error messages. IF you pass an incompatible type to that parameter, it ca > > > >> >> It's just an influx of names, and those names have to be simple in order >> to be effective. They cannot be put into some prefixed namespace, >> because that would make them cumbersome. >> >> For instance, for memcpy in <string.h>, you might want nice >> short names like: >> >> void memcpy(void *dest, const void *source, size_t size); >> >> So now "dest", "source" and "size" have become reserved in the >> macro namespace. Perhaps "dst" and "src" would be nicer. > > With the feature in place, people can create their own wrapper functions > and make their own choices. > And someone needs to put the effort in to show which option is suitable, so that something like this can move forward. Since once it is done, the name of the library parameters are defined, and changing them will be virtually impossible (due to breaking code compatibility), effort needs to be done to show something is good enough to live with.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-26 15:28 -0700 |
| Message-ID | <875y51e8vj.fsf@nosuchdomain.example.com> |
| In reply to | #172831 |
Bart <bc@freeuk.com> writes:
[...]
> I assume the reason for the underscope (I don't know why there are two
> and not one), is so that 'str' is not shadowed by a global macro name
> 'str' if that happens to be defined before 'puts'.
>
> If 'str' expands to something that isn't an identifier, it can cause a
> syntax error.
>
> OK, use a prefix then, if the alternative is not to have the feature at all.
Those aren't the only alternatives.
> Note that somebody can still define a macro called 'puts'. Note also
> that gcc headers (that is, the headers that are associated with my gcc
> installation, in case somebody wants to bring that up again),
No, I don't want to bring that up again. Why do you?
> use
> "_Str" for the parameter name, with one underscore and a capital
> letter.
>
> It's not clear what the purpose of these names is, unless they had
> keyword parameters already in mind.
The purpose is conformance. A strictly conforming program can define
"str" as a macro before including <stdio.h>.
A program that defines "puts" as a macro before including <stdio.h> had
undefined behavior; see N1570 7.1.3p1, last bullet point. File scope
identifiers, including function names declared in standard headers, are
reserved for use a macro names. Parameter names are not.
[...]
--
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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-27 04:24 +0000 |
| Message-ID | <20230826210521.20@kylheku.com> |
| In reply to | #172831 |
On 2023-08-26, Bart <bc@freeuk.com> wrote: > With the feature in place, people can create their own wrapper functions > and make their own choices. Yikes; just what we need: people scrambling the order of arguments to standard functions, using their own local names. Quick, which one is the destination? strcpy(goat: userid, fish: uid); :) -- 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-08-26 21:59 -0700 |
| Message-ID | <ucel76$11gfl$2@dont-email.me> |
| In reply to | #172858 |
On 8/26/2023 9:24 PM, Kaz Kylheku wrote: > On 2023-08-26, Bart <bc@freeuk.com> wrote: >> With the feature in place, people can create their own wrapper functions >> and make their own choices. > > Yikes; just what we need: people scrambling the order of arguments > to standard functions, using their own local names. > > Quick, which one is the destination? > > strcpy(goat: userid, fish: uid); > > :) > fish:shark eats goat userid 42?
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web