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 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-03 17:26 -0700 |
| Message-ID | <87ttsa6ax2.fsf@nosuchdomain.example.com> |
| In reply to | #173844 |
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:
>>>> 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.
I disagree. A diagnostic is required if:
- A syntax rule or constraint is violated; or
- A syntax rule or constraint is violated and the behavior is explicitly
undefined; or
- A syntax rule or constraint is violated and the behavior is
explicitly implementation-defined.
(The last two cases are arguably covered by the first.)
In this case, no syntax rule is violated, so none of the cases apply,
so no diagnostic is required.
The syntax rule is not violated because the implementation-defined
character is part of the syntax rule. (See the parent article where I
quoted the syntax rule, or see the standard.) It's not the *behavior*
that's implementation defined, it's the *syntax rule*.
I do find it a bit odd, and potentially inconvenient, that one
implementation can quietly accept foo$bar as an identifier and another
can reject it as a syntax error, but that's what the standard says.
--
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-10-03 03:19 -0700 |
| Message-ID | <86wmw4c8k3.fsf@linuxsc.com> |
| In reply to | #173847 |
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: >>>> >>>>> 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. > > I disagree. A diagnostic is required if: > - A syntax rule or constraint is violated; or > - A syntax rule or constraint is violated and the behavior is explicitly > undefined; or > - A syntax rule or constraint is violated and the behavior is > explicitly implementation-defined. > > (The last two cases are arguably covered by the first.) > > In this case, no syntax rule is violated, so none of the cases apply, > so no diagnostic is required. > > The syntax rule is not violated because the implementation-defined > character is part of the syntax rule. (See the parent article where I > quoted the syntax rule, or see the standard.) It's not the *behavior* > that's implementation defined, it's the *syntax rule*. > > I do find it a bit odd, and potentially inconvenient, that one > implementation can quietly accept foo$bar as an identifier and another > can reject it as a syntax error, but that's what the standard says. I appreciate your comments and the thoughtfulness of the message. 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]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-29 19:43 +0000 |
| Message-ID | <20230829122909.854@kylheku.com> |
| In reply to | #173180 |
On 2023-08-29, Bart <bc@freeuk.com> 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? > > 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? What may or may not consistute a an identifier in ISO C is obviously well documented in ISO C; there is no guesswork. A C identifiers is a nonempty mixture of letters, digits and underscores, not beginning with a digit. Disallowing other characters leaves room for local extension. Linkers use special characters like period, dollar sign, at and others. Assemblers also. Programs which use these characters by way of a language extension risk clashing with those internal uses. For instance if you were to use $123 as an identifier name and it ends up as an assembly language operand, the assembler might interpet it as a constant: movl $123, %eax > Can I safely use it with any compiler apart > from Tiny C? I don't know. A few ASCII symbols are not part of C at all. C does not make use of @ and $. So outside of a comment or string literal, and a few other situations, these are syntax errors in the standard dialect. I think there are now some conversion specifiers in printf that might use dollar sign (which is in a string literal). Objective-C uses @ to introduce extensions. That trivially ensures that its features don't clash with anything in C. Including future features, as long as C avoids introducing @. > (I use '$' extensively in machine-generated code.) I used a Modula 2 compiler called Top Speed which used dollar signs at the linkage level: <module_name>$<symbol_name>. -- 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-29 13:23 -0700 |
| Message-ID | <87wmxda98x.fsf@nosuchdomain.example.com> |
| In reply to | #173213 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-29, Bart <bc@freeuk.com> wrote:
[...]
>> So is '$' allowed or not?
>
> What may or may not consistute a an identifier in ISO C is obviously
> well documented in ISO C; there is no guesswork.
>
> A C identifiers is a nonempty mixture of letters, digits and
> underscores, not beginning with a digit.
I'm afraid it's not that simple. C99 added universal-character-names
and "other implementation-defined characters". One conforming compiler
can accept `foo$bar` without a warning; another can reject it as a
syntax error.
[...]
> A few ASCII symbols are not part of C at all. C does not make use of @
> and $. So outside of a comment or string literal, and a few other
> situations, these are syntax errors in the standard dialect.
The missing symbols are '$', '`', and '@'. C23 adds all three as
mandatory extended characters.
> I think there are now some conversion specifiers in printf that might
> use dollar sign (which is in a string literal).
Some implementations might use it in an extension, but the standard
doesn't.
[...]
--
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 | Bobby Moore <bobbymoore018@gmail.com> |
|---|---|
| Date | 2023-08-29 13:54 -0700 |
| Message-ID | <8b9f0727-340e-4f85-a5d6-0e13178a48c6n@googlegroups.com> |
| In reply to | #173221 |
Description Purchase DMT powder online Buy DMT powder online is an effective hallucinogen, as well as a kind of tryptamine alkaloid. It is a normally happening material, discovered in various plants and also pets, and also in small quantities in the human mind, where its function is unidentified. DMT is famous for its power, though the psychedelic trip it creates only lasts 5 to half an hour when smoked. The impact is extensive and also remarkable, with the sensation that the user is transferred to a completely various location, submersed in kaleidoscopic noises as well as pictures. In its pure kind, the medication is a white to yellow crystalline strong. https://methamphetaminebox.com/product/buy-dmt-crystal-online/ https://methamphetaminebox.com/product/buy-dmt-crystal-online/ Acquire DMT powder online has been taken in throughout history and into prehistory by aboriginal individuals, specifically in South America, where it is taken in throughout shamanic routines and called ayhuasca. This is done by combining plant product that contains it with a monoamine oxide inhibitor, an unique chemical that permits the medication to prevent digestion by the tummy and also get to the bloodstream. Proof of DMT consumption by aboriginal peoples in South America stretches back to a minimum of 2130 BC. A pipeline made from puma bone of that age was checked favorable for the material. Smoking it would give the individuals visions and feelings that they connected with magical sources, placing them into contact with “spirits” they can seek advice from on issues of plants, illness, and so on. A few of the most unusual psychedelic trip reports originate from customers of DMT, who report “rotating quadrate vortices,” discussions with intelligent alien-type animals, and so forth. These reports are uncommon because of their strength and also the sensation of meeting smart beings, which is evocative what happens to lots of people each night in desires. Though clinical examination of the results of the medication has actually been restricted, cognitive scientific research may be able to find out more concerning the human mind by seeing just how it transforms its procedure in feedback to tryptamines. Spiritualists might be inclined to believe that the beings that individuals “fulfill” intoxicated might in fact feed on identical aircrafts, which has actually introduced alternating religion systems or worldviews based on the experience. DMT is a powerful hallucinogen, suggested to be thoroughly administered in a tranquil setting to somebody who has prior experience with various other psychedelic drugs. The medicine is relatively uncommon because of the lack of industrial demand as well as the shortage of individuals with the understanding and also motivation to separate it from plants. Still, as a molecule, it appears like a terrain ripe for exploration. Untried conjectures have actually suggested that the DMT located normally in the mind may be implicated in specific neurological states, and if it is synthetically provided, it may pull these “switches as well as bars” in manner ins which can be extra exactly defined and studied. As the human brain is the most complicated well-known things in the universe, identifying the specific way in which it engages with complicated particles like this may be just one of the biggest clinical obstacles of all time. Get DMT powder online is a white crystalline powder that is stemmed from specific plants discovered in Mexico, South America as well as parts of Asia. It is usually evaporated or smoked in a pipeline, or eaten by mouth in brews like ayahuasca. Sometimes, DMT is grunted or injected. Acquire DMT powder online’s chemical root structure is similar to the anti-migraine medicine sumatriptan, and it functions as a non-selective agonist at most or all of the serotonin receptors. Serotonin is a neurotransmitter that widely affects most of our body’s mind cells. When smoked, the ordinary dose of DMT is 30-150 mg, and also the start of action can be really felt virtually promptly. The results peak and also plateau for 3-5 minutes, and slowly leave with the duration of impact totaling 30-45 mins. When eaten as a brew, the dose is in between 35-75 mg. Effects begin after 30-45 mins, optimal at 2-3 hours and are resolved in 4-6 hours. Road names of Buy DMT powder online Dmitri Businessman’s journey Businessman’s unique Fantasia Forty-five-minute psychosis. Degree of DMT use Purchase DMT powder online has no approved medical use in the US however can be made use of by researchers under a Schedule I study registration that requires authorization from both the DEA as well as the Fda (FDA). DMT is utilized illicitly for its psychoactive, hallucinogenic impacts. Customers report “spiritual understanding” as one of the most commonly reported favorable impacts of the drug. The vast bulk of new DMT individuals are already experienced with making use of hallucinogens, and also as holds true with other unlawful hallucinogens, customers acquire the drug through the Internet. Use DMT has actually enhanced in recent years, suggesting that the medicine might be obtaining in popularity. The National Study on Drug Use and Health and wellness disclosed that the number of individuals in the United States that reported making use of some kind of DMT had actually increased from 688,000 individuals in 2006 to 1,475,000 in 2012. Adverse effects of Buy DMT powder online A person is having a surreal hallucination with clocks. The primary result of DMT is the experience of intense hallucinations that change the individual’s assumption of the globe around them. The main effect of DMT is mental, with extreme visual as well as acoustic hallucinations, ecstasy and also a modified feeling of space, body as well as time. Several individuals explain profound, life-changing experiences such as going to other worlds, chatting with alien entities as well as full changes in the assumption of identification and also fact. In contrast to various other psychedelic drugs (LSD, ketamine, magic mushrooms), recreational users of DMT consider it to have the most affordable adverse effects account. Possible side effects of Buy DMT powder online may include: Enhanced heart price Raised high blood pressure Chest pain or rigidity Agitation Dilated students Quick rhythmic movements of the eye Wooziness When taken orally, DMT can cause queasiness, throwing up as well as looseness of the bowels. Depending upon the specific customer, the DMT experience can be either extremely amazing or overwhelmingly frightening. The experience can be so effective that users might have problem handling as well as integrating the “trip” right into their reality. Mental adverse effects may remain for numerous days or weeks after ingestion of the medicine. Health threats of DMT Due to the fact that DMT is structurally related to the natural chemical serotonin, a problem called serotonin syndrome is a possibly dangerous health and wellness threat that can be connected with its use. People taking antidepressants go to greatest risk for this problem. Serotonin syndrome happens when the body builds up a too much amount of serotonin. The condition is often brought on by taking a mix of different medicines. Way too much serotonin in the body can cause signs and symptoms such as: Anxiety Confusion Hypertension Loss of muscle coordination Frustration At higher dosages, Purchase DMT powder online can create seizures, breathing arrest and coma. DMT can have significant unfavorable consequences for individuals with pre-existing mental problems or a mental disorder such as schizophrenia. As a result of limited research data, DMT is not known to create physical reliance or addiction, although frequent recreational customers may create emotional food cravings for the medicine. The National Institute on Drug Abuse (NIDA) recommend that, unlike various other hallucinogens, DMT usage does not appear to cause tolerance of the medication. 5-MeO-DMT, additionally called 5-Methoxy-N, N-dimethyltryptamine is a normally occurring psychedelic of the tryptamine class, 5-MeO-DMT exposes structural similarities to N, N-Dimethyltryptamine (DMT), nonetheless studies have actually shown chemical characteristics that may resemble a greater effectiveness than the better recognized substance. It is distributed in a wide range of plant types and also in the venom of a few psychedelic pathogens such as Bufo Alvaris. PURCHASE 5-MeO-DMT 5-MeO-DMT, additionally referred to as 5-Methoxy-N, N-dimethyltryptamine is a normally occurring psychedelic of the tryptamine class, 5-MeO-DMT bares architectural resemblances to N, N-Dimethyltryptamine (DMT), nevertheless researches have actually revealed chemical features that might appear like a greater strength than the better recognized substance. It is distributed in a wide array of plant types and in the poison of a couple of psychedelic virus such as Bufo Alvaris. 5-MeO-DMT can be located in the milky white venom of the Colorado River Toad. South American medicine men have actually used toad poisonous substance for hundreds of years Today, both the extracts of the toad poisonous substance and the synthetic powder form are examined. Its synthesis as well as outcomes were first documented in Alexander Shulgin’s 1997 book TiHKAL (” Tryptamines I Have Actually Known and Liked”). Recent researches have revealed that it can supply magical end results during research study and has actually expanded in popularity over the past couple of years. Just how to utilize 5-MeO-DMT? Buy 5-MeO-DMT in the best quality freebase as well as hydrochloride type. Buy 5-MeO-DMT research chemicals in the quantities 0,25 gr, 0,5 gr, 1gr, 2gr, 5gr, and 10gr. Make certain to keep the 5-MeO-DMT in a completely dry as well as great place for maximum shelf-life. When handling study chemicals ensure to constantly take the appropriate precautions busy like cleaning down surface areas and wearing handwear covers, a mask & protective garments. We advise additional caution with 5-MeO-DMT as a result of its high potency. Meaning 5-MeO-DMT The definition of 5-MeO-DMT is officially called 5-Methoxy-N, N-dimethyltryptamine. 5-MeO-DMT is a normally occurring but extremely potent psychedelic of the tryptamine class. It’s even considered as the most powerful psychedelic in research study chemical background. Chemistry background details 5-MeO-DMT Research study shows that 5-MeO-DMT creates its results by binding to serotonin receptors, although the exact system is unknown. 5-methoxy-N, N-dimethyltryptamine is a ring-substituted indole alkaloid tryptamine. and shares a core of a bicylic indole heterocycle connected at R3 to a terminal amine team by means of an ethyl side chain. It’s thought that 5-MeO-DMT is very powerful. Research study suggests that this compound is likely to generate huge as well as remarkable lead to that lab. Therefore, It is highly recommended to use injury decrease practices when carrying out study on this compound. Where to purchase 5-MeO-DMT 5-MeO-DMT can be purchased right here on the cosmos pharma internet site. We market premium top quality 5-MeO-DMT, typically in powder. However, we often have other substance forms offered, so do not hesitate to contact us to see if we have your favored compound form in supply. You have to be at the very least 18 years of ages to get 5-MeO-DMT from us. Buy 4-aco-dmt online. 4-aco-dmt (also known as O-Acetylpsilocin, 4-Acetoxy-DMT, or Psilacetin) is a synthetically produced psychedelic tryptamine. This allows 4-aco-dmt to function as a perfect substitute for psilocybin mushrooms. 4-aco-dmt or 4-high-temperature N, N-dimethyltryptamine is a synthetic indole alkaloid molecule of the tryptamine class. 4-aco-dmt and several other esters of psilocin were originally patented on January 16, 1963 by Sandoz Ltd. Via Albert Hofmann & Franz Troxler.[2][3] Despite this fact, 4-aco-dmt remains a psychedelic with a limited history of use prior to its release as a grey area compound on the online research chemical market. The Science Behind You can buy 4-aco-dmt without a doctor. It is a semi-manufactured compound. It’s accepted to be a prodrug of psilocin. This may boost thoughts of O-acetylpsilocin conceivably filling in as a substitute to psilocybin for use in research of the impact’s hallucinogenic mixes in medicine. You know the science of it, now order 4-aco-dmt online. Action: However, the role of these interactions and how they lead into the Psychedelic experience continues to be elusive. There are, however, claims of subjective differences in strength between acetylated and non-acetylated forms of psilocin. [4] Some users report that 4-aco-dmt lasts a little longer than psilocin while the other report, it lasts for a significantly shorter time. Many users report less body weight and nausea, compared to psilocin. Some users believe that the visual distortion of the production of 4-aco-dmt more closely resembles those produced by DMT than psilocin. These differences may be possible if 4-aco-dmt itself, and not just as a pro-drug. 4-AcO-DMT and all other designer drugs sold on this website are for research and legal applications. 4-AcO-DMT is a designer drug of tryptamine type with physiological apparent and psychoactive effects and has the molecular formula C14H18N2O2 • HCl. The weight of the formula has a cost of 282.8g.- mol. Buy 4-aco-dmt online at affordable prices. https://methamphetaminebox.com/ https://methamphetaminebox.com/product/buy-dmt-5ml-deadhead-chemist-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-5-meo-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-5ml-dmt-cartridge/ https://methamphetaminebox.com/product/buy-schwifty-labs-5-ml-5-meo-dmt-cartridge/ https://methamphetaminebox.com/product/buy-purecybin-1ml-700mg-dmt-carts/ https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/ https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/ https://methamphetaminebox.com/product/buy-crystal-meth-online/ https://methamphetaminebox.com/product/buy-4-fa-powder-online/ https://methamphetaminebox.com/product/buy-25i-nbome-powder-legally/ https://methamphetaminebox.com/product/a-pvp-crystals-for-sale/ https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/ https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/ https://methamphetaminebox.com/product/buy-dmt-crystal-online/ https://methamphetaminebox.com/product/buy-diclazepam-online/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-29 11:41 +0200 |
| Message-ID | <uckefj$26moa$1@dont-email.me> |
| In reply to | #173130 |
On 29/08/2023 02:36, Bart wrote:
> 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.
>
While you still need to remember things, it does make it harder to get
the order wrong when writing the code or for someone else reading the code.
> 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 agree with all these points.
>
>>> 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-29 08:29 -0700 |
| Message-ID | <86cyz5vpdk.fsf@linuxsc.com> |
| In reply to | #173130 |
Bart <bc@freeuk.com> writes: [...] I have no reason to think your comments were offered in good faith, but posted just to stir up trouble. Go annoy someone else.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-29 16:54 +0100 |
| Message-ID | <ucl4c3$2akbu$1@dont-email.me> |
| In reply to | #173198 |
On 29/08/2023 16:29, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > > [...] > > I have no reason to think your comments were offered in > good faith, but posted just to stir up trouble. Go > annoy someone else. OK, since we're being so civil, then fuck you, too. I was pointing out shortcomings in your alternative to keyword parameters. Sure these are workarounds that some will employ because the feature doesn't exit. But any C programmer will have long learned to create their own such solutions. Better to have the actual feature. My remarks weren't specifically aimed at you. I was commenting on the ideas. But if you were annoyed, then all the better.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-30 19:30 +0000 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <9OdIB8bvkgNvRPt7n@bongo-ra.co> |
| In reply to | #173127 |
On Mon, 28 Aug 2023 16:49:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >> 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.
If one is willing to write a wrapper function then why not do it like this :
struct struct_strcpy {
char * to ;
const char * from ;
}
and have the wrapper function take as a single argument a pointer to struct
struct_strcpy .This way no changes to the language are needed , everyone can
choose whatever member names they prefer , they can reuse the same structure
object if some members have the same value for different function calls (and
assign to the other members) and they can define a structure with default
values if they so wish.
Does having named arguments offer anything over this approach ?
> > 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.
--
Every theatre is an insane asylum, but an opera theatre is the
ward for the incurables.
Franz Schalk
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-30 19:53 +0000 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <20230830124510.831@kylheku.com> |
| In reply to | #173341 |
On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> If one is willing to write a wrapper function then why not do it like this :
>
> struct struct_strcpy {
> char * to ;
> const char * from ;
> }
>
> and have the wrapper function take as a single argument a pointer to struct
> struct_strcpy .This way no changes to the language are needed , everyone can
> choose whatever member names they prefer
Not according to the rule that struct types in different translation
units must havre the same member names if they are to be considered
compatible.
> they can reuse the same structure
> object if some members have the same value for different function calls (and
> assign to the other members) and they can define a structure with default
> values if they so wish.
>
> Does having named arguments offer anything over this approach ?
Pragmatics:
- Poor ergonomics of calling functions that take struct-encapsulated
tuple arguments instead of individual arguments.
- E.g. clumsy for a function to call another function that *almost* takes
the same arguments. The incoming struct must be destructured,
and the member values used to initialize the new structure.
- Reduced diagnosis: all arguments have become optional, because
designated initializers are optional! If we add a new parameter by
adding a member to the struct, the compiler will not find the places
that need a new argument.
- ABI concerns: binary compatibility now dominated by rules for
structure passing.
- Poor performance in ABIs that don't use registers for struct passing,
even for small structs.
--
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 | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-30 20:07 +0000 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <=cpNTIYn=xLPR00Wq@bongo-ra.co> |
| In reply to | #173344 |
On Wed, 30 Aug 2023 19:53:02 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> > If one is willing to write a wrapper function then why not do it like this :
> >
> > struct struct_strcpy {
> > char * to ;
> > const char * from ;
> > }
> >
> > and have the wrapper function take as a single argument a pointer to struct
> > struct_strcpy .This way no changes to the language are needed , everyone can
> > choose whatever member names they prefer
>
> Not according to the rule that struct types in different translation
> units must havre the same member names if they are to be considered
> compatible.
Why would anyone choose different member names in different translation
units ? They just declare the structure once in some header.
> > they can reuse the same structure
> > object if some members have the same value for different function calls (and
> > assign to the other members) and they can define a structure with default
> > values if they so wish.
> >
> > Does having named arguments offer anything over this approach ?
>
> Pragmatics:
>
> - Poor ergonomics of calling functions that take struct-encapsulated
> tuple arguments instead of individual arguments.
>
> - E.g. clumsy for a function to call another function that *almost* takes
> the same arguments. The incoming struct must be destructured,
> and the member values used to initialize the new structure.
I don't see how this becomes simpler with named arguments.
> - Reduced diagnosis: all arguments have become optional, because
> designated initializers are optional! If we add a new parameter by
> adding a member to the struct, the compiler will not find the places
> that need a new argument.
Yes this may be an issue. But compilers could warn about it.
> - ABI concerns: binary compatibility now dominated by rules for
> structure passing.
>
> - Poor performance in ABIs that don't use registers for struct passing,
> even for small structs.
I said
the wrapper function take as a single argument a pointer to struct
--
vlaho.ninja/prog
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-30 20:42 +0000 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <20230830130958.888@kylheku.com> |
| In reply to | #173345 |
On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Wed, 30 Aug 2023 19:53:02 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
>> > If one is willing to write a wrapper function then why not do it like this :
>> >
>> > struct struct_strcpy {
>> > char * to ;
>> > const char * from ;
>> > }
>> >
>> > and have the wrapper function take as a single argument a pointer to struct
>> > struct_strcpy .This way no changes to the language are needed , everyone can
>> > choose whatever member names they prefer
>>
>> Not according to the rule that struct types in different translation
>> units must havre the same member names if they are to be considered
>> compatible.
>
> Why would anyone choose different member names in different translation
> units ? They just declare the structure once in some header.
OK, I wrongly interpreted "everyone can choose whatever member names
they prefer" means. Not everyone working in the same project,
calling the same function.
>
>> > they can reuse the same structure
>> > object if some members have the same value for different function calls (and
>> > assign to the other members) and they can define a structure with default
>> > values if they so wish.
>> >
>> > Does having named arguments offer anything over this approach ?
>>
>> Pragmatics:
>>
>> - Poor ergonomics of calling functions that take struct-encapsulated
>> tuple arguments instead of individual arguments.
>>
>> - E.g. clumsy for a function to call another function that *almost* takes
>> the same arguments. The incoming struct must be destructured,
>> and the member values used to initialize the new structure.
>
> I don't see how this becomes simpler with named arguments.
void foo(int a, int b, int c)
{
bar(a: c, b: b:, c: a, d: SOME_CONSTANT);
}
vs something like:
void foo(foo_struct args)
{
bar((bar_struct) {a: args.c, b: args.b:, c: args.a, d: SOME_CONSTANT});
}
You're missing syntactic sugar to make it smooth. What I want here
is a translator for a C-with-named-args to C-without-name-args
which generates the latter code from the former.
Another issue is that if a structure takes names args by way
of a structure, then that is not optional, unlike the proposals
for names args which make them optional.
The former foo() could dispense with named args and just call
bar like this:
bar(a, b, c, SOME_CONSTANT);
(If bar is an internal helper in the same module, with the argument
conventions being consistent, why would you bother with named args.)
>> - Reduced diagnosis: all arguments have become optional, because
>> designated initializers are optional! If we add a new parameter by
>> adding a member to the struct, the compiler will not find the places
>> that need a new argument.
>
> Yes this may be an issue. But compilers could warn about it.
Or other solutions, like a declaration mechanism in a struct/enum
which stipulates that certain members must be explicitly initialized
(and so become de facto required arguments when structs are used
as parameter tuples).
>
>> - ABI concerns: binary compatibility now dominated by rules for
>> structure passing.
>>
>> - Poor performance in ABIs that don't use registers for struct passing,
>> even for small structs.
>
> I said
> the wrapper function take as a single argument a pointer to struct
Probably, this is something that projects would decide on a case
by case basis.
Dealing with structs passed by pointer at the ABI level is much more
consistent; you're only dealing with the layout rules. E.g. targetting
a function with a struct pointer argument versus struct argument
via FFI can be easier (in particular if there is no ownership protocol:
caller continues to own).
There is the extra pointer indirection though. We lose the ability
to pass small numbers of scalar parameters via registers.
We don't (necessarily) lose that that with a struct by-value.
It's entirely possible that a struct { int a, b, c, d; } is passed via
four registers.
--
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 Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-08-30 23:15 +0100 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <ucof1i$2tbqe$1@dont-email.me> |
| In reply to | #173345 |
On 30/08/2023 21:07, Spiros Bousbouras wrote:
>
> I said
> the wrapper function take as a single argument a pointer to struct
>
Can a struct have the same qualifiers as a function?
I mean, say you have:
void foo(const char * restrict bar);
Can you have ...?
struct foo
{
const char * restrict bar;
};
void foos(struct foo foo);
... ?
Does the const/restrict'ness survive?
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-31 18:41 +0000 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <FH2PvBd=Z3nt=LKcX@bongo-ra.co> |
| In reply to | #173358 |
On Wed, 30 Aug 2023 23:15:13 +0100
Richard Harnden <richard.nospam@gmail.com> wrote:
> On 30/08/2023 21:07, Spiros Bousbouras wrote:
>
> >
> > I said
> > the wrapper function take as a single argument a pointer to struct
> >
>
> Can a struct have the same qualifiers as a function?
>
> I mean, say you have:
> void foo(const char * restrict bar);
>
> Can you have ...?
>
> struct foo
> {
> const char * restrict bar;
> };
>
> void foos(struct foo foo);
>
> ... ?
>
> Does the const/restrict'ness survive?
The syntax allows it but to what extent the semantics are different , I'm not
sure. For restrict I'm not clear about the details even if it's not a member
of a structure.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-31 12:43 +0200 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <ucpqt4$37q88$1@dont-email.me> |
| In reply to | #173345 |
On 30/08/2023 22:07, Spiros Bousbouras wrote: > On Wed, 30 Aug 2023 19:53:02 -0000 (UTC) > Kaz Kylheku <864-117-4973@kylheku.com> wrote: >> - ABI concerns: binary compatibility now dominated by rules for >> structure passing. >> >> - Poor performance in ABIs that don't use registers for struct passing, >> even for small structs. > > I said > the wrapper function take as a single argument a pointer to struct > The wrapper function could be an inline function in a header, along with the struct definition. Then there would be no ABI concerns because only the original ABI is used - any overheads due to the struct and and wrapper disappear.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-30 20:40 -0700 |
| Subject | Re: Named function arguments (Was : C vs Haskell for XML parsing) |
| Message-ID | <86r0njubf1.fsf@linuxsc.com> |
| In reply to | #173341 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Mon, 28 Aug 2023 16:49:21 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> 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.
>
> If one is willing to write a wrapper function then why not do it
> like this :
>
> struct struct_strcpy {
> char * to ;
> const char * from ;
> }
>
> and have the wrapper function take as a single argument a pointer
> to struct struct_strcpy . [...]
Because it's needlessly clunky, and adds annoying visual clutter
at every call site.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-28 14:15 +0000 |
| Message-ID | <q_1HM.144952$ftCb.122801@fx34.iad> |
| In reply to | #172904 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Kaz Kylheku <864-117-4973@kylheku.com> writes: >[...] >> If required, positional parameters are going to be callable using named >> arguments, the named arguments must be a mandatory part of the function >> definition. > >Named arguments are already mandatory for function definitions (barring >old-style definitions). Nit, IIRC, you don't need the name if you don't use the parameter.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-28 15:53 +0100 |
| Message-ID | <uciccb$1o58a$1@dont-email.me> |
| In reply to | #173003 |
On 28/08/2023 15:15, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> [...]
>>> If required, positional parameters are going to be callable using named
>>> arguments, the named arguments must be a mandatory part of the function
>>> definition.
>>
>> Named arguments are already mandatory for function definitions (barring
>> old-style definitions).
>
> Nit, IIRC, you don't need the name if you don't use the parameter.
>
This program:
void F(int,int,int) {}
int main(void) {}
generally results in hard errors in I think 5 out of 6 compilers I
tried. Only gcc on Windows passed it with no comment.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-28 18:41 +0200 |
| Message-ID | <uciinp$1p8qk$1@dont-email.me> |
| In reply to | #173007 |
On 28/08/2023 16:53, Bart wrote:
> On 28/08/2023 15:15, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> [...]
>>>> If required, positional parameters are going to be callable using named
>>>> arguments, the named arguments must be a mandatory part of the function
>>>> definition.
>>>
>>> Named arguments are already mandatory for function definitions (barring
>>> old-style definitions).
>>
>> Nit, IIRC, you don't need the name if you don't use the parameter.
That's true in C++, but not true in C until C2x comes out.
>>
>
> This program:
>
> void F(int,int,int) {}
>
> int main(void) {}
>
> generally results in hard errors in I think 5 out of 6 compilers I
> tried. Only gcc on Windows passed it with no comment.
As you know, gcc does not try to be accurately conforming to the
standards unless you give it appropriate command line flags. In
particular, it tends to be lax in accepting some syntax from later C
standards (and occasionally C++), as long as there is no conflict with
valid code of the specified (or default) standard. So gcc accepts this
because C2x will allow it, or because C++ allows it, and it is a simple
and obvious extension.
If you don't like that, you know what flags to give gcc to get the
standards-required diagnostic. (The standards do not require a "hard
error". For some kinds of mistakes in code, I would agree with you that
a hard error would be far better than a warning or silently accepting
the code by default - but in this case, a hard error is an overreaction
unless you want to enforce very strict checking.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-28 18:01 +0100 |
| Message-ID | <uciju2$1pkgn$1@dont-email.me> |
| In reply to | #173022 |
On 28/08/2023 17:41, David Brown wrote:
> On 28/08/2023 16:53, Bart wrote:
>> On 28/08/2023 15:15, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> [...]
>>>>> If required, positional parameters are going to be callable using
>>>>> named
>>>>> arguments, the named arguments must be a mandatory part of the
>>>>> function
>>>>> definition.
>>>>
>>>> Named arguments are already mandatory for function definitions (barring
>>>> old-style definitions).
>>>
>>> Nit, IIRC, you don't need the name if you don't use the parameter.
>
> That's true in C++, but not true in C until C2x comes out.
Why is the standard moving backwards?
>
>>>
>>
>> This program:
>>
>> void F(int,int,int) {}
>>
>> int main(void) {}
>>
>> generally results in hard errors in I think 5 out of 6 compilers I
>> tried. Only gcc on Windows passed it with no comment.
>
> As you know, gcc does not try to be accurately conforming to the
> standards unless you give it appropriate command line flags.
'gcc c.c' on Windows (13.2.0) passed it; 'gcc c.c' on WSL (9.4.0)
failed it.
I've given up trying to make sense of gcc's behaviour. WHATEVER it does
or doesn't do, even when it contradicts itself, people will always find
an excuse for it.
But this one is unusual: normally newer gcc tries to continue passing
legacy code that older versions passed. Now, it can be passing code that
older versions *failed*.
gcc appears to be doing a passing (no pun) imitation of Trump: no matter
what crazy stuff it does, people like it all the more!
It will please people when it does X instead of Y, and please those who
want it to do Y when it does Y instead of X, and it will please those
who like the 'flexibility' of it being able to either X or Y.
Any complaints about the behaviour, Oh, you can just add these
half-dozen obscure options to give the correct behaviour, which of
course you already knew about in advance, to join the other 200 weird
behaviours.
The fact that you're then dividing C into two languages: C which allows
parameter names to be omitted from definitions, and C which doesn't, is
of no consequences. So you end up define one of 2**N dialects where N is
the number of behaviour-altering options. What language are you
programming in, again?
> If you don't like that, you know what flags to give gcc to get the
> standards-required diagnostic.
As I said...
> (The standards do not require a "hard
> error". For some kinds of mistakes in code, I would agree with you that
> a hard error would be far better than a warning or silently accepting
> the code by default - but in this case, a hard error is an overreaction
> unless you want to enforce very strict checking.)
In this case, the rule can very simple: each parameter name in a
definiton MUST be named.
(Accidentally delete a parameter name 'abc', and it's possible that a
reference to that parameter in the function now matches a global 'abc'.)
[toc] | [prev] | [next] | [standalone]
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web