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 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | candycane@f172.n1.z21.fsxnet (candycane) |
|---|---|
| Date | 2023-08-27 02:42 +1300 |
| Message-ID | <2646917749@f172.n1.z21.fsxnet> |
| In reply to | #172858 |
KK> Quick, which one is the destination? KK> KK> strcpy(goat: userid, fish: uid); I'm going to guess goat? ----------------------------------- user is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-27 11:23 +0100 |
| Message-ID | <ucf86t$14b70$1@dont-email.me> |
| In reply to | #172858 |
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
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-27 22:45 +0000 |
| Message-ID | <20230827151627.814@kylheku.com> |
| In reply to | #172874 |
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.
If required, positional parameters are going to be callable using named
arguments, the named arguments must be a mandatory part of the function
definition.
A redeclaration with different names must be diagnosable error.
In the case of C structures, names count for compatibility.
Two structure types that are structurally identical, occurring in
different translation units must have the same member names, in the
same order, in order to be considered compatible.
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.
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.
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);
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-27 19:06 -0400 |
| Message-ID | <kGQGM.834420$TPw2.617635@fx17.iad> |
| In reply to | #172902 |
On 8/27/23 6:45 PM, 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. > > If required, positional parameters are going to be callable using named > arguments, the named arguments must be a mandatory part of the function > definition. > > A redeclaration with different names must be diagnosable error. No, that would be a very backwards breaking change. changing names might make the function not callable with named parameters, but only "old style" with just values listed. > > In the case of C structures, names count for compatibility. > > Two structure types that are structurally identical, occurring in > different translation units must have the same member names, in the > same order, in order to be considered compatible. Why? what difference can that make to the actual code generted? In C, the structures don't even need the same type name to be compatible. Again, that becomes a breaking change, and one that actually takes a lot of work to actually detect the error to give a diagnostic. > > 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); That is one option to make named parameter calls optional. If you do that, THEN you can make not match an error. > > 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. > > 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. > > 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); >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-08-28 02:18 -0400 |
| Message-ID | <uche7g$1j3q5$1@dont-email.me> |
| In reply to | #172903 |
On 8/27/23 19:06, Richard Damon wrote: > On 8/27/23 6:45 PM, 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: ... >> In the case of C structures, names count for compatibility. >> >> Two structure types that are structurally identical, occurring in >> different translation units must have the same member names, in the >> same order, in order to be considered compatible. > > Why? what difference can that make to the actual code generted? Unfortunately, the C99 Rationale doesn't go into any detail about the reasons for that requirement. I think that requirement is motivated by the belief that such code is inherently confusing, and should therefore not be required to work as you might expect it to. > In C, the structures don't even need the same type name to be compatible. That was changed in C99. If either structure type is given a tag, the other one must be given the same tag. > Again, that becomes a breaking change, and one that actually takes a lot > of work to actually detect the error to give a diagnostic. He's not describing a proposed change - that's what the current requirements are: "Two types have compatible type if their types are the same. ... Moreover, two structure, union, or enumerated types declared in separate translation units are compatible if their tags and members satisfy the following requirements: If one is declared with a tag, the other shall be declared with the same tag." Note the same tag requirement. "If both are completed anywhere within their respective translation units, then the following additional requirements apply: there shall be a one-to-one correspondence between their members such that each pair of corresponding members are declared with compatible types; if one member of the pair is declared with an alignment specifier, the other is declared with an equivalent alignment specifier; and if one member of the pair is declared with a name, the other is declared with the same name." Note the same name requirement. "For two structures, corresponding members shall be declared in the same order. For two structures or unions, corresponding bit-fields shall have the same widths. ..." (6.2.7p1) Note also that this applies only for struct declarations in separate translation units. Otherwise, struct types are covered only by the "same type" part of the rule. Struct types declared with member lists are considered to be new types in that translation unit. (6.7.2.1p10). Doing so twice with the same tag in the same scope is a constraint violation (6.7.2.3p1,5). Struct types declared in different scopes or with different tags or no tag are considered distinct types (6.7.2.3p6). As a result, two struct types defined in the same translation unit are never compatible, regardless of how they are defined.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-27 16:21 -0700 |
| Message-ID | <87edjocbqj.fsf@nosuchdomain.example.com> |
| In reply to | #172902 |
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).
I don't think it's practical to make them mandatory for function
declarations. That would break tons of existing code.
My suggestion: If a function declaration doesn't use parameter names,
you can't call it with named arguments. (You can always write your own
declaration for an existing function.)
> A redeclaration with different names must be diagnosable error.
That would break existing code. My suggestion: the names in the *last*
visible declaration before a call can be used in a call. (Strongly
suggested best practice would be to use consistent names.)
[...]
> 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);
Why not just declare
char *strcpy(const char *dest, char *src);
and use those names in calls, with a few simple rules for when there's
more than one visible declaration?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-28 00:00 +0000 |
| Message-ID | <20230827165554.489@kylheku.com> |
| In reply to | #172904 |
On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > [...] >> 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); > > Why not just declare > char *strcpy(const char *dest, char *src); > and use those names in calls, with a few simple rules for when there's > more than one visible declaration? In order to prevent #include <string.h> // someone adds this somewhere, and arguments get flipped // downscope of it. char *strcpy(char *src, const char *dest); If we are going to have argument names that have a semantic purpose, I'd like those to be part of the declaration. If the standard declaration has been included via the proper header, the program should be defended against an incorrect declaration coming from somewhere else. -- 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-27 19:36 -0700 |
| Message-ID | <87a5ubdhb2.fsf@nosuchdomain.example.com> |
| In reply to | #172908 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> [...]
>>> 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);
>>
>> Why not just declare
>> char *strcpy(const char *dest, char *src);
>> and use those names in calls, with a few simple rules for when there's
>> more than one visible declaration?
>
> In order to prevent
>
> #include <string.h>
>
> // someone adds this somewhere, and arguments get flipped
> // downscope of it.
> char *strcpy(char *src, const char *dest);
So don't do that.
And don't this either:
#define strcpy(s1, s2) ((strcpy)((s2), (s1)))
> If we are going to have argument names that have a semantic
> purpose, I'd like those to be part of the declaration.
>
> If the standard declaration has been included via the proper header, the
> program should be defended against an incorrect declaration coming from
> somewhere else.
Adding named arguments should be fairly simple (though library functions
additionally defined as macros present some complications). Parameter
names can already be given in a function declaration. I just want to be
able to use them.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-28 03:00 +0000 |
| Message-ID | <20230827194919.67@kylheku.com> |
| In reply to | #172920 |
On 2023-08-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >> On 2023-08-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> Why not just declare >>> char *strcpy(const char *dest, char *src); >>> and use those names in calls, with a few simple rules for when there's >>> more than one visible declaration? >> >> In order to prevent >> >> #include <string.h> >> >> // someone adds this somewhere, and arguments get flipped >> // downscope of it. >> char *strcpy(char *src, const char *dest); > > So don't do that. We could dispense with all sorts of static checking if we "don't do that". If you don't pass incorrect types to strcpy, you can just declare it as: char *strcpy(); The named arguments idea is purely a static gadget in which it's possible to do sanity checks for consistency, which is a good argument that it should be done. There are many situations we can't easily check for at translation time. > Adding named arguments should be fairly simple (though library functions > additionally defined as macros present some complications). Parameter > names can already be given in a function declaration. I just want to be > able to use them. You have to think of the C implementations that won't fix their library declarations to the specified names where you'd like your code to be able to run (if you have the compiler for it). If this were rolled out, you would face situations where the names coming from the header are not the right ones, or are completely absent. Programs would have to supply their own redeclarations of library functions to make up for this. In such a program, it would be a good idea to have those declarations active even in an implementation that provides the standard-defined names, so that those redeclarations get checked. For that reason, it would be useful for a declaration to be able to somehow assert "I provide argument names for use in calls (check me against other such declarations)", versus "I'm a regular old declaration that doesn't assert argument names (I don't speak to the validity of declarations which do that).". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 06:58 -0700 |
| Message-ID | <86edjnxo81.fsf@linuxsc.com> |
| In reply to | #172904 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
[named function arguments]
>> 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);
>
> Why not just declare
> char *strcpy(const char *dest, char *src);
> and use those names in calls, with a few simple rules for when there's
> more than one visible declaration?
Amusing that both of thesse declarations get the qualifiers
wrong.
I favor a different approach to this problem:
static inline char *
copy_to_from( char *to, const char *from ){
return strcpy( to, from );
}
with no language changes needed. And people are still free to
use the more concise form if they so desire.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-28 15:22 -0700 |
| Message-ID | <87ledubyeh.fsf@nosuchdomain.example.com> |
| In reply to | #172999 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> [named function arguments]
>
>>> 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);
>>
>> Why not just declare
>> char *strcpy(const char *dest, char *src);
>> and use those names in calls, with a few simple rules for when there's
>> more than one visible declaration?
>
> Amusing that both of thesse declarations get the qualifiers
> wrong.
I am suitably amused.
char *strcpy(char *restrict dst, const char *restrict src);
(And we could discuss about how far "destination" and "source" should be
abbreviated.)
> I favor a different approach to this problem:
>
> static inline char *
> copy_to_from( char *to, const char *from ){
> return strcpy( to, from );
> }
>
> with no language changes needed. And people are still free to
> use the more concise form if they so desire.
But if we change the names used in the standard for strcpy's parameters,
there's no need for a wrapper function (with, in your approach, a name
that doesn't suggest that it operates on strings).
Your wrapper would be useful only if the language added named arguments,
yes? I'd expect that an edition of the standard that added named
arguments would also rework the argument names in the standard library.
Even without named arguments, I don't think "s1" and "s2" the best
choices for parameters of strcpy(). They're consistent with strcmp(),
but they don't need to be. It makes no semantic difference, but IMHO
the description would be a little clearer with more meaningful names.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 16:49 -0700 |
| Message-ID | <861qfmwwvy.fsf@linuxsc.com> |
| In reply to | #173096 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [named function arguments]
>>
>>>> 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);
>>>
>>> Why not just declare
>>> char *strcpy(const char *dest, char *src);
>>> and use those names in calls, with a few simple rules for when there's
>>> more than one visible declaration?
>>
>> I favor a different approach to this problem:
>>
>> static inline char *
>> copy_to_from( char *to, const char *from ){
>> return strcpy( to, from );
>> }
>>
>> with no language changes needed. And people are still free to
>> use the more concise form if they so desire.
>
> But if we change the names used in the standard for strcpy's parameters,
Part of the point of my approach is that it doesn't need any
changes to the C standard.
> there's no need for a wrapper function (with, in your approach, a name
> that doesn't suggest that it operates on strings).
That's incidental. It could be copy_string_to_from();
> Your wrapper would be useful only if the language added named arguments,
> yes?
Not at all, that's the point. The function name indicates where
the destination (to) and source (from) arguments go. There is
no reason a declaration has to use those names, or any names at
all, for the function parameters. All the information needed
is present in the name of the function.
> I'd expect that an edition of the standard that added named
> arguments would also rework the argument names in the standard library.
Part of the advantage of the approach I favor is it doesn't
need to wait for a new edition of the C standard. I think
there are lots of cases where simply adopting a coding style
obviates any need for new language features.
> Even without named arguments, I don't think "s1" and "s2" the best
> choices for parameters of strcpy(). They're consistent with strcmp(),
> but they don't need to be. It makes no semantic difference, but IMHO
> the description would be a little clearer with more meaningful names.
In the context of the C standard, and especially for strcpy(), I
don't see anything wrong with s1 and s2. Moreover using s1 and s2
means there won't be any bike-shedding arguments about what the
names should be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-28 17:11 -0700 |
| Message-ID | <87h6oibtc1.fsf@nosuchdomain.example.com> |
| In reply to | #173127 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> [named function arguments]
>>>
>>>>> 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);
>>>>
>>>> Why not just declare
>>>> char *strcpy(const char *dest, char *src);
>>>> and use those names in calls, with a few simple rules for when there's
>>>> more than one visible declaration?
>>>
>>> I favor a different approach to this problem:
>>>
>>> static inline char *
>>> copy_to_from( char *to, const char *from ){
>>> return strcpy( to, from );
>>> }
>>>
>>> with no language changes needed. And people are still free to
>>> use the more concise form if they so desire.
>>
>> But if we change the names used in the standard for strcpy's parameters,
>
> Part of the point of my approach is that it doesn't need any
> changes to the C standard.
Ah, I misunderstood your point.
This subthread has been about how named arguments should be implemented.
You're saying that if named arguments *aren't* added as a new feature,
providing a wrapper function whose name indicates meanings of the
parameters
I would never bother to write or use the wrapper function you suggest.
I deal with the potential ambiguity in the parameters of strcpy() by
remembering that the destination is first, analagous to an assignment.
I speculate that you do the same.
I'm sympathetic to arguments that named arguments shouldn't be added to
C because it would be too complex. I personally think it would be a
worthwhile change, but I can certainly live without it. But if it were
added, it could be very useful in writing more legible code. strcpy()
is just one example. More compelling examples are functions that take
one or more bool arguments. I've used languages (Ada, Python) with
named arguments, and found the feature very useful.
[...]
--
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-29 16:06 +0200 |
| Message-ID | <ucku1d$29kkf$1@dont-email.me> |
| In reply to | #173128 |
On 29/08/2023 02:11, Keith Thompson wrote:
>
> I'm sympathetic to arguments that named arguments shouldn't be added to
> C because it would be too complex. I personally think it would be a
> worthwhile change, but I can certainly live without it. But if it were
> added, it could be very useful in writing more legible code. strcpy()
> is just one example. More compelling examples are functions that take
> one or more bool arguments. I've used languages (Ada, Python) with
> named arguments, and found the feature very useful.
>
You can make named parameters with strong typing in C - it's just a bit
more effort than in some languages (like Ada, or C++). You have to wrap
things in a struct (or a union, if you prefer).
A function with several bool arguments is likely to have a high risk of
mixing argument order, or mixing what "true" and "false" mean:
void foo(bool upDown, bool leftRight, bool forwardBack);
void test(bool a, bool b, bool c) {
foo(a, b, c);
}
void test1(void) {
foo(true, false, true);
}
It's easy to misread, or miswrite, calls to "foo". But it is hard to
get it wrong with a strongly-typed boolean :
#define StrongBool(TypeName, FalseName, TrueName) \
typedef struct { bool v; } TypeName; \
static const TypeName FalseName = { false }; \
static const TypeName TrueName = { true };
StrongBool(upDown_t, down, up)
StrongBool(leftRight_t, right, left)
StrongBool(forwardBack_t, back, forward)
void bar(upDown_t ud, leftRight_t lr, forwardBack_t fb);
void test2(upDown_t ud, leftRight_t lr, forwardBack_t fb) {
bar(ud, lr, fb);
}
void test3(void) {
bar(up, right, forward);
}
void test4(bool a, bool b, bool c) {
bar((upDown_t) { a }, (leftRight_t) { b }, (forwardBack_t) { c });
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-29 08:27 -0700 |
| Message-ID | <86jztdvpgp.fsf@linuxsc.com> |
| In reply to | #173128 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>> [named function arguments]
>>>>
>>>>>> 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);
>>>>>
>>>>> Why not just declare
>>>>> char *strcpy(const char *dest, char *src);
>>>>> and use those names in calls, with a few simple rules for when
>>>>> there's more than one visible declaration?
>>>>
>>>> I favor a different approach to this problem:
>>>>
>>>> static inline char *
>>>> copy_to_from( char *to, const char *from ){
>>>> return strcpy( to, from );
>>>> }
>>>>
>>>> with no language changes needed. And people are still free to
>>>> use the more concise form if they so desire.
>>>
>>> But if we change the names used in the standard for strcpy's
>>> parameters,
>>
>> Part of the point of my approach is that it doesn't need any
>> changes to the C standard.
>
> Ah, I misunderstood your point.
>
> This subthread has been about how named arguments should be
> implemented. You're saying that if named arguments *aren't* added
> as a new feature, providing a wrapper function whose name
> indicates meanings of the parameters
I didn't mean that the two techniques are mutually exclusive,
just to suggest an alternative. The function name approach
does have the advantage that it can be used in C as it is now,
and also in other languages that don't have named function
parameters.
> I would never bother to write or use the wrapper function you
> suggest.
The example function was shown assuming the context of the
discussion. The same idea can be used in writing new functions
that are not related to inner functions such as strcpy().
> I deal with the potential ambiguity in the parameters of strcpy()
> by remembering that the destination is first, analagous to an
> assignment.
As often as not I just read the man page.
> I speculate that you do the same.
It depends. For a function that isn't used much, probably I
would just use it as is. But if it's something that is going to
get used a lot, I tend to favor wrappers. I'm a big fan of
abstraction, both function abstraction and other kinds.
> I'm sympathetic to arguments that named arguments shouldn't be
> added to C because it would be too complex. I personally think it
> would be a worthwhile change, but I can certainly live without it.
> But if it were added, it could be very useful in writing more
> legible code. strcpy() is just one example. More compelling
> examples are functions that take one or more bool arguments. I've
> used languages (Ada, Python) with named arguments, and found the
> feature very useful.
IMO named arguments don't add much to conventional programming
languages (of which C certainly counts as one). But even if I
thought named function arguments were a net win overall, which
isn't a sure thing, they are quite a ways down the priority list,
since there are alternatives that offer most of the benefits
without needing any new language features.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-29 01:36 +0100 |
| Message-ID | <ucjei2$1tv7s$1@dont-email.me> |
| In reply to | #173127 |
On 29/08/2023 00:49, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>> [named function arguments]
>>>
>>>>> 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);
>>>>
>>>> Why not just declare
>>>> char *strcpy(const char *dest, char *src);
>>>> and use those names in calls, with a few simple rules for when there's
>>>> more than one visible declaration?
>>>
>>> I favor a different approach to this problem:
>>>
>>> static inline char *
>>> copy_to_from( char *to, const char *from ){
>>> return strcpy( to, from );
>>> }
>>>
>>> with no language changes needed. And people are still free to
>>> use the more concise form if they so desire.
>>
>> But if we change the names used in the standard for strcpy's parameters,
>
> Part of the point of my approach is that it doesn't need any
> changes to the C standard.
>
>> there's no need for a wrapper function (with, in your approach, a name
>> that doesn't suggest that it operates on strings).
>
> That's incidental. It could be copy_string_to_from();
>
>> Your wrapper would be useful only if the language added named arguments,
>> yes?
>
> Not at all, that's the point. The function name indicates where
> the destination (to) and source (from) arguments go. There is
> no reason a declaration has to use those names, or any names at
> all, for the function parameters. All the information needed
> is present in the name of the function.
So you've just moving the parameter names to the name of the function.
You're now back to remembering the order, by having to remember the name
of the function.
The parts of the name for the N arguments, and the N arguments
themselves are now disjoint.
You don't have the choice of using a short function name and using
non-keyword parameters. You might want to do that if you can remember
which way around the strcpy arguments go.
You can't apply the scheme to existing functions that are exported using
a certain name from their libraries; you'd have to write wrapper functions.
And it's not really scalable to many arguments. It also would not allow
for optional arguments, or allowing for your own choice of argument order.
>> I'd expect that an edition of the standard that added named
>> arguments would also rework the argument names in the standard library.
>
> Part of the advantage of the approach I favor is it doesn't
> need to wait for a new edition of the C standard.
But then things will never change.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 01:22 +0000 |
| Message-ID | <20230828182115.305@kylheku.com> |
| In reply to | #173130 |
On 2023-08-29, Bart <bc@freeuk.com> wrote: > On 29/08/2023 00:49, Tim Rentsch wrote: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> Part of the advantage of the approach I favor is it doesn't >> need to wait for a new edition of the C standard. > > But then things will never change. But when they do change, you will try things on three random compilers, one of which speaks its own native dialect by default, one which has that new standard and a third which doesn't and then proclaim that the language is in chaos; will the real C language stand up? -- 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 10:40 +0100 |
| Message-ID | <uckeel$26q6m$1@dont-email.me> |
| In reply to | #173133 |
On 29/08/2023 02:22, Kaz Kylheku wrote:
> On 2023-08-29, Bart <bc@freeuk.com> wrote:
>> On 29/08/2023 00:49, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Part of the advantage of the approach I favor is it doesn't
>>> need to wait for a new edition of the C standard.
>>
>> But then things will never change.
>
> But when they do change, you will try things on three random compilers,
> one of which speaks its own native dialect by default, one which has
> that new standard and a third which doesn't and then proclaim that the
> language is in chaos; will the real C language stand up?
>
Here's an example of people being afraid of change:
Most C compilers accept '$' within identifiers. I find that useful as a
more visually distinct 'special' character than '_' which already has
lots of official meanings.
The exceptions had been lcc-win32 (but years ago), where '$' could only
be used at certain places in a name.
And in Tiny C, until version 0.9.27, when it only worked if you gave
this ridiculous option:
-fdollars-in-identifiers
Tiny C isn't the most conforming compiler around; what are they actually
afraid of by just allowing it anyway?
There is always something. Wasn't that half the point of 'make' and
'configure'?
Now, maybe C doesn't officially sanction the use of '$', in which case
why do most compilers accept it?
gcc 13.2.0 will reject it using '-std=c89 -Wpedantic', and accept it if
anything else is used, but n1570.pdf (C11 draft) doesn't specifically
mention it.
So is '$' allowed or not? Can I safely use it with any compiler apart
from Tiny C? I don't know.
(I use '$' extensively in machine-generated code.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-29 02:53 -0700 |
| Message-ID | <6618fc2b-2ff1-4f2f-897e-6ec48ecc2b16n@googlegroups.com> |
| In reply to | #173180 |
On Tuesday, 29 August 2023 at 10:40:53 UTC+1, Bart wrote: > On 29/08/2023 02:22, Kaz Kylheku wrote: > > On 2023-08-29, Bart <b...@freeuk.com> wrote: > >> On 29/08/2023 00:49, Tim Rentsch wrote: > >>> Keith Thompson <Keith.S.T...@gmail.com> writes: > >>> Part of the advantage of the approach I favor is it doesn't > >>> need to wait for a new edition of the C standard. > >> > >> But then things will never change. > > > > But when they do change, you will try things on three random compilers, > > one of which speaks its own native dialect by default, one which has > > that new standard and a third which doesn't and then proclaim that the > > language is in chaos; will the real C language stand up? > > > Here's an example of people being afraid of change: > > Most C compilers accept '$' within identifiers. I find that useful as a > more visually distinct 'special' character than '_' which already has > lots of official meanings. > > The exceptions had been lcc-win32 (but years ago), where '$' could only > be used at certain places in a name. > > Now, maybe C doesn't officially sanction the use of '$', in which case > why do most compilers accept it? > Off-label use. If dollar signs are not allowed in identifiers in valid C programs, but still accepted by the compiler, then the dollar sign becomes a symbol which can be used, but not in C programs which are passed to someone else. > > (I use '$' extensively in machine-generated code.) > Exactly. Prefixing everything with a dollar sign is a good way of making your machine-generated identifier match an identifier entered by the user, whilst avoiding any possibility of a name clash.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-29 03:00 -0700 |
| Message-ID | <87a5uab226.fsf@nosuchdomain.example.com> |
| In reply to | #173180 |
Bart <bc@freeuk.com> writes:
[...]
> Now, maybe C doesn't officially sanction the use of '$', in which case
> why do most compilers accept it?
>
> gcc 13.2.0 will reject it using '-std=c89 -Wpedantic', and accept it
> if anything else is used, but n1570.pdf (C11 draft) doesn't
> specifically mention it.
In C89/C90, the syntax for an identifier allowed only the 52 uppercase
and lowercase Latin letters, underscores, and decimal digits.
C99 added universal-character-names and "other implementation-defined
characters".
So a conforming C99 or later compiler may or may not accept '$' in
identifiers. A conforming C90 compiler cannot.
(You saw that the gcc's behavior changed between "-std=c89 -Wpedantic"
and "-std=c99 -Wpedantic". It never occurred to you to check the C99
standard or the N1256 draft to see if the syntax of an identifier had
changed, did it?)
> So is '$' allowed or not? Can I safely use it with any compiler apart
> from Tiny C? I don't know.
See above.
> (I use '$' extensively in machine-generated code.)
--
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]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web