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 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-29 16:18 +0200 |
| Message-ID | <uckumo$29oe0$1@dont-email.me> |
| In reply to | #173180 |
On 29/08/2023 11:40, Bart wrote: > 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? Being able to accept $ in identifiers is a convenient extension. > > 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. It's not in the standard, so you should assume you can't use it safely with compilers that don't document that they support it as an extension. If you are only using compilers that you know accept it (such as gcc with "-fdollars-in-identifiers", even in pedantic modes), then use it if you want. You have two risks, however. One is that some compilers don't accept it. Sometimes that's because they are very strict, sometimes because they haven't bothered implementing it as an extension, and sometimes it is because they can't - dollars may be reserved for other purposes. Some assemblers use $ for special purposes that would conflict with having them dollars in identifiers - a compiler that targets a processor with such an assembly would be unable to support the extension (or at least, not easily). (Yes, such assemblers and compilers are real things.) And perhaps some compilers already use $ for some other extension. The other risk is that future C standards may use $ for some other purpose. I think that's fairly unlikely, but it /could/ happen. > > (I use '$' extensively in machine-generated code.) > You only target certain specific known compilers, so that's fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-29 13:06 -0700 |
| Message-ID | <875y4xboly.fsf@nosuchdomain.example.com> |
| In reply to | #173195 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Being able to accept $ in identifiers is a convenient extension.
Quibble: $ in identifiers is not an extension as specified in section 4
of the standard. Starting in C99, the set of characters accepted in
identifiers is implementation-defined. (I'm not sure what difference
that makes.)
--
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-29 22:14 -0700 |
| Message-ID | <864jkhun64.fsf@linuxsc.com> |
| In reply to | #173215 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > David Brown <david.brown@hesbynett.no> writes: > [...] > >> Being able to accept $ in identifiers is a convenient extension. > > Quibble: $ in identifiers is not an extension as specified in section 4 > of the standard. Starting in C99, the set of characters accepted in > identifiers is implementation-defined. (I'm not sure what difference > that makes.) In Annex J, J.5.2 gives adding $ to the set of characters that can appear in identifiers as an example of a common extension.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-30 01:32 -0700 |
| Message-ID | <87sf819bi3.fsf@nosuchdomain.example.com> |
| In reply to | #173248 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>
>>> Being able to accept $ in identifiers is a convenient extension.
>>
>> Quibble: $ in identifiers is not an extension as specified in section 4
>> of the standard. Starting in C99, the set of characters accepted in
>> identifiers is implementation-defined. (I'm not sure what difference
>> that makes.)
>
> In Annex J, J.5.2 gives adding $ to the set of characters that
> can appear in identifiers as an example of a common extension.
C90 says the same thing in its Annex G. Looks like they didn't update
it when C99 updated the syntax for an identifier. (Though I suppose an
implementation could accept $ in identifiers either as an extension or
as an "other implementation-defined character".)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-30 21:09 -0700 |
| Message-ID | <86il8vua3h.fsf@linuxsc.com> |
| In reply to | #173251 |
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: >> >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>> >>>> Being able to accept $ in identifiers is a convenient extension. >>> >>> Quibble: $ in identifiers is not an extension as specified in section 4 >>> of the standard. Starting in C99, the set of characters accepted in >>> identifiers is implementation-defined. (I'm not sure what difference >>> that makes.) >> >> In Annex J, J.5.2 gives adding $ to the set of characters that >> can appear in identifiers as an example of a common extension. > > C90 says the same thing in its Annex G. Looks like they didn't update > it when C99 updated the syntax for an identifier. Certainly it's true that this passage wasn't changed. That doesn't mean it wasn't reviewed; it may have been deliberately left in. There have been lots of opportunities to change it, and it hasn't been changed yet. > (Though I suppose an > implementation could accept $ in identifiers either as an extension or > as an "other implementation-defined character".) Yes, no question about it. Furthermore implementors might make one choice or the other, depending on how they think of the character(s) in question. For myself, I expect I would naturally think of adding characters from another alphabet in the implementation-defined sense, but think of adding $ in the extension sense. Having both options has some value, in terms of conveying mindset.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-30 12:44 +0200 |
| Message-ID | <ucn6hi$2n2kb$1@dont-email.me> |
| In reply to | #173215 |
On 29/08/2023 22:06, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Being able to accept $ in identifiers is a convenient extension. > > Quibble: $ in identifiers is not an extension as specified in section 4 > of the standard. Starting in C99, the set of characters accepted in > identifiers is implementation-defined. (I'm not sure what difference > that makes.) > Until it was mentioned in this thread, I didn't realise that dollars (or other characters) in identifiers were implementation-defined options, rather than requiring it to be an extension. (The distinction I would make here is that an "extension" is for something that the standard does not cover at all but is documented by the compiler - something that would be a syntax error, a constraint violation, or undefined behaviour if the compiler did not support it.) As you say, I don't think there is a significant difference in practice, but I like to understand these things as accurately as I can, and I appreciate the bug-fix when I get them wrong. On a related note, I am looking at 6.4.2.1p3 (in C11) on "universal character names", and it appears to say that the characters must come from the list in D.1 (but not D.2, for the initial character), but also that implementations can allow other characters. This would make the D.1 list the minimal set allowed, but implementations could allow any (or almost any) other Unicode characters. Do you think that is right, or am I missing something?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-08-30 12:32 -0400 |
| Message-ID | <ucnqv5$2q4fv$1@dont-email.me> |
| In reply to | #173267 |
On 8/30/23 06:44, David Brown wrote: ... > Until it was mentioned in this thread, I didn't realise that dollars (or > other characters) in identifiers were implementation-defined options, > rather than requiring it to be an extension. (The distinction I would > make here is that an "extension" is for something that the standard does > not cover at all but is documented by the compiler - something that > would be a syntax error, a constraint violation, or undefined behaviour > if the compiler did not support it.) The defining characteristic of a C extension is "A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program." Since it is implementation-defined whether those characters can be used, a strictly conforming program cannot use them, I would have preferred that they call these "conforming" extensions - that is, extensions that do not render the implementation non-conforming. I think it would be appropriate to talk about extensions that render an implementation non-conforming, calling them "non-conforming extensions".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-30 11:44 -0700 |
| Message-ID | <87jztc9xp0.fsf@nosuchdomain.example.com> |
| In reply to | #173309 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 8/30/23 06:44, David Brown wrote:
> ...
>> Until it was mentioned in this thread, I didn't realise that dollars (or
>> other characters) in identifiers were implementation-defined options,
>> rather than requiring it to be an extension. (The distinction I would
>> make here is that an "extension" is for something that the standard does
>> not cover at all but is documented by the compiler - something that
>> would be a syntax error, a constraint violation, or undefined behaviour
>> if the compiler did not support it.)
>
> The defining characteristic of a C extension is "A conforming
> implementation may have extensions (including additional library
> functions), provided they do not alter the behavior of any strictly
> conforming program." Since it is implementation-defined whether those
> characters can be used, a strictly conforming program cannot use them,
>
> I would have preferred that they call these "conforming" extensions -
> that is, extensions that do not render the implementation
> non-conforming. I think it would be appropriate to talk about extensions
> that render an implementation non-conforming, calling them
> "non-conforming extensions".
That might be useful, but I suggest that anything that renders an
implementation non-conforming is simply outside the scope of the
standard.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-09-09 01:15 -0400 |
| Message-ID | <udgv2d$3ufb5$2@dont-email.me> |
| In reply to | #173338 |
On 8/30/23 14:44, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> The defining characteristic of a C extension is "A conforming >> implementation may have extensions (including additional library >> functions), provided they do not alter the behavior of any strictly >> conforming program." Since it is implementation-defined whether those >> characters can be used, a strictly conforming program cannot use them, >> >> I would have preferred that they call these "conforming" extensions - >> that is, extensions that do not render the implementation >> non-conforming. I think it would be appropriate to talk about extensions >> that render an implementation non-conforming, calling them >> "non-conforming extensions". > > That might be useful, but I suggest that anything that renders an > implementation non-conforming is simply outside the scope of the > standard. Sorry for the late reply. I've been in quarantine due to Covid-19, and my computer was not in quarantine with me. A very large fraction of all of the things I would be inclined to call "extensions" to C do in fact render the implementation that supports them non-conforming. That doesn't have to be the case - if it gives a meaning to keywords that aren't standard C keywords, all it would have to do is give those keywords names that are reserved to the implementation. Any use of those keywords could trigger a single diagnostic message "Congratulations for using our [description] extension". But not all implementors bother doing that. I therefore find it annoying that C's definition of extensions cannot be used to refer to such things.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-31 04:47 -0700 |
| Message-ID | <861qfjtov4.fsf@linuxsc.com> |
| In reply to | #173309 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: [...] > The defining characteristic of a C extension is "A conforming > implementation may have extensions (including additional library > functions), provided they do not alter the behavior of any > strictly conforming program." [...] > > I would have preferred that they call these "conforming" > extensions - that is, extensions that do not render the > implementation non-conforming. I think it would be appropriate > to talk about extensions that render an implementation > non-conforming, calling them "non-conforming extensions". That's a silly idea. Without imposing any limitations on what may be included or excluded, a "non-conforming extension" could be anything (literally anything) at all. It could look like C. It could look like Fortran, or Ada. It could /be/ Fortran or Ada. It could look exactly like C, but always have undefined behavior. Or it could look exactly like C, but always just exit immediately (with EXIT_SUCCESS on Tuesdays, and EXIT_FAILURE the rest of the time). None of these possibilities merit being called an extension of C, non-conforming or otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-30 11:42 -0700 |
| Message-ID | <87o7io9xsv.fsf@nosuchdomain.example.com> |
| In reply to | #173267 |
David Brown <david.brown@hesbynett.no> writes:
> On 29/08/2023 22:06, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Being able to accept $ in identifiers is a convenient extension.
>> Quibble: $ in identifiers is not an extension as specified in
>> section 4
>> of the standard. Starting in C99, the set of characters accepted in
>> identifiers is implementation-defined. (I'm not sure what difference
>> that makes.)
>
> Until it was mentioned in this thread, I didn't realise that dollars
> (or other characters) in identifiers were implementation-defined
> options, rather than requiring it to be an extension. (The
> distinction I would make here is that an "extension" is for something
> that the standard does not cover at all but is documented by the
> compiler - something that would be a syntax error, a constraint
> violation, or undefined behaviour if the compiler did not support it.)
> As you say, I don't think there is a significant difference in
> practice, but I like to understand these things as accurately as I
> can, and I appreciate the bug-fix when I get them wrong.
>
> On a related note, I am looking at 6.4.2.1p3 (in C11) on "universal
> character names", and it appears to say that the characters must come
> from the list in D.1 (but not D.2, for the initial character), but
> also that implementations can allow other characters. This would make
> the D.1 list the minimal set allowed, but implementations could allow
> any (or almost any) other Unicode characters. Do you think that is
> right, or am I missing something?
C23 reworks the definition of "identifier". See N3096 6.4.2.1.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
An identifier may start with any of:
nondigit
XID_Start character
universal-character-name of class XID_Start
followed by zero or more of:
digit
nondigit
XID_Continue character
universal-character-name of class XID_Continue
where "digit" is one of 0..9 and "nondigit" is underscore or one of the
52 uppercase and lowercase Latin letters.
XID_Start and XID_Continue are specified in "UAX #44"
https://unicode.org/reports/tr44/
I haven't yet read enough of it to figure out what those mean.
Annex D has more information.
Under Semantics, N3096 says:
An XID_Start character is an implementation-defined character whose
corresponding code point in ISO/IEC 10646 has the XID_Start
property. An XID_Continue character is an implementation-defined
character whose corresponding code point in ISO/IEC 10646 has the
XID_Continue property.
My understanding is that an implementation will choose and document some
subset of the XID_Start and XID_Continue characters to be valid in
identifiers.
One odd thing (in both N1570 and N3096) is that the Semantics subsection
uses "shall". For example, N1570 6.4.2.1p3 says:
Each universal character name in an identifier shall designate a
character whose encoding in ISO/IEC 10646 falls into one of the
ranges specified in D.1. The initial character shall not be a
universal character name designating a character whose encoding
falls into one of the ranges specified in D.2.
This implies that a violation of such a requirement has undefined
behavior. I would have expected it to be a syntax error.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-30 23:36 -0700 |
| Message-ID | <86a5u7u39b.fsf@linuxsc.com> |
| In reply to | #173337 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [..syntax for identifiers...] > One odd thing (in both N1570 and N3096) is that the Semantics > subsection uses "shall". For example, N1570 6.4.2.1p3 says: > > Each universal character name in an identifier shall designate > a character whose encoding in ISO/IEC 10646 falls into one of > the ranges specified in D.1. The initial character shall not > be a universal character name designating a character whose > encoding falls into one of the ranges specified in D.2. > > This implies that a violation of such a requirement has undefined > behavior. I would have expected it to be a syntax error. Clearly the idea is that implementations be allowed to choose what other universal character names, if any, are to be permitted in identifiers. As an example, consider an implementation that supports the common extension of allowing dollar signs in identifiers. It would make sense, in case a keyboard is being used that doesn't have a dollar sign key, to allow the universal character name for dollar sign (\u0024, IIANM). Other universal character names might serve some other purpose, not being part of the identifier but not necessarily causing an error either. Apparently anything less than undefined behavior was thought to be too limiting.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 08:15 +0000 |
| Message-ID | <20230831011341.24@kylheku.com> |
| In reply to | #173379 |
On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > in identifiers. As an example, consider an implementation that > supports the common extension of allowing dollar signs in > identifiers. It would make sense, in case a keyboard is being > used that doesn't have a dollar sign key, to allow the universal > character name for dollar sign (\u0024, IIANM). Other universal Maybe let that coder expense $15 on the company credit card to get a better keyboard instad of inflicting \u0024 on future maintainers of the code. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-01 11:48 -0700 |
| Message-ID | <86o7ilspa9.fsf@linuxsc.com> |
| In reply to | #173382 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> in identifiers. As an example, consider an implementation that >> supports the common extension of allowing dollar signs in >> identifiers. It would make sense, in case a keyboard is being >> used that doesn't have a dollar sign key, to allow the universal >> character name for dollar sign (\u0024, IIANM). Other universal > > Maybe let that coder expense $15 on the company credit card to get a > better keyboard instad of inflicting \u0024 on future maintainers of the > code. A pointless observation. It's the implementor who is making the decision, and it's easier just to put in the exception than to try to convince even one potential user to get a new keyboard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-03 03:55 -0700 |
| Message-ID | <8734zv7cgb.fsf@nosuchdomain.example.com> |
| In reply to | #173215 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Being able to accept $ in identifiers is a convenient extension.
>
> Quibble: $ in identifiers is not an extension as specified in section 4
> of the standard. Starting in C99, the set of characters accepted in
> identifiers is implementation-defined. (I'm not sure what difference
> that makes.)
On further thought, there is a significant difference.
An implementation that supports $ in identifiers via an via the
"other implementation-defined characters" wording in the syntax
of an identifier can accept foo$bar as an identifier without
issuing a diagnostic. If it's an extension as defined in section 4
(Conformance) of the standard, it can accept foo$bar but it must
still issue a diagnostic (presumably a non-fatal warning).
(That's in conforming mode, of course. The standard has nothing to say
about non-conforming modes.)
--
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-09-03 11:44 -0700 |
| Message-ID | <86il8rqeps.fsf@linuxsc.com> |
| In reply to | #173758 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>
>>> Being able to accept $ in identifiers is a convenient extension.
>>
>> Quibble: $ in identifiers is not an extension as specified in section 4
>> of the standard. Starting in C99, the set of characters accepted in
>> identifiers is implementation-defined. (I'm not sure what difference
>> that makes.)
>
> On further thought, there is a significant difference.
>
> An implementation that supports $ in identifiers via an via the
> "other implementation-defined characters" wording in the syntax
> of an identifier can accept foo$bar as an identifier without
> issuing a diagnostic. If it's an extension as defined in section 4
> (Conformance) of the standard, it can accept foo$bar but it must
> still issue a diagnostic (presumably a non-fatal warning).
I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as
undefined or implementation-defined.
Note the last clause: "even if the behavior is also explicitly
specified as undefined or implementation-defined." This clause
suggests that accepting $ as one of the implementation-defined
characters still warrants a diagnostic.
(And as was pointed out, only if the compiler is invoked in what
is purported to be a conforming mode.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-03 16:20 -0700 |
| Message-ID | <87y1hm6dyl.fsf@nosuchdomain.example.com> |
| In reply to | #173806 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> Being able to accept $ in identifiers is a convenient extension.
>>>
>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>> of the standard. Starting in C99, the set of characters accepted in
>>> identifiers is implementation-defined. (I'm not sure what difference
>>> that makes.)
>>
>> On further thought, there is a significant difference.
>>
>> An implementation that supports $ in identifiers via an via the
>> "other implementation-defined characters" wording in the syntax
>> of an identifier can accept foo$bar as an identifier without
>> issuing a diagnostic. If it's an extension as defined in section 4
>> (Conformance) of the standard, it can accept foo$bar but it must
>> still issue a diagnostic (presumably a non-fatal warning).
>
> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>
> A conforming implementation shall produce at least one
> diagnostic message (identified in an implementation-defined
> manner) if a preprocessing translation unit or translation
> unit contains a violation of any syntax rule or constraint,
> even if the behavior is also explicitly specified as
> undefined or implementation-defined.
>
> Note the last clause: "even if the behavior is also explicitly
> specified as undefined or implementation-defined." This clause
> suggests that accepting $ as one of the implementation-defined
> characters still warrants a diagnostic.
Ah, but the "implementation-defined characters" are part of the syntax.
As of C11, the grammar for an identifier is:
identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit
identifier-nondigit:
nondigit
universal-character-name
other implementation-defined characters
nondigit: one of
[_, a..z, A..Z]
digit: one of
[0..9]
If $ is one of the "other implementation-defined characters" for a given
implementation, then `foo$bar` does not violate a syntax rule.
> (And as was pointed out, only if the compiler is invoked in what
> is purported to be a conforming mode.)
--
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-09-03 16:47 -0700 |
| Message-ID | <86wmx6q0o5.fsf@linuxsc.com> |
| In reply to | #173836 |
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: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> David Brown <david.brown@hesbynett.no> writes: >>>> [...] >>>> >>>>> Being able to accept $ in identifiers is a convenient extension. >>>> >>>> Quibble: $ in identifiers is not an extension as specified in section 4 >>>> of the standard. Starting in C99, the set of characters accepted in >>>> identifiers is implementation-defined. (I'm not sure what difference >>>> that makes.) >>> >>> On further thought, there is a significant difference. >>> >>> An implementation that supports $ in identifiers via an via the >>> "other implementation-defined characters" wording in the syntax >>> of an identifier can accept foo$bar as an identifier without >>> issuing a diagnostic. If it's an extension as defined in section 4 >>> (Conformance) of the standard, it can accept foo$bar but it must >>> still issue a diagnostic (presumably a non-fatal warning). >> >> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says >> >> A conforming implementation shall produce at least one >> diagnostic message (identified in an implementation-defined >> manner) if a preprocessing translation unit or translation >> unit contains a violation of any syntax rule or constraint, >> even if the behavior is also explicitly specified as >> undefined or implementation-defined. >> >> Note the last clause: "even if the behavior is also explicitly >> specified as undefined or implementation-defined." This clause >> suggests that accepting $ as one of the implementation-defined >> characters still warrants a diagnostic. > > Ah, but the "implementation-defined characters" are part of the > syntax. [...] I know that. Since the sentence in 5.1.1.3 p1 specifically calls out cases that are explicitly implementation-defined, it should take precedence. There is a violation of a syntax rule; any argument that there isn't has to rely on implementation-defined behavior, and thus a diagnostic is required.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-03 17:24 -0700 |
| Message-ID | <Is9JM.815111$SuUf.795653@fx14.iad> |
| In reply to | #173844 |
On 9/3/23 4:47 PM, 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: >>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> [...] >>>>> >>>>>> Being able to accept $ in identifiers is a convenient extension. >>>>> >>>>> Quibble: $ in identifiers is not an extension as specified in section 4 >>>>> of the standard. Starting in C99, the set of characters accepted in >>>>> identifiers is implementation-defined. (I'm not sure what difference >>>>> that makes.) >>>> >>>> On further thought, there is a significant difference. >>>> >>>> An implementation that supports $ in identifiers via an via the >>>> "other implementation-defined characters" wording in the syntax >>>> of an identifier can accept foo$bar as an identifier without >>>> issuing a diagnostic. If it's an extension as defined in section 4 >>>> (Conformance) of the standard, it can accept foo$bar but it must >>>> still issue a diagnostic (presumably a non-fatal warning). >>> >>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says >>> >>> A conforming implementation shall produce at least one >>> diagnostic message (identified in an implementation-defined >>> manner) if a preprocessing translation unit or translation >>> unit contains a violation of any syntax rule or constraint, >>> even if the behavior is also explicitly specified as >>> undefined or implementation-defined. >>> >>> Note the last clause: "even if the behavior is also explicitly >>> specified as undefined or implementation-defined." This clause >>> suggests that accepting $ as one of the implementation-defined >>> characters still warrants a diagnostic. >> >> Ah, but the "implementation-defined characters" are part of the >> syntax. [...] > > I know that. Since the sentence in 5.1.1.3 p1 specifically calls > out cases that are explicitly implementation-defined, it should > take precedence. There is a violation of a syntax rule; any > argument that there isn't has to rely on implementation-defined > behavior, and thus a diagnostic is required. No, it says that *IF* there is a violation of a syntax rule, there must be a diagnostic, even if the results of that violation is indicated to be undefined or implementation defined. If $ is an implmenetation defined identifier character, then no violation of a syntax rules exist.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-10-03 03:16 -0700 |
| Message-ID | <861qecdn98.fsf@linuxsc.com> |
| In reply to | #173846 |
Richard Damon <Richard@Damon-Family.org> writes: > On 9/3/23 4:47 PM, 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: >>>> >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>>> >>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> [...] >>>>>> >>>>>>> Being able to accept $ in identifiers is a convenient extension. >>>>>> >>>>>> Quibble: $ in identifiers is not an extension as specified in section 4 >>>>>> of the standard. Starting in C99, the set of characters accepted in >>>>>> identifiers is implementation-defined. (I'm not sure what difference >>>>>> that makes.) >>>>> >>>>> On further thought, there is a significant difference. >>>>> >>>>> An implementation that supports $ in identifiers via an via the >>>>> "other implementation-defined characters" wording in the syntax >>>>> of an identifier can accept foo$bar as an identifier without >>>>> issuing a diagnostic. If it's an extension as defined in section 4 >>>>> (Conformance) of the standard, it can accept foo$bar but it must >>>>> still issue a diagnostic (presumably a non-fatal warning). >>>> >>>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says >>>> >>>> A conforming implementation shall produce at least one >>>> diagnostic message (identified in an implementation-defined >>>> manner) if a preprocessing translation unit or translation >>>> unit contains a violation of any syntax rule or constraint, >>>> even if the behavior is also explicitly specified as >>>> undefined or implementation-defined. >>>> >>>> Note the last clause: "even if the behavior is also explicitly >>>> specified as undefined or implementation-defined." This clause >>>> suggests that accepting $ as one of the implementation-defined >>>> characters still warrants a diagnostic. >>> >>> Ah, but the "implementation-defined characters" are part of the >>> syntax. [...] >> >> I know that. Since the sentence in 5.1.1.3 p1 specifically calls >> out cases that are explicitly implementation-defined, it should >> take precedence. There is a violation of a syntax rule; any >> argument that there isn't has to rely on implementation-defined >> behavior, and thus a diagnostic is required. > > No, it says that *IF* there is a violation of a syntax rule, there > must be a diagnostic, even if the results of that violation is > indicated to be undefined or implementation defined. > > If $ is an implmenetation defined identifier character, then no > violation of a syntax rules exist. I think there is more to be said in this discussion but I have decided not to pursue it for now.
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web