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 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 20:01 +0200 |
| Message-ID | <ucine0$1q9jg$1@dont-email.me> |
| In reply to | #173024 |
On 28/08/2023 19:01, Bart wrote:
> On 28/08/2023 17:41, David Brown wrote:
>> On 28/08/2023 16:53, Bart wrote:
>>> On 28/08/2023 15:15, Scott Lurndal wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>> [...]
>>>>>> If required, positional parameters are going to be callable using
>>>>>> named
>>>>>> arguments, the named arguments must be a mandatory part of the
>>>>>> function
>>>>>> definition.
>>>>>
>>>>> Named arguments are already mandatory for function definitions
>>>>> (barring
>>>>> old-style definitions).
>>>>
>>>> Nit, IIRC, you don't need the name if you don't use the parameter.
>>
>> That's true in C++, but not true in C until C2x comes out.
>
> Why is the standard moving backwards?
What do you mean?
C2x allows you to omit names for parameters you don't use in a function
definition. How is that "moving backwards" ? You still need the proper
prototype, and you still need to include the arguments when calling the
function.
It is not uncommon to have compiler warnings on unused variables and
parameters - if a function takes a parameter, and the definition does
not use it somehow, then it's likely there's a mistake somewhere. But
that is not always the case, so such warnings have relatively high false
positive rates, and then you have to have explicit indication that the
parameter is intentionally unused. That's not a bad idea from the point
of view of documenting what the code is doing, but an alternative option
in C++, and now in C2x, is to simply omit a name for the parameter.
(Whether you like that or not is a matter of opinion, and you can use
the feature or ignore it.)
>
>
>>
>>>>
>>>
>>> This program:
>>>
>>> void F(int,int,int) {}
>>>
>>> int main(void) {}
>>>
>>> generally results in hard errors in I think 5 out of 6 compilers I
>>> tried. Only gcc on Windows passed it with no comment.
>>
>> As you know, gcc does not try to be accurately conforming to the
>> standards unless you give it appropriate command line flags.
>
> 'gcc c.c' on Windows (13.2.0) passed it; 'gcc c.c' on WSL (9.4.0)
> failed it.
That does not surprise me. Newer gcc has support for some parts of C2x,
older gcc does not.
>
> I've given up trying to make sense of gcc's behaviour. WHATEVER it does
> or doesn't do, even when it contradicts itself, people will always find
> an excuse for it.
OK. Maybe I should stop trying to explain it to you? (Note that
explaining why gcc does something is not the same thing as making an
excuse for it, or liking it. I personally would prefer if it followed
the standards more strictly by default.)
>
> But this one is unusual: normally newer gcc tries to continue passing
> legacy code that older versions passed. Now, it can be passing code that
> older versions *failed*.
And the problem with that is... what? Nothing, as far as I can see.
It can be a problem if old code used to work with older gcc and fails to
work with newer gcc. But it's not a problem if something works on newer
gcc and fails on older gcc - that's entirely natural with new versions
of tools.
>
>> If you don't like that, you know what flags to give gcc to get the
>> standards-required diagnostic.
>
> As I said...
You didn't say anything related to that.
>
>> (The standards do not require a "hard error". For some kinds of
>> mistakes in code, I would agree with you that a hard error would be
>> far better than a warning or silently accepting the code by default -
>> but in this case, a hard error is an overreaction unless you want to
>> enforce very strict checking.)
>
> In this case, the rule can very simple: each parameter name in a
> definiton MUST be named.
That's certainly a simple rule.
But is it a useful rule? I can't see it being particularly important.
If anything, I'd prefer a rule saying parameter names were necessary in
declarations - that's the bit seen by people using the function.
Parameter names for unused parameters in a function definition add very
little to the code.
>
> (Accidentally delete a parameter name 'abc', and it's possible that a
> reference to that parameter in the function now matches a global 'abc'.)
>
That's a conceivable reason, yes. But is it likely? You'd have to
accidentally delete a bit of your code - accidentally deleting bits of
your code can always have adverse effects, no matter what. That's why
we have keyboard shortcuts for saving files often, undo features for
when you've made such a mistake, and "commit often" policies for source
code control. And how often do your parameter names shadow global
identifiers? Rarely, I would say, in well-written code (though it
certainly /can/ happen). And of course the shadowed identifier would
have to be of an appropriate type.
Note that C++ has had this feature for decades - I've never heard anyone
complain about it. (And people complain about C++ a /lot/.)
I think there are many things that are more likely to be errors in code.
(And I am confident that there are other things in C2x that you will
dislike far more than this. C2x has so many new features that I think
you'll be hard pushed to find someone who likes them all.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-28 20:14 +0100 |
| Message-ID | <ucirmk$1r066$1@dont-email.me> |
| In reply to | #173035 |
On 28/08/2023 19:01, David Brown wrote:
> On 28/08/2023 19:01, Bart wrote:
>> Why is the standard moving backwards?
>
> What do you mean?
>
> C2x allows you to omit names for parameters you don't use in a function
> definition. How is that "moving backwards" ?
We want a stricter language moving forward and less of the crazy
flexibility of older versions.
What other missing bits of syntax can we assign some arbitrary meaning
to rather than being called out as obvious errors?
How about, leaving out a function name in a definition, when that
function is not called?
>> But this one is unusual: normally newer gcc tries to continue passing
>> legacy code that older versions passed. Now, it can be passing code
>> that older versions *failed*.
>
> And the problem with that is... what? Nothing, as far as I can see.
It was an error before for a good reason. Now somebody decided you need
to take away some redundancy so that they can declare unused parameters
without the compiler moaning about it.
So that actual errors, like accidentally missing out a name, are harder
to detect.
There are also lots of reasons for a parameter name not to be used in
some compilations out of dozens or hundreds:
Maybe you've only got as far as writing a skeleton function and not all
params are yet use, or in the middle of writing it, or it's being
changed, or parts are temporarily commented out. It's a WIP!
Yet an overzealous compiler might warn about an unused parameter name.
There must be better ways of shutting it up than deleting the name
completely. So, what was it again, when you decide to use it?
What about declarations? It would be perverse for those to define a name
for a parameter which is not named nor used in the definition (what
would it be called?).
The whole thing has a very bad smell to me.
Using Godbolt, I can see that gcc up to 11.1 failed missing parameter
names. From 11.1 onward, such code passes.
On C, code fails on older versions, and gives warnings from 11.0.0 onwards.
In MSVC, code fails on all versions. So:
Older Newer/current
GCC Fail Pass
Clang Fail Warning
MSVC Fail Fail
bcc --- Fail
tcc --- Fail
Nice to see consistency in a language! All those languages in the final
column are still C. I think.
Of course, a really useful enhancement such as declaring multiple
parameter names under the same shared type doesn't get a look-in:
void F(int a, b, c) {}
> But is it a useful rule? I can't see it being particularly important.
>
> If anything, I'd prefer a rule saying parameter names were necessary in
> declarations - that's the bit seen by people using the function.
> Parameter names for unused parameters in a function definition add very
> little to the code.
Which, of course, is totally backwards. Most things in this newsgroup are!
Parameter names in declarations are optional: you can take them all out,
and programs would still compile.
Not so with parameter names in definitions.
Actually, I've never across missing parameter names in definitions in
the million lines of code I've passed through my C compiler. Or maybe
everyone has been waiting for 50 years for just that feature.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-28 19:27 +0000 |
| Message-ID | <zy6HM.837180$TPw2.12699@fx17.iad> |
| In reply to | #173039 |
Bart <bc@freeuk.com> writes: >On 28/08/2023 19:01, David Brown wrote: >> On 28/08/2023 19:01, Bart wrote: > >>> Why is the standard moving backwards? >> >> What do you mean? >> >> C2x allows you to omit names for parameters you don't use in a function >> definition. How is that "moving backwards" ? > >We want a stricter language moving forward Are you using the royal "we" here? The plural definite article surely doesn't apply.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 16:09 -0700 |
| Message-ID | <86edjmwyr4.fsf@linuxsc.com> |
| In reply to | #173044 |
scott@slp53.sl.home (Scott Lurndal) writes: [...] > Are you using the royal "we" here? I think the narcissistic "we" is more likely.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 21:53 +0200 |
| Message-ID | <ucitv4$1rcba$1@dont-email.me> |
| In reply to | #173039 |
On 28/08/2023 21:14, Bart wrote:
> On 28/08/2023 19:01, David Brown wrote:
>> On 28/08/2023 19:01, Bart wrote:
>
>>> Why is the standard moving backwards?
>>
>> What do you mean?
>>
>> C2x allows you to omit names for parameters you don't use in a
>> function definition. How is that "moving backwards" ?
>
> We want a stricter language moving forward and less of the crazy
> flexibility of older versions.
I am certainly in favour of things that make it easier to find or
prevent errors. And there are certainly some flexibilities in C that
make it easier for some kinds of errors to slip by. (For my own
development, I use a lot of warnings in gcc as a way to limit the
language and reduce possibilities. Many people do this - it is also
popular to adhere to coding standards or style guides.)
However, I really do not see this particular case as a problem.
>
> What other missing bits of syntax can we assign some arbitrary meaning
> to rather than being called out as obvious errors?
Let's stick to the issue at hand.
>
> How about, leaving out a function name in a definition, when that
> function is not called?
>
And let's not go overboard.
We are letting unused parameters be anonymous. Letting unused things be
anonymous is often a good thing - it reduces clutter and saves having to
invent identifiers that are never actually needed. Thus we have
anonymous unions and anonymous structs.
>
>>> But this one is unusual: normally newer gcc tries to continue passing
>>> legacy code that older versions passed. Now, it can be passing code
>>> that older versions *failed*.
>>
>> And the problem with that is... what? Nothing, as far as I can see.
>
> It was an error before for a good reason. Now somebody decided you need
> to take away some redundancy so that they can declare unused parameters
> without the compiler moaning about it.
Remember we are talking about /unused/ parameters. There was not really
a good reason to require them to have names, and in C2x they won't be
needed.
A typical use-case for this is for call-backs. Call-back function types
often have parameters such as a "void *" user data pointer, or perhaps
parameters for handles or instances (of whatever thing is doing the
call-back). These can be very useful for writing generic call-back
functions that handle many cases. But if you only need one case, you
don't really want parameters at all. Of course you must still declare
the right number and types of parameters in C - those must match.
Omitting the parameter names seems a nice convenience. (Some people
will prefer to have the names anyway, and that's also fine.)
>
> So that actual errors, like accidentally missing out a name, are harder
> to detect.
It is important to detect errors that are likely. It is a lot less
important to detect errors that are very unlikely to be made.
>
> There are also lots of reasons for a parameter name not to be used in
> some compilations out of dozens or hundreds:
>
> Maybe you've only got as far as writing a skeleton function and not all
> params are yet use, or in the middle of writing it, or it's being
> changed, or parts are temporarily commented out. It's a WIP!
Sure. And there is nothing stopping you from including the parameter
name - omission is optional.
>
> Yet an overzealous compiler might warn about an unused parameter name.
> There must be better ways of shutting it up than deleting the name
> completely. So, what was it again, when you decide to use it?
There /are/ other ways of doing it.
A common way, supported by most compilers, is a cast to void :
int foo(int x, int y) {
(void) y; // y is intentionally unused
return x + 1;
}
Compilers also often have their own methods, such as gcc's
"maybe_unused" attribute (others have pragmas, declspecs, or other methods).
If you think it is clearer to use "(void) y" in such a situation, rather
than omitting the parameter name, then write that. I probably will
continue to do so in my own code - it's not a feature I expect to have
much use of personally. But others could well find it neat.
>
>
> What about declarations? It would be perverse for those to define a name
> for a parameter which is not named nor used in the definition (what
> would it be called?).
You don't have to have parameter names in declarations in today's code.
You don't have to have consistency between the names in declarations and
definitions. (You can well say that this is a bad thing - and I'd agree
with you, even though I understand why enforcing consistency would not
be an easy fit with the rest of the language. But whatever your opinion
on this is, you must understand that this is how C is defined.)
Allowing function definitions to omit parameter names lets you be
consistent with declarations that omit parameter names. So it is a win
for consistency.
>
> The whole thing has a very bad smell to me.
>
> Using Godbolt, I can see that gcc up to 11.1 failed missing parameter
> names. From 11.1 onward, such code passes.
Yes, as I explained - this is not a surprise.
(Again, I would have preferred an error, or at least a warning, if the
C2x standard were not explicitly chosen. Don't mistake understanding
for liking.)
>
>> But is it a useful rule? I can't see it being particularly important.
>>
>> If anything, I'd prefer a rule saying parameter names were necessary
>> in declarations - that's the bit seen by people using the function.
>> Parameter names for unused parameters in a function definition add
>> very little to the code.
>
> Which, of course, is totally backwards. Most things in this newsgroup are!
>
> Parameter names in declarations are optional: you can take them all out,
> and programs would still compile.
>
> Not so with parameter names in definitions.
>
> Actually, I've never across missing parameter names in definitions in
> the million lines of code I've passed through my C compiler. Or maybe
> everyone has been waiting for 50 years for just that feature.
>
Why would you expect to come across missing parameter names in
definitions? They are not legal in C as yet - C2x is not published.
And even after it comes out, you won't expect to see it in much code for
a long time - C programmers are conservative in using new standards.
You'd see it sometimes in C++ code, but obviously that's not something
you'd give to your compiler.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-28 20:37 +0000 |
| Message-ID | <20230828125920.929@kylheku.com> |
| In reply to | #173039 |
On 2023-08-28, Bart <bc@freeuk.com> wrote:
> On 28/08/2023 19:01, David Brown wrote:
>> On 28/08/2023 19:01, Bart wrote:
>
>>> Why is the standard moving backwards?
>>
>> What do you mean?
>>
>> C2x allows you to omit names for parameters you don't use in a function
>> definition. How is that "moving backwards" ?
>
> We want a stricter language moving forward and less of the crazy
> flexibility of older versions.
What?
> What other missing bits of syntax can we assign some arbitrary meaning
> to rather than being called out as obvious errors?
>
> How about, leaving out a function name in a definition, when that
> function is not called?
Yes, that is possible with this same feature:
void foo_api_bar_impl(int arg, void (*)(char *))
{
// ...
}
This bar implementation of the foo API found that it didn't need to
store or call the function pointer parameter, so it didn't name it.
In C++ implementations, this feature suppresses warnings about unused
parameters. If it's not used, but not named, then there is nothing to
complain about.
C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
prototype declaration, parameter names can be omitted.
C++ just allowed that syntax in definitions, which looks like a
miniscule extension that has as a palpable impact on usability.
C programmers have wasted lines of code on things like
void foo_api_bar_impl(int arg, void (*fn)(char *))
{
UNUSED(fn); // this project's own unused macro
}
>>> But this one is unusual: normally newer gcc tries to continue passing
>>> legacy code that older versions passed. Now, it can be passing code
>>> that older versions *failed*.
>>
>> And the problem with that is... what? Nothing, as far as I can see.
>
> It was an error before for a good reason. Now somebody decided you need
> to take away some redundancy so that they can declare unused parameters
> without the compiler moaning about it.
C++ has had this feature for decades. Adopting it into C improves the
range of compatibility between the languages.
The "void *" type came from C++; if ANSI C hadn't adopted it, that would
have been a major rift. It's not adopted in the same form though;
C is more loose in conversion from void *.
ANSI C invented the (void) parameter list; in C++ it was just ().
C++ doesn't support old-style unprototyped declarations, so it doesn't
need this. Yet, C++ implemented (void) for compatibility.
Compatibility matters. Less work when preparting a header file usable
in C and C++. Less work converting C code to C++.
> So that actual errors, like accidentally missing out a name, are harder
> to detect.
Accidentally missing a name makes itself loudly heard when you use
the name and it's not defined.
You could have a bug whereby it is defined, but in an outer scope;
that's too bad for you.
Since standard C doesn't have nested functions, that would have to be a
clash between a intended/forgotten local and global, which indicates
that you're using a local-like naming scheme for globals.
> There are also lots of reasons for a parameter name not to be used in
> some compilations out of dozens or hundreds:
>
> Maybe you've only got as far as writing a skeleton function and not all
> params are yet use, or in the middle of writing it, or it's being
> changed, or parts are temporarily commented out. It's a WIP!
If you think you will use the parameters, you will likely put in
their names and live with the unused diagnostics which remind you
to complete the work.
> Yet an overzealous compiler might warn about an unused parameter name.
This is not overzealous. Diagnosis of unused lexical variables uncovers
bugs. You want this in any language with lexical scopes, and to be on by
default.
I added it to TXR Lisp not long ago.
Only the compiler warns about it, not the interpreter.
Both warn about an unbound variable.
No peep out of interpreter:
1> (let (x))
nil
Intepreter warns about y before running code, then the error
happens:
2> (let (x) y)
** expr-2:1: warning: unbound variable y
** expr-2:1: unbound variable y
Compiler warns about unused x and undefined y, but generates code.
3> (compile-toplevel '(let (x) y))
** expr-3:1: warning: unbound variable y
** expr-3:1: warning: let: variable x unused
#<sys:vm-desc: 8b9e5c0>
Code bombs when run:
4> [*3]
** expr-2:1: variable y is not defined
Unused variables are code smell which can indicate an actual
bug like: (defun add (x y) (+ x x)).
Sometimes unused variables are just crumbs left after refactoring;
it's good to clean them out.
> There must be better ways of shutting it up than deleting the name
> completely. So, what was it again, when you decide to use it?
If the option is available in the syntax, there is nothing better.
All else being equal, subtracting a token to achieve a goal is
better than adding more tokens.
> What about declarations? It would be perverse for those to define a name
> for a parameter which is not named nor used in the definition (what
> would it be called?).
No it wouldn't.
The declaration might be like this:
void foo_api_register_bar_callback(void *context,
void (*callback_fn)(void *context,
void *buffer,
size_t size));
You're implementing the callback and find you don't need a context:
void my_bar_callback(void *, void *buffer, size_t size)
{
}
Just because you don't need that parameter in your implementation of the
callback doesn't mean that the master declaration for it should omit the
name, too. The naming (assuming it does not lie) tells us that the
context parameter that will be passed to the callback is that one that
is passed to the registration function.
Obviously, you lack experience in C and C++, due to working in other
things, but you have a lot of opinions.
> On C, code fails on older versions, and gives warnings from 11.0.0 onwards.
>
> In MSVC, code fails on all versions. So:
>
> Older Newer/current
>
> GCC Fail Pass
> Clang Fail Warning
> MSVC Fail Fail
>
> bcc --- Fail
> tcc --- Fail
>
> Nice to see consistency in a language! All those languages in the final
> column are still C. I think.
They are a newer dialect of C. Obviously, you can't use the feature
if your code has to work with older compilers (that are not C++).
C is fragmented into numerous dialects with each new revision of
the language.
So is anything you've written yourself.
Any change you make to a language, whether an ISO-standard definition,
or your own project, means that something works no that won't work
with yesterday's version.
Every real, functional change is testable by a test case which fails if
the change is absent and passes when the change is present.
(If you can't write such a test for a change, it must be some
refactoring or code cleanup.)
For a language, that test case is a piece of code that is not supported
by the version of the language before the change.
Every commit that you make like this splinters the dialect into
before that commit and after.
> Actually, I've never across missing parameter names in definitions in
> the million lines of code I've passed through my C compiler. Or maybe
> everyone has been waiting for 50 years for just that feature.
Yes; it's a bleeding-edge feature, so you wouldn't have encountered
that. If you'd supported a million lines of C++, you probably would
have.
--
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-28 23:39 +0100 |
| Message-ID | <ucj7n7$1svn8$1@dont-email.me> |
| In reply to | #173072 |
On 28/08/2023 21:37, Kaz Kylheku wrote:
> On 2023-08-28, Bart <bc@freeuk.com> wrote:
>> On 28/08/2023 19:01, David Brown wrote:
>>> On 28/08/2023 19:01, Bart wrote:
>>
>>>> Why is the standard moving backwards?
>>>
>>> What do you mean?
>>>
>>> C2x allows you to omit names for parameters you don't use in a function
>>> definition. How is that "moving backwards" ?
>>
>> We want a stricter language moving forward and less of the crazy
>> flexibility of older versions.
>
> What?
>
>> What other missing bits of syntax can we assign some arbitrary meaning
>> to rather than being called out as obvious errors?
>>
>> How about, leaving out a function name in a definition, when that
>> function is not called?
>
> Yes, that is possible with this same feature:
>
>
> void foo_api_bar_impl(int arg, void (*)(char *))
> {
> // ...
> }
>
> This bar implementation of the foo API found that it didn't need to
> store or call the function pointer parameter, so it didn't name it.
My remark was about leaving out the main name of the function, like:
void (int arg, void (*)(char *)){}
If this function is never called, then it might stop some compilers
reporting that fact.
Although you will quickly find this is not practical: if you have a lot
of such anonymous functions, that you later need to call, you will no
longer know which is which.
Which helps to highlight another thing with missing parameter names; say
you end up with a function like this:
void F(int a, int, char* c, char*, int, int, int) {}
Later you decide that you do need to use one of those parameters, but
which one was it? That useful information imparted by the name doesn't
exist.
> In C++ implementations, this feature suppresses warnings about unused
> parameters. If it's not used, but not named, then there is nothing to
> complain about.
>
> C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
> prototype declaration, parameter names can be omitted.
That's not really surprising, since probably the same bit of grammar
covers both declaration and definition parameter lists.
And in the former, names can be added or omitted on a per-parameter basis.
So, an untidy bit of syntax, all-told.
(In the syntaxes I use, it is stricter:
* Parameters all have types only, no names (only in FFIs)
* Parameters all have types and names
* Parameters have names only (only in dynamic code)
You can't mix and match. And of course, a function definition must be
one of the last two. As is also necessary to make use of keyword
parameters and/or default values.
Detecting unused variables of any sort I consider the job of a tool
other than the compiler, although the compiler can make use of such info
internally to improve the code.)
> C++ just allowed that syntax in definitions, which looks like a
> miniscule extension that has as a palpable impact on usability.
>
> C programmers have wasted lines of code on things like
>
> void foo_api_bar_impl(int arg, void (*fn)(char *))
> {
> UNUSED(fn); // this project's own unused macro
> }
Excuse me, but that is just a problem with the compiler. You shouldn't
need to modify or annotation your code, or removed potentially useful
information, just to silence a warning.
I think if I had to do something on those lines, I would use parameter
names starting with '$'. Then no warnings are given; I don't need to
annotate; I can use a more consistent grammar rule; and I retain a
reminder of what the names for those parameters not currently refered to;
I could even use that parameter name later, with the '$', but it might
be simpler to delete that one character.
>>>> But this one is unusual: normally newer gcc tries to continue passing
>>>> legacy code that older versions passed. Now, it can be passing code
>>>> that older versions *failed*.
>>>
>>> And the problem with that is... what? Nothing, as far as I can see.
>>
>> It was an error before for a good reason. Now somebody decided you need
>> to take away some redundancy so that they can declare unused parameters
>> without the compiler moaning about it.
>
> C++ has had this feature for decades. Adopting it into C improves the
> range of compatibility between the languages.
What was it used for in C++?
> Accidentally missing a name makes itself loudly heard when you use
> the name and it's not defined.
>
> You could have a bug whereby it is defined, but in an outer scope;
> that's too bad for you.
That's not a bug. It's called shadowing, a useful feature meaning you
can reuse identifiers in their own private scope, without needing to
have unique identifiers throughout a translation unit. This is not assembly!
> Since standard C doesn't have nested functions, that would have to be a
> clash between a intended/forgotten local and global, which indicates
> that you're using a local-like naming scheme for globals.
But gnu C has. Which itself leads to slightly inexplicable errors when
you forget the } at the end of a function, and the following 400
functions are assumed to be nested.
> If you think you will use the parameters, you will likely put in
> their names and live with the unused diagnostics which remind you
> to complete the work.
Sometimes I have a suite of functions which must all share the same
signature, as they accessed from a table of function pointers.
But the functions do different somewhat different tasks and may not use
all the parameters. I wouldn't be happy about those 200 or whatever
functions ending up with parameter lists looking like this:
(int a, int b, int c)
(int a, int, int)
(int a, int b, int)
(int, int, int c)
>> Yet an overzealous compiler might warn about an unused parameter name.
>
> This is not overzealous. Diagnosis of unused lexical variables uncovers
> bugs. You want this in any language with lexical scopes, and to be on by
> default.
So you run a tool to check that every so often, or use that compiler option.
> Code bombs when run:
>
> 4> [*3]
> ** expr-2:1: variable y is not defined
>
> Unused variables are code smell which can indicate an actual
> bug like: (defun add (x y) (+ x x)).
OK, so that's good. But here you want to use that parameter.
What happens what you really want to use only x, but it is necessary to
pass two (maybe it has to be a certain pattern); how do you indicate
that here?
Leave out y turns in into a one-parameter function; it needs to be two!
So it's trickier in a language without type annotations as place-holders.
>
> Sometimes unused variables are just crumbs left after refactoring;
> it's good to clean them out.
>
>> There must be better ways of shutting it up than deleting the name
>> completely. So, what was it again, when you decide to use it?
>
> If the option is available in the syntax, there is nothing better.
I mentioned a possibility above.
> All else being equal, subtracting a token to achieve a goal is
> better than adding more tokens.
You're also taking away what could be vital information needed to
restore the name, or deciding which parameter you restoring it to.
>> GCC Fail Pass
>> Clang Fail Warning
>> MSVC Fail Fail
> They are a newer dialect of C. Obviously, you can't use the feature
> if your code has to work with older compilers (that are not C++).
And yet, using the most recent versions of 3 major compilers at the time
of writing, one passes, one warns, one fails!
Talk about being equivocal. You'd think a C compiler would know whether
an input is valid C or not.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 00:23 +0000 |
| Message-ID | <20230828160956.758@kylheku.com> |
| In reply to | #173104 |
On 2023-08-28, Bart <bc@freeuk.com> wrote:
> On 28/08/2023 21:37, Kaz Kylheku wrote:
>> On 2023-08-28, Bart <bc@freeuk.com> wrote:
>>> On 28/08/2023 19:01, David Brown wrote:
>>>> On 28/08/2023 19:01, Bart wrote:
>>>
>>>>> Why is the standard moving backwards?
>>>>
>>>> What do you mean?
>>>>
>>>> C2x allows you to omit names for parameters you don't use in a function
>>>> definition. How is that "moving backwards" ?
>>>
>>> We want a stricter language moving forward and less of the crazy
>>> flexibility of older versions.
>>
>> What?
>>
>>> What other missing bits of syntax can we assign some arbitrary meaning
>>> to rather than being called out as obvious errors?
>>>
>>> How about, leaving out a function name in a definition, when that
>>> function is not called?
>>
>> Yes, that is possible with this same feature:
>>
>>
>> void foo_api_bar_impl(int arg, void (*)(char *))
>> {
>> // ...
>> }
>>
>> This bar implementation of the foo API found that it didn't need to
>> store or call the function pointer parameter, so it didn't name it.
>
> My remark was about leaving out the main name of the function, like:
>
> void (int arg, void (*)(char *)){}
>
> If this function is never called, then it might stop some compilers
> reporting that fact.
In fact we can write, equivalently:
void foo_api_bar_impl(int arg, void (char *))
// ^ no name
Leaving out the top-level name of a function is interesting, but
I don't see how it makes sense.
The reason we would likee to remove the parameter name is that
the parameter must continue to exist; it itself cannot be removed, since
the calls to the functions are passing it an argument.
If a function is not called from anywhere, we just remove it.
We can't always edit calls to a function to remove an argument.
Sometimes in code we don't control, and possibly in callback interfaces
with multiple implementations, where you can't/don't want to remove a
parameter even if you do control everything.
> Although you will quickly find this is not practical: if you have a lot
> of such anonymous functions, that you later need to call, you will no
> longer know which is which.
>
> Which helps to highlight another thing with missing parameter names; say
> you end up with a function like this:
>
> void F(int a, int, char* c, char*, int, int, int) {}
If this is registered as a callback somewhere, we find that line:
register_foo_callback(F, whatever);
Then we look at the definitition of that to understand what the
arguments mean.
F could also have a declaration where the parameters are named,
and the could be documented in a block comment there.
>
>> In C++ implementations, this feature suppresses warnings about unused
>> parameters. If it's not used, but not named, then there is nothing to
>> complain about.
>>
>> C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
>> prototype declaration, parameter names can be omitted.
>
> That's not really surprising, since probably the same bit of grammar
> covers both declaration and definition parameter lists.
>
> And in the former, names can be added or omitted on a per-parameter basis.
>
> So, an untidy bit of syntax, all-told.
It's untidy; only, the viable alternatives are worse.
> (In the syntaxes I use, it is stricter:
> * Parameters all have types only, no names (only in FFIs)
> * Parameters all have types and names
> * Parameters have names only (only in dynamic code)
That's very nice, but you've not convinced the world to standardize
on those syntaxes, and develop an entire free operating system,
and multitude of tools and applications, and so on.
For now we are stuck with what we have.
People working on replacements are by and large making the programming
experience worse. More complicated, more convoluted, more siloed into
their little necks of the woods.
Make me a concrete recommendation on how to code, and what with.
In my work and side projects, I target 32 and 64 bit ARM boards,
desktop GNU/Linuxes (Ubuntu, Debian, Nix, Guix, ...), MacOS, Solaris,
Android.
> Detecting unused variables of any sort I consider the job of a tool
> other than the compiler, although the compiler can make use of such info
> internally to improve the code.)
So you like tools other than the compiler eh? Oh, except when they
are called "make" for building stuff, and whatnot; then tools not
in the compiler are bad.
If a compiler just improves the code (e.g. eliminatees dead code)
but doesn't remark on unusd variables, it's being only halfway helfpul.
This is really a "low hanging fruit" diagnosis; it has a decent payoff
relative to implementation cost and difficulty.
>> C++ just allowed that syntax in definitions, which looks like a
>> miniscule extension that has as a palpable impact on usability.
>>
>> C programmers have wasted lines of code on things like
>>
>> void foo_api_bar_impl(int arg, void (*fn)(char *))
>> {
>> UNUSED(fn); // this project's own unused macro
>> }
>
> Excuse me, but that is just a problem with the compiler. You shouldn't
> need to modify or annotation your code, or removed potentially useful
> information, just to silence a warning.
Yet, someone hit upon that idea, and people liked it.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-29 01:01 -0700 |
| Message-ID | <6dcdb286-1371-4b0b-935d-0c543782eb3cn@googlegroups.com> |
| In reply to | #173129 |
On Tuesday, 29 August 2023 at 01:23:52 UTC+1, Kaz Kylheku wrote: > > If a compiler just improves the code (e.g. eliminatees dead code) > but doesn't remark on unusd variables, it's being only halfway helfpul. > > This is really a "low hanging fruit" diagnosis; it has a decent payoff > relative to implementation cost and difficulty. > The problem is that people have a hysterical attitude to warnings, and that occasionally, not so often, but not so infrequently either, there is a legitimate need for an unused variable. The obvious case is an unused parameter which is necessary to pass the function indirectly, because other functions called through the same function pointer do use the parameter.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 19:28 +0000 |
| Message-ID | <20230829122230.303@kylheku.com> |
| In reply to | #173159 |
On 2023-08-29, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On Tuesday, 29 August 2023 at 01:23:52 UTC+1, Kaz Kylheku wrote: >> >> If a compiler just improves the code (e.g. eliminatees dead code) >> but doesn't remark on unusd variables, it's being only halfway helfpul. >> >> This is really a "low hanging fruit" diagnosis; it has a decent payoff >> relative to implementation cost and difficulty. >> > The problem is that people have a hysterical attitude to warnings, and > that occasionally, not so often, but not so infrequently either, there is > a legitimate need for an unused variable. There must be a way to silence these diagnostics on a case-by-case basis, which is not obtrusive. -- 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-29 11:08 +0100 |
| Message-ID | <uckg25$278cn$1@dont-email.me> |
| In reply to | #173129 |
On 29/08/2023 01:23, Kaz Kylheku wrote: > On 2023-08-28, Bart <bc@freeuk.com> wrote: > People working on replacements are by and large making the programming > experience worse. More complicated, more convoluted, more siloed into > their little necks of the woods. > > Make me a concrete recommendation on how to code, and what with. > > In my work and side projects, I target 32 and 64 bit ARM boards, > desktop GNU/Linuxes (Ubuntu, Debian, Nix, Guix, ...), MacOS, Solaris, > Android. If I had to target those machines, I would write in my language, and generate C code because C compilers will exist for those platforms. But I would only use a subset of the language. It could actually be quite a small subset. There are a number of problems in using C as an intermediate language but it's easier than writing dedicated backends for each. However, it means that for everyday writing of writing code, I'd be using my own language, only moderately crippled by needing to avoid features that can't be expressed as C. And that language already has features like keyword parameters. If I was writing those programs however, I would need Tiny C installed, since relying on gcc as a backend would be like driving into a brick wall. So, that's my own solution: either use my language directly on a fully supported platform, or use my transpiler. > >> Detecting unused variables of any sort I consider the job of a tool >> other than the compiler, although the compiler can make use of such info >> internally to improve the code.) > > So you like tools other than the compiler eh? Oh, except when they > are called "make" for building stuff, and whatnot; then tools not > in the compiler are bad. I don't have such a tool. Unlike make, it is not something necessary for turning source code into a running program. Imagine that you mainly using C compilers to turn machine-generated code into executable binary. All the validation, to the standards of the original language, has been done. There should be no errors in the C code. I don't want the compiler wasting time on speculation; just do the translation to native code. (I just activated the -unused option of my compiler. It needed only two extra lines of code in the optimiser, since that is where it decides to whether to bother dealing with locals. It's something I might use every so often, the same time I might decide to get rid of ugly commented-out debugging code and generally tidy things up. It's not something I want seeing 100s of times a day.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-28 01:31 +0100 |
| Message-ID | <ucgptp$1coeu$1@dont-email.me> |
| In reply to | #172902 |
On 27/08/2023 23:45, Kaz Kylheku wrote:
> On 2023-08-27, Bart <bc@freeuk.com> wrote:
>> On 27/08/2023 05:24, 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);
>>>
>>
>> That's an excellent idea, I've just changed my FFI strcpy, which hadn't
>> had parameter names up to now, to this:
>>
>> func strcpy(ichar goat, fish="<Insert string here>")ichar
>>
>> Now I can write:
>>
>> strcpy(fish:"Hello", goat:str)
>>
>> or even just:
>>
>> strcpy(str)
>>
>> Silly, but at least I can do it. The more useful, non-silly applications
>> outnumber the silly ones.
>>
>> Remember that C's macro processor can do a LOT worse:
>>
>> #define int float
>>
>> #define while if
>
> This argument is like: crack can do worse, so just give the kids
> cigarettes.
The argument is more like: kids can already legally buy crack, but let's
stop them buying cigarettes. (Which I believe would actually be a safer
habit.)
> The only way this can be sanely introduced into C with backward
> compatibility is if there is a separate way to introduce the
> parameter names used for named calling, like this:
>
>
> char *strcpy(const char * : dest, char * : src);
>
> THe syntax for the declaread identifier in a function declaration
> would be:
>
> ident_opt
> | ident ':' ident_opt
> | ':' ident
> | /* nothing */
>
> The identifier after the ':' is available for specifying named
> arguments. Only functions which are declared this way support
> named arguments.
So what goes inside a function definition? Do you have to write this:
char *strcpy(const char * dest : dest, char * src : src);
Or will all existing definitions need to end up as:
char *strcpy(const char * : dest, char * : src);
with the extra colon? If so, will these identifiers also serve as naming
the parameters for use inside the function?
Could somebody do this:
char *strcpy(const char * dest : src, char * src : dest);
> If at least one parameter of a function declaration uses the
> above ':' syntax, then all parameters implicitly have argument
> names, even without ussing ':'.
> When only the ':' is given, not followed by an identifier,
> then that specifies a named argument which inherits the parameter
> name: foo : is the same as foo : foo.
Sorry, too complicated.
> If a parameter is asssociated with an argument name implicitly,
> without the use of the : syntax above, because some other
> parameter uses the : syntax, then the argument name is
> the same as the parameter name, as if : were given followed
> by nothing or by a repetition of the parameter name.
>
> Constraints:
>
> - The argument names need not be the same as the parameter names,
> but must be unique among themselves.
>
> - An argument name associated with a parameter may be the same
> as that parameter name; but must not be the same as any other
> parameter name.
>
> - If a declaration of a function uses argument names, all other
> declarations of the function must use argument names, and the
> names must be the same. The parameter names need not be.
>
> Implementations could support a macro to enable names, like
>
> #define __stdc_argument_names 1
>
> Inside a header, it could be like:
>
> #if __stdc_argument_names
> #define __aname(x) : x
> #else
> #define __aname(x)
> #endif
>
> Then strcpy would look like:
>
> char *strcpy(char *__dst __aname(dst),
> const char *__src __aname(src));
>
> If the application enables __stdc_argument_names, then it
> can no longer do this:
>
> #define __stdc_argument_names 1
> #include <string.h>
>
> // Error: non-arg-name declaration follows arg-name
> char *strcpy(char *destination, const char *source);
>
> It must ensure that there are argument names which match
> the standard-given ones:
>
> // Explicitly given: param names can be arbitrary
> char *strcpy(char *foo : dst, const char *bar : src);
>
> // Explicitly given: param names omitted
>
> char *strcpy(char * : st, const char * : src);
>
> // Implicitly derived from param names
> char *strcpy(char *dst :, const char *src);
>
> // Error, wrong names
> char *strcpy(char *src :, const char *dst);
>
Yep. That's good way to ensure nobody will use the feature. It needs to
simple to understand and use.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 20:18 -0700 |
| Message-ID | <8acf0486-4880-4df4-8e9b-aeb6c4489316n@googlegroups.com> |
| In reply to | #172792 |
On Saturday, 26 August 2023 at 02:16:48 UTC+1, Bart wrote: > > > 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'? > Yes. The problem is this. /* foo.h */ void foo(int x); #define x 100 #include "foo.h" It's unlikely that anyone would be so stupid as to #define x, but other parameter names, such as "Nelements", might clash with symbols someone would want to use. To get round this problem, some people omit parameter names from headers in the prototype. void foo(int) Of course if you do this in user code then it is a complete nightmare, because someone reading the code then. has no clue what the parameters mean.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 18:50 +0200 |
| Message-ID | <ucfusp$18cb9$3@dont-email.me> |
| In reply to | #172781 |
On 25/08/2023 20:59, 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.
>
You can have both "void foo(int a, int b);" and "void foo(int b, int
a);" declarations visible at the same time.
And if one translation unit defined "void foo(int a, int b);", while
another declared "void foo(int b, int a);" and used that with named
parameters, you would not get the correct call.
If you required the compiler to enforce that all declarations and
definitions of a function used the same parameter names, then you'd do
much better. (There is still scope for errors, but would be basically
the same as we have today for calling functions with incorrect numbers
or types of arguments.) But that would conflict with existing code that
was valid before.
So you'd need a new syntax to say that a function must have all its
declarations having consistent parameter names. You'd have to write
"void foo(int a static, int b static);" !
> 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-)}
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-08-27 19:18 +0100 |
| Message-ID | <ucg420$19crf$1@dont-email.me> |
| In reply to | #172885 |
On 27/08/2023 17:50, David Brown wrote:
[about named parameters]
>
> You can have both "void foo(int a, int b);" and "void foo(int b, int
> a);" declarations visible at the same time.
The function is 'void foo(int, int)' ... the a and b tags are supposed
to be self-documenting.
>
> And if one translation unit defined "void foo(int a, int b);", while
> another declared "void foo(int b, int a);" and used that with named
> parameters, you would not get the correct call.
You'd need something like: void foo(int a:x, int b:y);
where the parameter names are x and y (and a and b don't really matter).
All that buys you is the ability to call foo with the paramaters
out-of-order:
foo(y:100, x:5); // foo(5, 100);
And I don't think it really gains you anything.
But ... default values, maybe that would be more useful?
void foo(int a:x, int b:y:5);
void bar(int a:x, int b:y:5, int c:z:2);
So you could say:
foo(100); // foo(100, 5);
foo(y:1); // error - no default for x
bar(100, z:4); // bar(100, 5, 4);
bar(z:4, y:1, x:20); // bar(20, 1, 4);
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-27 21:19 +0200 |
| Message-ID | <ucg7jl$19tgt$1@dont-email.me> |
| In reply to | #172890 |
On 27/08/2023 20:18, Richard Harnden wrote: > On 27/08/2023 17:50, David Brown wrote: > > [about named parameters] > >> >> You can have both "void foo(int a, int b);" and "void foo(int b, int >> a);" declarations visible at the same time. > > The function is 'void foo(int, int)' ... the a and b tags are supposed > to be self-documenting. > >> >> And if one translation unit defined "void foo(int a, int b);", while >> another declared "void foo(int b, int a);" and used that with named >> parameters, you would not get the correct call. > > You'd need something like: void foo(int a:x, int b:y); > > where the parameter names are x and y (and a and b don't really matter). Why would you want two names here? You want the parameters to have a single name each (which should be, as you say, self-documenting). > > All that buys you is the ability to call foo with the paramaters > out-of-order: > foo(y:100, x:5); // foo(5, 100); > > And I don't think it really gains you anything. The real gain comes from not using them out-of-order by mistake. If "foo" is defined as "void foo(int x, int y)" and you write : foo(y : 100, x : 5) then it could either be counted as "foo(5, 100)", or it could be flagged as an error. I wouldn't mind it being an error, and having to write "foo(x : 5, y : 100)" - that would help keep the source code consistent. The key point is that you don't write "foo(100, 5)" thinking mistakenly that foo was defined as "foo(int y, int x)". So for me at least, the biggest benefit of named parameters is to catch potential errors. User convenience at the call site is secondary. > > But ... default values, maybe that would be more useful? > > void foo(int a:x, int b:y:5); > void bar(int a:x, int b:y:5, int c:z:2); > > So you could say: > foo(100); // foo(100, 5); > foo(y:1); // error - no default for x > bar(100, z:4); // bar(100, 5, 4); > bar(z:4, y:1, x:20); // bar(20, 1, 4); > > I'm not so convinced about default values. They can be handy (in languages that support them) when adding new parameters to existing functions, but are not necessarily a great idea. There is a school of thought in C++ that instead of declaring "void foo(int x, int y = 1)" you should declare two functions - "void foo(int x)" and "void foo(int x, int y)" - where "void foo(int x)" calls "foo(x, 1)". Some people feel it gives you more control - you can differentiate between leaving out the argument and coincidentally picking the default value.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-27 20:33 +0100 |
| Message-ID | <ucg8f7$1a528$1@dont-email.me> |
| In reply to | #172890 |
On 27/08/2023 19:18, Richard Harnden wrote:
> On 27/08/2023 17:50, David Brown wrote:
>
> [about named parameters]
>
>>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> The function is 'void foo(int, int)' ... the a and b tags are supposed
> to be self-documenting.
>
>>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> You'd need something like: void foo(int a:x, int b:y);
>
> where the parameter names are x and y (and a and b don't really matter).
I don't understand: what are 'a' and 'b' for then? If both lots of names
are used, then let them be alternatives:
int count_e(int FS, char* filename:string) {...}
When FS is 'F' the second parameter represents a filename; when 'S', it
is a string containing the data. Those two uses can be given more apt names:
count_e('F', filename:"input.txt");
count_e('S', string:"This is some literal text");
> All that buys you is the ability to call foo with the paramaters
> out-of-order:
> foo(y:100, x:5); // foo(5, 100);
>
> And I don't think it really gains you anything.
It helps to document the meaning of each argument in calls like 'f(1, 0,
1, 1)'.
It avoids having to remember the order of the arguments (but you need to
remember the parameter names).
It allows the parameter ordering to be changed without affecting
call-sites (but only if positional arguments are used).
> But ... default values, maybe that would be more useful?
With those it will be considerably more useful. They are useful also on
their own. For example, start with this:
int F(int a, int b);
Write 1000s of lines of code with instances of F(x,y). Then you decide
that sometimes, an extra parameter is needed (or this could even be
temporary to help debugging). Make that extra parameter optional:
int F(int a, int b, int newflag=0);
'=0' is my syntax for a default value. Like this, existing code will
compile unchanged, and will pass newflag as 0. Only new code that needs
to use that flag need to supply that new argument.
> void foo(int a:x, int b:y:5);
> void bar(int a:x, int b:y:5, int c:z:2);
A rather strange syntax though.
> So you could say:
> foo(100); // foo(100, 5);
> foo(y:1); // error - no default for x
> bar(100, z:4); // bar(100, 5, 4);
> bar(z:4, y:1, x:20); // bar(20, 1, 4);
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-27 14:14 -0700 |
| Message-ID | <87il90chmj.fsf@nosuchdomain.example.com> |
| In reply to | #172890 |
Richard Harnden <richard.nospam@gmail.com> writes:
> On 27/08/2023 17:50, David Brown wrote:
> [about named parameters]
>
>> You can have both "void foo(int a, int b);" and "void foo(int b, int
>> a);" declarations visible at the same time.
>
> The function is 'void foo(int, int)' ... the a and b tags are supposed
> to be self-documenting.
>
>> And if one translation unit defined "void foo(int a, int b);", while
>> another declared "void foo(int b, int a);" and used that with named
>> parameters, you would not get the correct call.
>
> You'd need something like: void foo(int a:x, int b:y);
>
> where the parameter names are x and y (and a and b don't really matter).
Why? What's the point of having two names for the same parameter?
> All that buys you is the ability to call foo with the paramaters
> out-of-order:
> foo(y:100, x:5); // foo(5, 100);
>
> And I don't think it really gains you anything.
The main point is letting calls be more self-documenting. (Names like
a, b, x, and y don't illustrate that very well.)
I think this was triggered by bool parameters, where you could have a
call like:
func(blah, true, true, false);
A reader can't tell what "true, true, false" means without being *very*
familiar with func()'s signature. With named arguments, you could write
that as:
func(blah, text_mode: true, highlight: true, color: false);
[...]
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-27 13:56 -0700 |
| Message-ID | <87pm38cihm.fsf@nosuchdomain.example.com> |
| In reply to | #172885 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/08/2023 20:59, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> 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.
>
> You can have both "void foo(int a, int b);" and "void foo(int b, int
> a);" declarations visible at the same time.
So have a rule that the most recent declaration applies. If you write
two declarations with deliberately misleading parameter names, you get
what you deserve.
> And if one translation unit defined "void foo(int a, int b);", while
> another declared "void foo(int b, int a);" and used that with named
> parameters, you would not get the correct call.
True. So don't do that.
> If you required the compiler to enforce that all declarations and
> definitions of a function used the same parameter names, then you'd do
> much better. (There is still scope for errors, but would be basically
> the same as we have today for calling functions with incorrect numbers
> or types of arguments.) But that would conflict with existing code
> that was valid before.
I might have advocated requiring parameter names to be consistent
(basically making parameter names as well as their types, part of the
function signature), but it's too late for that.
> So you'd need a new syntax to say that a function must have all its
> declarations having consistent parameter names. You'd have to write
> "void foo(int a static, int b static);" !
No, I don't think you do.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 11:00 +0200 |
| Message-ID | <uchno8$1kjtk$1@dont-email.me> |
| In reply to | #172900 |
On 27/08/2023 22:56, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 25/08/2023 20:59, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: > [...] >>>> 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. >> >> You can have both "void foo(int a, int b);" and "void foo(int b, int >> a);" declarations visible at the same time. > > So have a rule that the most recent declaration applies. If you write > two declarations with deliberately misleading parameter names, you get > what you deserve. > >> And if one translation unit defined "void foo(int a, int b);", while >> another declared "void foo(int b, int a);" and used that with named >> parameters, you would not get the correct call. > > True. So don't do that. That would boil down to undiagnosable undefined behaviour - and I'd rather avoid that. If there was a way to enforce checking here, it would be significantly better (IMHO). To me, avoiding mistakes is the most important justification for named parameters. Since we can't do anything about currently legal declarations and definitions with different (or missing) parameter names, I think we want a new or modified syntax for the declaration and definition of functions that can use named parameters. I think that with this new type of declaration, the rules should be that a function should either be "static" and have at most one forward declaration, or non-static and have exactly one "extern" declaration in scope before it, and that the parameter names and styles (such as pointers or array parameter) match exactly. This would not force programmers to have declarations in a single header that is included by both the defining TU and TU's that use the function, but it would strongly encourage it. And it would make it a lot harder to get wrong. Since this would conflict with existing styles used in some code, I think we'd need a new syntax (or a new function attribute or qualifier). It's possible that compilers could have a flag to apply such checks by default (gcc has "-Wmissing-declarations -Wredundant-declarations", but no check on parameter names AFAIK), but that would be an implementation option, useful to some people and not others. > >> If you required the compiler to enforce that all declarations and >> definitions of a function used the same parameter names, then you'd do >> much better. (There is still scope for errors, but would be basically >> the same as we have today for calling functions with incorrect numbers >> or types of arguments.) But that would conflict with existing code >> that was valid before. > > I might have advocated requiring parameter names to be consistent > (basically making parameter names as well as their types, part of the > function signature), but it's too late for that. > >> So you'd need a new syntax to say that a function must have all its >> declarations having consistent parameter names. You'd have to write >> "void foo(int a static, int b static);" ! > > No, I don't think you do. > > [...] >
[toc] | [prev] | [next] | [standalone]
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web