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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-23 19:30 +0200 |
| Message-ID | <uc5foc$311jt$1@dont-email.me> |
| In reply to | #172699 |
On 23/08/2023 17:21, Malcolm McLean wrote: > On Wednesday, 23 August 2023 at 16:05:55 UTC+1, Bart wrote: >> On 23/08/2023 15:48, Malcolm McLean wrote: >>> On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: >>>> On 23/08/2023 06:59, Malcolm McLean wrote: >> >>> I'm not arguing that text without spaces is easier to read than text with >>> spaces. However spaces in C identifiers are not allowed. The fact that >>> for many hundereds of years people wrote text without spaces >> Where did they do that? I guess you'd not talking about programming syntax. >> tells you >> > The modern system of separating words by spaces was only introduced in > about the seventh century, by Irish monks. Not true. Earlier writing systems used a variety of word separation systems, going back long before Greek or Latin manuscripts. But there was a period in Greek and Latin writing where unseparated writing was common. However, it is important to note that the source of such writing was done by different people (not the authors, but scribes - typically slaves who did not attempt to understand the text but simply transcribed verbatim). They were written for a different purpose - as memory aids to speeches (usually given by the same author), not as texts to be read regularly. Making the text hard to read was an advantage, because it hindered competitors and made reading more exclusive. And saving on paper or writing material was an advantage due to the cost. When readability was important, interpuncts were often used in Latin. However, "scriptio continua" was common enough that it was also used in books (again, saving a little space might have been a factor). It was only later that Europeans began to use writing as something other than a recording of speech that it became important to make text more readable - and word separation made an enormous difference. It turned writing into a way to spread knowledge, rather than just a memory aid. And it was perhaps one of the reasons Europe was gradually able to catch up with the Islamic world - the Arabic script was much easier to read because the word divisions were clear from the shape of the letters. So yes, there was a period where manuscripts in Europe were often written without inter-word divisions. It was not a good thing, and readability hugely improved when it went out of fashion. > The earliest classical texts we > have use dots or lines to separate words, but fairly soon that was dropped > and all the words were simply run together. That was in use for about 2,000 > years. Well, closer to about 1000 years - and it was not universally practised. Humorism - the "theory" that sickness was due to an imbalance of the four humors and should be cured by blood-letting - held sway for about 2000 years. That does not make it a good idea. >>> that, though it's less readable than text with spaces, it's not that difficult >>> to read. >> It can sometimes lead to ambiguities when word boundaries are not marked. >> >> Eg. #amazonshitcarshow >> > Yes. Spaces are better. Although spoken language doesn't usually have pauses > between words. Yes, it does. They are often very small, but they are very significant and it is easily distinguishable. If you speak a synthetic language (i.e., a language where words are often combined into longer words), it is entirely clear when you have separate words or a combined word, because there is a pause in the sound. For example, in Norwegian "dyrlege" is a vet, while "dyr lege" is an expensive doctor - Norwegian speakers will hear the difference. > The question is what to do for C identifiers, where spaces are not allowed. The > scriptio continua system was used for a very long time, so it must have at least > something going for it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-23 18:50 +0200 |
| Message-ID | <uc5dd0$30jrk$1@dont-email.me> |
| In reply to | #172697 |
On 23/08/2023 16:48, Malcolm McLean wrote: > On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: >> On 23/08/2023 06:59, Malcolm McLean wrote: >> >> All I can tell you here is that /I/ would not expect a "determinant" >> function to trash the matrix I pass to it. If /I/ were writing a >> determinate function, I would do so in a way that did not trash the >> caller's data, and did not take noticeably longer. And if I were >> convinced that some operations, such as this one, were significantly >> more efficient without copying, and destruction was fine for a >> significant proportion of use-cases, I'd make an explicit >> "determinant_destructive" version. The non-destructive version would, >> of course, take a const pointer. > I don't need the matrix after taking the determinant. And at the moment, I > don't have another use for the function. There's a trade-off between speed > and good interfaces, and I might change it to retain the matrix. There might > also be a faster way of obtaining the information I need. My own > mathematical ability is also a constraint. An API that unexpectedly trashes user data is a bad API. If you feel that people will never need their matrices after finding the determinant, and that this is the most efficient way of implementing the function, then fair enough - but make it absolutely clear what you are doing. One part of that is the documentation (as you have rightly pointed out). Another is the name of the function - "determinant" is not a good name for a destructive function. And another important aid is to distinguish between functions that change their parameters and functions that do not by using "const" pointers appropriately. No matter how you look at it, "const" pointers are important. >> >> In no circumstances would I make a function that left the caller's data >> "corrupt" or "indeterminate". >> >> (Oh, and I'd write it in C++ to give a much better user API here. C's >> great for some things - but it's not the best choice for everything.) >> > No, it's far better in C. In C++ it would pull in a "Matrix" class, and then > it's totally unusable in another program unless someone wants to take > that entire apparatus. If you don't know how to make good API's in C++, ask down the hall in comp.lang.c++. I /do/ know how, and I know your disagreement here is based on misunderstanding, but I really don't want to go more off-topic here. I'll just give you a hint - free-standing functions exist in C++, just like in C, and are "pulled in" to exactly the same extent. >> >>> No, it's a known problem. >> I note you haven't actually looked at references for it. It is a known >> /consideration/ - not a known /problem/. When you hit a row with a zero >> on the diagonal, you simply swap it with a row further down that does >> not have zero in that column. Swapping rows multiplies the determinant >> by -1. If there is no such row, the determinant is 0. (In fact, it is >> common to swap rows for Gaussian elimination anyway to improve numerical >> stability. But that is definitely off-topic here.) >> > My matrix will occasionally have a zero in the top left hand cell. (It's a Sylvester > matrix giving the coefficients of two simulataneous equations, and the > determinant represents the product of the difference of the roots, plus > a term based on the highest coefficents. If the determiant is zero or so close > to zero that it represents machine precision problems, then the equations > have a root in common, which is what I'm interested in. However because of > the factor based on the highest coefficients, it's useless to me if the top left > is zero. However I have to do something. Gaussian elimination is an O(n³) algorithm for calculating determinants. It is not, I believe, the most efficient known algorithm - but to get much better you need a much more complicated algorithm. The recursive formula - your fall-back - is O(n!). That quickly gets unusable if your matrices are more than perhaps 6 rows/columns. >> >> Do you really believe you are making a sound argument here? Or do you >> realise that you are conflating completely different concepts? I'm >> trying to think of a single example in this thread where you have >> actually addressed the question, and actually justified your decisions. >> But it's just a field of straw men fishing for red herrings. >> > If you provide aboolean type then you encourage people to write functions > that take boolean parameters. We were talking about an API - /you/ pick the parameters. And boolean parameters are fine, as long as their use is clear - just like "int" parameters, and "char * " parameters, and all other parameters. Booleans are not somehow magically complicated or error-prone - /any/ generic type is equally error-prone in the face of poor API's or unclear information. > Of course intelligent people like you and I > can see, as soon as the problem is pointed out, that this isn't a good idea, > and will have the self-discipline to write enums. But a lot of people won't. > So it's better not to have a boolean type. Of course they can still pass > "1" or "0" in an int, but at least this isn't beign actively encouraged. >>> So bool is pretty useless and we're better off without it. >> No, bool is pretty useful and we are better off having it. >> > It's useful where a function returns a boolean true / false value whose > meaning is obvious from the function definition. And it is useful in > marking fields of structures which are logically true / false (though here > it can be a rather extravagant use of memory and you might be better > off with bitfields). > But these are minor aids to readability, whilst boolean parameters are > major impediments to readability. Booleans can be significant aids to readability, and any duplicated parameter type can be unclear - booleans are not different there. > The there's the if (value == true) problem. No there is not. Stop making up nonsense. >> >> Are you /seriously/ suggesting that "readfilefromdisk" is easy to read? >> Better than, say, "read_file_from_disk" or "readFileFromDisk" ? (Not >> that I think the camel-case version is particularly easy to read here - >> but it is a world better than your choice of jumble.) >> > In programs, yes. Such an extraordinary claim requires extraordinary evidence. Would you like to provide references to studies showing this? And I note that - from a quick look at your babyxrc code - you regularly use functions with names like "bbx_utf8_skip" as well as camel-case such as "trailingBytesForUTF8". If you really thought that "bbxutf8skip" and "trailingbytesforutf8" were easier to read, why did you not use them? > Because you have many identifiers all jostling for attention. If that's a problem, try a better layout for your code, putting white space in appropriately to keep parts clearer. > As a single word in flowing lowercase text, the decorated version is > maybe easier to read. What do you mean by "decorated" ? >>> In fact, as you >>> are obviously not aware, scripto continua was the norm for ancient manuscripts.. >> I am entirely aware of that. I have not studied such things >> academically, but I have a far above average interest in history and >> writing systems. Are you aware of /why/ ancient manuscripts (and other >> old writing) was regularly written without spacing? I'll give you a >> clue - it was /not/ in order to make the text easier to read. >> > I'm not arguing that text without spaces is easier to read than text with > spaces. Yes you were. But if you've changed your mind, that's good. Sometimes a hypocrite is just someone who is learning. > However spaces in C identifiers are not allowed. The fact that > for many hundereds of years people wrote text without spaces tells you > that, though it's less readable than text with spaces, it's not that difficult > to read. OK, so you /don't/ know why some kinds of manuscripts were written without spaces (or other inter-word symbols). >> >>> A const void * is not an opaque pointer. We can say something about how the >>> called function will handle the data it points to. >> Yes - that's a good thing. > But it's not an opaque pointer any more. Yes, it is still an opaque pointer (that's a bad thing in general), and yes, we know something about it (that's a good thing). It is now an opaque pointer to data that is not changed by the function using it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-23 10:49 -0700 |
| Message-ID | <81879984-43e7-409a-a029-1ca6677f536dn@googlegroups.com> |
| In reply to | #172700 |
On Wednesday, 23 August 2023 at 17:50:54 UTC+1, David Brown wrote: > On 23/08/2023 16:48, Malcolm McLean wrote: > > On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: > >> On 23/08/2023 06:59, Malcolm McLean wrote: > >> > >> All I can tell you here is that /I/ would not expect a "determinant" > >> function to trash the matrix I pass to it. If /I/ were writing a > >> determinate function, I would do so in a way that did not trash the > >> caller's data, and did not take noticeably longer. And if I were > >> convinced that some operations, such as this one, were significantly > >> more efficient without copying, and destruction was fine for a > >> significant proportion of use-cases, I'd make an explicit > >> "determinant_destructive" version. The non-destructive version would, > >> of course, take a const pointer. > > I don't need the matrix after taking the determinant. And at the moment, I > > don't have another use for the function. There's a trade-off between speed > > and good interfaces, and I might change it to retain the matrix. There might > > also be a faster way of obtaining the information I need. My own > > mathematical ability is also a constraint. > An API that unexpectedly trashes user data is a bad API. If you feel > that people will never need their matrices after finding the > determinant, and that this is the most efficient way of implementing the > function, then fair enough - but make it absolutely clear what you are > doing. One part of that is the documentation (as you have rightly > pointed out). Another is the name of the function - "determinant" is > not a good name for a destructive function. And another important aid > is to distinguish between functions that change their parameters and > functions that do not by using "const" pointers appropriately. > > No matter how you look at it, "const" pointers are important. > The function was written specially for the specific problem of the Sylvester matrix. The first version was obviously the recursive version, since it is easy to get right, and is adequate for testing the logic. That version doens't corrupt the matrix. So by your logic, it should have taken a const *. But then I moved to Gaussian elimination. Now to keep the same signature, I would have had to take a local copy, involving a memory allocation (and, to be strict about it, a failure condition). But there was no need, because all I need is the determinant. I can throw away the matrix after I have that. So the best decisoon seemed to be not to introduce the unneccessary inefficiency. However I'm fully aware that it makes the function less usable for other purposes. > >> > >> In no circumstances would I make a function that left the caller's data > >> "corrupt" or "indeterminate". > >> > >> (Oh, and I'd write it in C++ to give a much better user API here. C's > >> great for some things - but it's not the best choice for everything.) > >> > > No, it's far better in C. In C++ it would pull in a "Matrix" class, and then > > it's totally unusable in another program unless someone wants to take > > that entire apparatus. > If you don't know how to make good API's in C++, ask down the hall in > comp.lang.c++. I /do/ know how, and I know your disagreement here is > based on misunderstanding, but I really don't want to go more off-topic > here. I'll just give you a hint - free-standing functions exist in C++, > just like in C, and are "pulled in" to exactly the same extent. > You might. But my experience of C++ is that it is much harder to take a function froma C++ prgram and integrate it into another program than it is to take a fucntion written in C and do the same thing. > > > My matrix will occasionally have a zero in the top left hand cell. (It's a Sylvester > > matrix giving the coefficients of two simulataneous equations, and the > > determinant represents the product of the difference of the roots, plus > > a term based on the highest coefficents. If the determiant is zero or so close > > to zero that it represents machine precision problems, then the equations > > have a root in common, which is what I'm interested in. However because of > > the factor based on the highest coefficients, it's useless to me if the top left > > is zero. However I have to do something. > Gaussian elimination is an O(n³) algorithm for calculating determinants. > It is not, I believe, the most efficient known algorithm - but to get > much better you need a much more complicated algorithm. The recursive > formula - your fall-back - is O(n!). That quickly gets unusable if your > matrices are more than perhaps 6 rows/columns. > The matrices are 6x6 so the fallback, though slow, isn't catastrophic. There might be a faster way of doing 6x6es, but I don't know it. > > >> Do you really believe you are making a sound argument here? Or do you > >> realise that you are conflating completely different concepts? I'm > >> trying to think of a single example in this thread where you have > >> actually addressed the question, and actually justified your decisions. > >> But it's just a field of straw men fishing for red herrings. > >> > > If you provide aboolean type then you encourage people to write functions > > that take boolean parameters. > We were talking about an API - /you/ pick the parameters. > > And boolean parameters are fine, as long as their use is clear - just > like "int" parameters, and "char * " parameters, and all other > parameters. Booleans are not somehow magically complicated or > error-prone - /any/ generic type is equally error-prone in the face of > poor API's or unclear information. > No they are not. drawPath(mypath, false) conveys no information. The first parameter is obviously a path, but the second one could mean almost anything. Functions that take boolean parameters are a bad idea, and should be discouraged. And one way to do that is not to have a boolean type, so people are not tempted to use it. > > > Booleans can be significant aids to readability, and any duplicated > parameter type can be unclear - booleans are not different there. > No. Take qsort(). It is a bit of a nuisance that the two middle parameters are both size_ts, and it's hard to remember which is which. But when you read a call to qsort in code, it will be. qsort(data, sizeof(ELEMENT), Nelements, compfunc); So you can tell that this is a bug, without any other information. > > And I note that - from a quick look at your babyxrc code - you regularly > use functions with names like "bbx_utf8_skip" as well as camel-case such > as "trailingBytesForUTF8". If you really thought that "bbxutf8skip" and > "trailingbytesforutf8" were easier to read, why did you not use them? > That code was written ten years ago. It is still solid. The tables were copied from some reference implementation and I kept the original identiifers. I do use bbx_ as a prefix. That's because C doesn't have namespaces, so the sequence bbx_ marks it as part of Baby X. But it's meant to be invisible, I want the reader to filter it out. > > Because you have many identifiers all jostling for attention. > If that's a problem, try a better layout for your code, putting white > space in appropriately to keep parts clearer. Oh come on. You've been programming for long enough to know what typical code looks like. > > As a single word in flowing lowercase text, the decorated version is > > maybe easier to read. > What do you mean by "decorated" ? camelCase or under_scores, decorated. continuoustext, undecorated. > > > However spaces in C identifiers are not allowed. The fact that > > for many hundereds of years people wrote text without spaces tells you > > that, though it's less readable than text with spaces, it's not that difficult > > to read. > OK, so you /don't/ know why some kinds of manuscripts were written > without spaces (or other inter-word symbols). > It;s not really known. Hebrew texts do have spaces. It's probably something to do with different Semitic and Indo-European concepts of word building. (That also explains why the Greeks changed the direction of the text, it's to do with the word entering the right visual field and therefore brain hemisphere). But this sort of thing is a bit speculative. Saving expensive manuscript may have been a factor, but probably not the real reason. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-23 18:08 +0000 |
| Message-ID | <UWrFM.311809$Fgta.286106@fx10.iad> |
| In reply to | #172705 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Wednesday, 23 August 2023 at 17:50:54 UTC+1, David Brown wrote: >> >>=20 >> >> (Oh, and I'd write it in C++ to give a much better user API here. C's= >=20 >> >> great for some things - but it's not the best choice for everything.)= >=20 >> >>=20 >> > No, it's far better in C. In C++ it would pull in a "Matrix" class, and= > then=20 >> > it's totally unusable in another program unless someone wants to take= >=20 >> > that entire apparatus. >> If you don't know how to make good API's in C++, ask down the hall in=20 >> comp.lang.c++. I /do/ know how, and I know your disagreement here is=20 >> based on misunderstanding, but I really don't want to go more off-topic= >=20 >> here. I'll just give you a hint - free-standing functions exist in C++,= >=20 >> just like in C, and are "pulled in" to exactly the same extent. >>=20 >You might. But my experience of C++ is that it is much harder to take a fun= >ction >froma C++ prgram and integrate it into another program than it is to take >a fucntion written in C and do the same thing. That has not been my experience. I routinely call C++ functions from C, from assembler and from python - all in the same application.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-23 21:28 +0200 |
| Message-ID | <uc5mlk$32gl3$1@dont-email.me> |
| In reply to | #172705 |
On 23/08/2023 19:49, Malcolm McLean wrote: > On Wednesday, 23 August 2023 at 17:50:54 UTC+1, David Brown wrote: >> On 23/08/2023 16:48, Malcolm McLean wrote: >>> On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: >>>> On 23/08/2023 06:59, Malcolm McLean wrote: >>>> >>>> All I can tell you here is that /I/ would not expect a "determinant" >>>> function to trash the matrix I pass to it. If /I/ were writing a >>>> determinate function, I would do so in a way that did not trash the >>>> caller's data, and did not take noticeably longer. And if I were >>>> convinced that some operations, such as this one, were significantly >>>> more efficient without copying, and destruction was fine for a >>>> significant proportion of use-cases, I'd make an explicit >>>> "determinant_destructive" version. The non-destructive version would, >>>> of course, take a const pointer. >>> I don't need the matrix after taking the determinant. And at the moment, I >>> don't have another use for the function. There's a trade-off between speed >>> and good interfaces, and I might change it to retain the matrix. There might >>> also be a faster way of obtaining the information I need. My own >>> mathematical ability is also a constraint. >> An API that unexpectedly trashes user data is a bad API. If you feel >> that people will never need their matrices after finding the >> determinant, and that this is the most efficient way of implementing the >> function, then fair enough - but make it absolutely clear what you are >> doing. One part of that is the documentation (as you have rightly >> pointed out). Another is the name of the function - "determinant" is >> not a good name for a destructive function. And another important aid >> is to distinguish between functions that change their parameters and >> functions that do not by using "const" pointers appropriately. >> >> No matter how you look at it, "const" pointers are important. >> > The function was written specially for the specific problem of the Sylvester > matrix. The first version was obviously the recursive version, since it > is easy to get right, and is adequate for testing the logic. That version > doens't corrupt the matrix. So by your logic, it should have taken a const *. My logic is that if the function /specification/ is for read-only access to the data, it should be "const". If the /specification/ says that the pointer parameter is for output data (or modified data), then it should be non-const. There is very little call for a function whose specification is that it will corrupt or destroy the input data - but if that's the specification, then it should be non-const. The declaration is part of the specification, not the implementation - the implementation is irrelevant once the API specification is in place. (You may, of course, have implementation details in mind when writing the specification and declaration.) > But then I moved to Gaussian elimination. Now to keep the same signature, > I would have had to take a local copy, involving a memory allocation > (and, to be strict about it, a failure condition). But there was no need, because > all I need is the determinant. I can throw away the matrix after I have that. > So the best decisoon seemed to be not to introduce the unneccessary > inefficiency. However I'm fully aware that it makes the function less usable > for other purposes. >>>> >>>> In no circumstances would I make a function that left the caller's data >>>> "corrupt" or "indeterminate". >>>> >>>> (Oh, and I'd write it in C++ to give a much better user API here. C's >>>> great for some things - but it's not the best choice for everything.) >>>> >>> No, it's far better in C. In C++ it would pull in a "Matrix" class, and then >>> it's totally unusable in another program unless someone wants to take >>> that entire apparatus. >> If you don't know how to make good API's in C++, ask down the hall in >> comp.lang.c++. I /do/ know how, and I know your disagreement here is >> based on misunderstanding, but I really don't want to go more off-topic >> here. I'll just give you a hint - free-standing functions exist in C++, >> just like in C, and are "pulled in" to exactly the same extent. >> > You might. But my experience of C++ is that it is much harder to take a function > froma C++ prgram and integrate it into another program than it is to take > a fucntion written in C and do the same thing. It's true that C++ tends to use more proper types, and this means more of the code hangs together. This goes along with better APIs for things like matrices (or at least, the possibility of writing better APIs) that are more modular, and clearer and safer to use. But done well the classes and their functions are perfectly usable in other programs - better, often, than functions written in C, because they are often more flexible. >> >>> My matrix will occasionally have a zero in the top left hand cell. (It's a Sylvester >>> matrix giving the coefficients of two simulataneous equations, and the >>> determinant represents the product of the difference of the roots, plus >>> a term based on the highest coefficents. If the determiant is zero or so close >>> to zero that it represents machine precision problems, then the equations >>> have a root in common, which is what I'm interested in. However because of >>> the factor based on the highest coefficients, it's useless to me if the top left >>> is zero. However I have to do something. >> Gaussian elimination is an O(n³) algorithm for calculating determinants. >> It is not, I believe, the most efficient known algorithm - but to get >> much better you need a much more complicated algorithm. The recursive >> formula - your fall-back - is O(n!). That quickly gets unusable if your >> matrices are more than perhaps 6 rows/columns. >> > The matrices are 6x6 so the fallback, though slow, isn't catastrophic. > There might be a faster way of doing 6x6es, but I don't know it. I'm telling you - Gaussian elimination, with row-swapping as needed. It's not hard. >> >>>> Do you really believe you are making a sound argument here? Or do you >>>> realise that you are conflating completely different concepts? I'm >>>> trying to think of a single example in this thread where you have >>>> actually addressed the question, and actually justified your decisions. >>>> But it's just a field of straw men fishing for red herrings. >>>> >>> If you provide aboolean type then you encourage people to write functions >>> that take boolean parameters. >> We were talking about an API - /you/ pick the parameters. >> >> And boolean parameters are fine, as long as their use is clear - just >> like "int" parameters, and "char * " parameters, and all other >> parameters. Booleans are not somehow magically complicated or >> error-prone - /any/ generic type is equally error-prone in the face of >> poor API's or unclear information. >> > No they are not. drawPath(mypath, false) conveys no information. Nor does drawRectangle(100, 200, 300, 400). And certainly nor does drawPath(mypath, 0). It's all a matter of suitable function naming, declarations and typing, along with documentation and consistent API design. I fully agree that an enum can often be clearer - though without C++ or good compiler warnings, enums are easily abused. My point is not that "bool" is clearer than all alternatives - merely that it is clearer than a 0/1 int. > The > first parameter is obviously a path, but the second one could mean almost > anything. Functions that take boolean parameters are a bad idea, and > should be discouraged. And one way to do that is not to have a boolean > type, so people are not tempted to use it. >> >> >> Booleans can be significant aids to readability, and any duplicated >> parameter type can be unclear - booleans are not different there. >> > No. Take qsort(). It is a bit of a nuisance that the two middle parameters > are both size_ts, and it's hard to remember which is which. But when you > read a call to qsort in code, it will be. > qsort(data, sizeof(ELEMENT), Nelements, compfunc); > So you can tell that this is a bug, without any other information. You have the information about the parameters to the function. How is that any different if the parameters are size_t or if they are bool? > > >> >> And I note that - from a quick look at your babyxrc code - you regularly >> use functions with names like "bbx_utf8_skip" as well as camel-case such >> as "trailingBytesForUTF8". If you really thought that "bbxutf8skip" and >> "trailingbytesforutf8" were easier to read, why did you not use them? >> > That code was written ten years ago. It is still solid. The tables were > copied from some reference implementation and I kept the original > identiifers. > I do use bbx_ as a prefix. That's because C doesn't have namespaces, so > the sequence bbx_ marks it as part of Baby X. But it's meant to be invisible, > I want the reader to filter it out. >>> Because you have many identifiers all jostling for attention. >> If that's a problem, try a better layout for your code, putting white >> space in appropriately to keep parts clearer. > Oh come on. You've been programming for long enough to know what > typical code looks like. I do, yes - to the extent that there is such a thing as "typical code". Long identifiers, all in lower case, made of multiple words with no underscores, are not typical code. And sometimes code looks jumbled and crushed - often better spacing can make a significant difference if you feel that's a problem for your code. (Too much spacing is also bad, of course.) >>> As a single word in flowing lowercase text, the decorated version is >>> maybe easier to read. >> What do you mean by "decorated" ? > camelCase or under_scores, decorated. continuoustext, undecorated. OK, so now you are saying that camelCase and under_scores makes things more readable? Or are you saying that this only applies to "flowing lowercase text", and that continuoustext identifiers are magically more readable than alternatives in other circumstances? >> >>> However spaces in C identifiers are not allowed. The fact that >>> for many hundereds of years people wrote text without spaces tells you >>> that, though it's less readable than text with spaces, it's not that difficult >>> to read. >> OK, so you /don't/ know why some kinds of manuscripts were written >> without spaces (or other inter-word symbols). >> > It;s not really known. There are some reasonable plausibilities, as I wrote in another post. You are, of course, correct that such things are rarely fully known - that's the nature of history. > Hebrew texts do have spaces. It's probably something to do > with different Semitic and Indo-European concepts of word building. It is primarily a matter of vowels. Hebrew was traditionally written with no vowels - at most, a few diacriticals as pronunciation hints. Such writing without any word-break indications would be hopelessly unreadable. Thus Hebrew has never (or at least, very rarely) been without word breaks. When writing in the Greek and Latin alphabets, however, vowels were always written - it is then feasible (though difficult) to interpret the text despite a lack of spaces. > (That also > explains why the Greeks changed the direction of the text, it's to do with the > word entering the right visual field and therefore brain hemisphere). No, it is not. It is because the Greeks wrote notes in sand, and also in wax tablets (as did the Romans). Right-to-left writing would smudge that for right-handed writers. (Earlier Greek was written more slowly, and often carved - like a number of older languages, it was not uncommon to change direction for each line.) In contrast, Arabic was written using a fine brush, held below the text being written, and could therefore have developed in either direction. I don't know why it happened to be right-to-left - it may have been as much luck as design. Brain hemispheres have nothing to do with it - any bias you think you have here is a result of the direction you learned to read, not the cause of the direction of the writing. > But this > sort of thing is a bit speculative. Saving expensive manuscript may have been a > factor, but probably not the real reason. I gave several reasons, and I expect it was a combination of these (and possibly others that I did not think of).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-23 20:53 -0700 |
| Message-ID | <8eec8404-4928-4bc3-8b00-c673ea22ab60n@googlegroups.com> |
| In reply to | #172708 |
On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote: > > > No they are not. drawPath(mypath, false) conveys no information. > Nor does drawRectangle(100, 200, 300, 400). > The function obviously draws a rectangle. And those values are almost certainly pixel values. If they were rbg values they would go from 0-255, and a normal raster designed for human viewing will have pixel co-ordinates in that range. So the call means either "draw a rectangle at 100,200 with width 300 pixels and height 400 pixels. Or it means "draw rectangle with top left at 100, 200 and bottom right at 300,400". We don't know which. (And we don't know whether y represents row indices or height from origin, or how the system gets context for colour, transformation, and so on, but we'll have that sort of information froma general understanding of the graphics system). Of course you can implement things perversely or unusually, so there might be no dimensions passed at all and it's all done by matrix transformations in the graphics context. That's a logical possibility. But we're talking about what the code probably means, and what the reader can understand. > > And certainly nor does drawPath(mypath, 0). > > It's all a matter of suitable function naming, declarations and typing, > along with documentation and consistent API design. > > I fully agree that an enum can often be clearer - though without C++ or > good compiler warnings, enums are easily abused. My point is not that > "bool" is clearer than all alternatives - merely that it is clearer than > a 0/1 int. > Yes, that is true. But it's all about psychology. If a parameter is an int, people are more likely to think "we should have a define for that". If it is boolean, you already have true/flase, so what more do you need? > > > qsort(data, sizeof(ELEMENT), Nelements, compfunc); > > So you can tell that this is a bug, without any other information. > You have the information about the parameters to the function. How is > that any different if the parameters are size_t or if they are bool? > void mysort(ELEMENT *data, int N, bool casesensitive, bool embeddednumbers) Ok, so it's pretty obvious what mysort() does, and most people ought to be able to call it successfully and say what it is doing, based on that information. But when we see a call mysort(data, Nelements, false, true); what are the last two parameters meant to mean? Even if we can remember that mysort() can be case sensitive or case-insensitive, and has an option for treating embedded numbers as values, we probably can't remember which one is the first parameter and which one is the second. But consider now the second parameter. Because it's an integer, it's unlikely to be hard coded. And most people will give it a sensible name like Nelements. So we know that it's the number of elements in the "data" array, not the size of an element, and not some sort of flag to control the type of sort. If it's hardcoded, it will have a value like "100", and we will probably know from context that that is the hardcoded size of the data array. Even if we don't have such context, "100" is quite likely as the size of a table. > > I do, yes - to the extent that there is such a thing as "typical code". > Long identifiers, all in lower case, made of multiple words with no > underscores, are not typical code. > Standard library functions are the most commonly called functions in C code, and are always named in my style. User functions can't use abbreviations as easily, so they tend to be a bit longer. But most aren't very long, one English word or two words. There are occasional exceptions where it's hard to think of a short name which adequately describes the function. But it's better to remain consistent. > > And sometimes code looks jumbled and crushed - often better spacing can > make a significant difference if you feel that's a problem for your > code. (Too much spacing is also bad, of course.) > >>> As a single word in flowing lowercase text, the decorated version is > >>> maybe easier to read. > >> What do you mean by "decorated" ? > > camelCase or under_scores, decorated. continuoustext, undecorated. > OK, so now you are saying that camelCase and under_scores makes things > more readable? Or are you saying that this only applies to "flowing > lowercase text", and that continuoustext identifiers are magically more > readable than alternatives in other circumstances? > Yes. It;s the highlighting paradox. A bit of highlighting makes text easier to read. But if you over-do it, then the highlighted text becomes hard to read. > One identifier in camelCase is easier to read than the same program with that identiifer in camelcase. But programs don't usually contain only one identifier, they have hundreds of them, in close proximity to each other. So you're in the "over-highlighted" area of the highlighting paradox. > > It;s not really known. > There are some reasonable plausibilities, as I wrote in another post. > You are, of course, correct that such things are rarely fully known - > that's the nature of history. > Your source is probably looking at classical slavery throuhg the lens of American slavery. American slaves were menial workers and held in contempt. But a slave scribe in the Roman Empire would have been a fairly high status individual. He might have had a slave himself to attend to his personal needs. Think of Bill Gates' personal pilot for the sort of figure he would be. > > Hebrew texts do have spaces. It's probably something to do > > with different Semitic and Indo-European concepts of word building. > It is primarily a matter of vowels. Hebrew was traditionally written > with no vowels - at most, a few diacriticals as pronunciation hints. > Such writing without any word-break indications would be hopelessly > unreadable. Thus Hebrew has never (or at least, very rarely) been > without word breaks. When writing in the Greek and Latin alphabets, > however, vowels were always written - it is then feasible (though > difficult) to interpret the text despite a lack of spaces. > But the spaces are not part of the Torah. They are regarded as man-made, not God-given. So there must have been an early tradition of text without spaces. But the Dead Sea scrolls are written with spaces, and they were composed at the same time that most Latin and Greek texts were written continuously. > > > (That also > > explains why the Greeks changed the direction of the text, it's to do with the > > word entering the right visual field and therefore brain hemisphere). > No, it is not. It is because the Greeks wrote notes in sand, and also > in wax tablets (as did the Romans). Right-to-left writing would smudge > that for right-handed writers. (Earlier Greek was written more slowly, > and often carved - like a number of older languages, it was not uncommon > to change direction for each line.) > > In contrast, Arabic was written using a fine brush, held below the text > being written, and could therefore have developed in either direction. > I don't know why it happened to be right-to-left - it may have been as > much luck as design. > > Brain hemispheres have nothing to do with it - any bias you think you > have here is a result of the direction you learned to read, not the > cause of the direction of the writing. > You might be right here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-24 15:15 +0200 |
| Message-ID | <uc7l4o$3fp72$1@dont-email.me> |
| In reply to | #172711 |
On 24/08/2023 05:53, Malcolm McLean wrote: > On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote: >> >>> No they are not. drawPath(mypath, false) conveys no information. >> Nor does drawRectangle(100, 200, 300, 400). >> > The function obviously draws a rectangle. And those values are almost > certainly pixel values. If they were rbg values they would go from 0-255, > and a normal raster designed for human viewing will have pixel co-ordinates > in that range. Is it (x1, y1, x2, y2) ? (x, y, w, h) ? (row, column, height, width) ? Is the y coordinate from the top down, or bottom up? Are we in pixels, millimetres, points, or something else? Are we relative to a window, or a screen, or an abstract desktop? Are we doing something very different, such as using indices into arrays of 3-D points in a scene definition? The point is, without context and more information (such as the declaration of the function with parameter names, or a knowledge of its use), you don't know enough to interpret the meaning of the parameters. You can guess, but you could be wrong. This is exactly the same whether it is a series of "int" parameters or some "bool" parameters, or other generic types. Such issues are well-known, as are solutions - strong typing (possible even in C, though the language doesn't have great support for it - a struct parameter with compound literals and designated literals one way), named parameters, chained function calls, etc. And of course, clear and consistent API's with good declarations and documentation are key. > >> I fully agree that an enum can often be clearer - though without C++ or >> good compiler warnings, enums are easily abused. My point is not that >> "bool" is clearer than all alternatives - merely that it is clearer than >> a 0/1 int. >> > Yes, that is true. But it's all about psychology. If a parameter is an int, > people are more likely to think "we should have a define for that". If it is > boolean, you already have true/flase, so what more do you need? I think you are imagining things, or extrapolating them from your own coding habits. > >> >>> qsort(data, sizeof(ELEMENT), Nelements, compfunc); >>> So you can tell that this is a bug, without any other information. >> You have the information about the parameters to the function. How is >> that any different if the parameters are size_t or if they are bool? >> > void mysort(ELEMENT *data, int N, bool casesensitive, bool embeddednumbers) > > Ok, so it's pretty obvious what mysort() does, and most people ought to be able > to call it successfully and say what it is doing, based on that information. > > But when we see a call > > mysort(data, Nelements, false, true); > > what are the last two parameters meant to mean? Even if we can remember that > mysort() can be case sensitive or case-insensitive, and has an option for > treating embedded numbers as values, we probably can't remember which one > is the first parameter and which one is the second. I agree entirely that a call like this is hard to interpret unless you know the details of the function. I agree entirely that an enum type for each parameter would make it clearer. (C++'s strong enum types are /hugely/ better than C's weak enums for such purposes.) I simply disagree with the suggestion that "bool" is worse than other types. "mysort(data, Nelements, 0, 1);" is even harder to interpret - at least with "false" and "true" we know the parameters are on/off flags. >> >> I do, yes - to the extent that there is such a thing as "typical code". >> Long identifiers, all in lower case, made of multiple words with no >> underscores, are not typical code. >> > Standard library functions are the most commonly called functions in C code, > and are always named in my style. No, they are not. Names with all lower case and no word separation are common in the C standard library for short identifiers (like "strlen"), while underscores are common for longer identifiers (like "memory_order_relaxed"). It would be nice if you were to check this kind of thing before making pointlessly incorrect claims. > > User functions can't use abbreviations as easily, Of course they can. > so they tend to be a bit > longer. But most aren't very long, one English word or two words. There > are occasional exceptions where it's hard to think of a short name which > adequately describes the function. But it's better to remain consistent. Short names are useful for things that are used often. Longer and more descriptive names are better for things that are used more rarely. Either way, readability is the key - for common identifiers, brevity improves reading speed, while for less common identifiers it is helpful to be clearer and more explicit. For longer identifiers, underscores are vital to readability (camel-case is fine in medium cases, but can be a poor choice when the identifier consists of several words). Consistency is a benefit, but it is not a priority - it does not trump readability. >> >> And sometimes code looks jumbled and crushed - often better spacing can >> make a significant difference if you feel that's a problem for your >> code. (Too much spacing is also bad, of course.) >>>>> As a single word in flowing lowercase text, the decorated version is >>>>> maybe easier to read. >>>> What do you mean by "decorated" ? >>> camelCase or under_scores, decorated. continuoustext, undecorated. >> OK, so now you are saying that camelCase and under_scores makes things >> more readable? Or are you saying that this only applies to "flowing >> lowercase text", and that continuoustext identifiers are magically more >> readable than alternatives in other circumstances? >> > Yes. It;s the highlighting paradox. A bit of highlighting makes text easier to > read. But if you over-do it, then the highlighted text becomes hard to read. Please stop your habit of using "Malcolm terms" as though they were real things. There is no such thing as "the highlighting paradox". Before you write something like that, next time check to see if there is a Wikipedia entry for your term and if that matches your usage. There is no "highlighting paradox", and what you describe is not a paradox. (Look up that concept in Wikipedia too.) If you are trying to say that trying to highlight everything results in highlighting nothing, just write that. Or better - don't bother writing it, because it is entirely obvious. >> > One identifier in camelCase is easier to read than the same program with > that identiifer in camelcase. But programs don't usually contain only one > identifier, they have hundreds of them, in close proximity to each other. > So you're in the "over-highlighted" area of the highlighting paradox. > That could conceivably be a valid argument, if camel-case were being used to highlight identifiers. But it is not - it is used to make the identifiers easier to read. Have you ever used a modern editor or IDE? Do you know what "syntax highlighting" is? That applies different appearances to different parts of the language syntax - everything is "highlighted", but it makes the code easier to read. > >>> It;s not really known. >> There are some reasonable plausibilities, as I wrote in another post. >> You are, of course, correct that such things are rarely fully known - >> that's the nature of history. >> > Your source is probably looking at classical slavery throuhg the lens of > American slavery. What? I'm sorry, but you really have very little idea of what you are talking about. I am well aware of the wide range of statuses that could apply to slaves in the classical Roman and Greek societies - with some having significant status, their own slaves, their own property, etc. Most scribes were /not/ high status slaves, and were certainly not privy to the details of politics, diplomacy and other aspects of running the societies. There were a few who were acted more as advisors and were of higher status. But usually a good scribe was one who did not remember or think about the things he wrote down - he was a dictation machine, and perhaps also required to read aloud and track accounts. For many uses, the less he understood about what was being written, the better. > American slaves were menial workers and held in > contempt. But a slave scribe in the Roman Empire would have been a > fairly high status individual. He might have had a slave himself to attend > to his personal needs. Think of Bill Gates' personal pilot for the sort of > figure he would be. > >>> Hebrew texts do have spaces. It's probably something to do >>> with different Semitic and Indo-European concepts of word building. >> It is primarily a matter of vowels. Hebrew was traditionally written >> with no vowels - at most, a few diacriticals as pronunciation hints. >> Such writing without any word-break indications would be hopelessly >> unreadable. Thus Hebrew has never (or at least, very rarely) been >> without word breaks. When writing in the Greek and Latin alphabets, >> however, vowels were always written - it is then feasible (though >> difficult) to interpret the text despite a lack of spaces. >> > But the spaces are not part of the Torah. They are regarded as man-made, not > God-given. So there must have been an early tradition of text without spaces. I think you have no basis for that conclusion - even if we assume, for the sake of argument, that the letters were "God-given". The paper (or other material) and ink are all man-made, but found in every scroll of the Torah. As I understand it, Kabalists do not view spaces or punctuation as significant when trying to find hidden patterns in the letters of the Torah. But Hebrew texts were written with spaces - there is (apparently) no good evidence of Hebrew being written without spaces. However, my knowledge of these things is all indirect - I don't know any Hebrew, I only know a little about the language and its script. > But the Dead Sea scrolls are written with spaces, and they were composed at > the same time that most Latin and Greek texts were written continuously. >> >>> (That also >>> explains why the Greeks changed the direction of the text, it's to do with the >>> word entering the right visual field and therefore brain hemisphere). >> No, it is not. It is because the Greeks wrote notes in sand, and also >> in wax tablets (as did the Romans). Right-to-left writing would smudge >> that for right-handed writers. (Earlier Greek was written more slowly, >> and often carved - like a number of older languages, it was not uncommon >> to change direction for each line.) >> >> In contrast, Arabic was written using a fine brush, held below the text >> being written, and could therefore have developed in either direction. >> I don't know why it happened to be right-to-left - it may have been as >> much luck as design. >> >> Brain hemispheres have nothing to do with it - any bias you think you >> have here is a result of the direction you learned to read, not the >> cause of the direction of the writing. >> > You might be right here. > >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-24 07:50 -0700 |
| Message-ID | <639e8e6f-2729-476b-9a6e-0b3eb066b06an@googlegroups.com> |
| In reply to | #172713 |
On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote: > On 24/08/2023 05:53, Malcolm McLean wrote: > > On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote: > >> > >>> No they are not. drawPath(mypath, false) conveys no information. > >> Nor does drawRectangle(100, 200, 300, 400). > >> > > The function obviously draws a rectangle. And those values are almost > > certainly pixel values. If they were rbg values they would go from 0-255, > > and a normal raster designed for human viewing will have pixel co-ordinates > > in that range. > Is it (x1, y1, x2, y2) ? (x, y, w, h) ? (row, column, height, width) ? > Is the y coordinate from the top down, or bottom up? Are we in > pixels, millimetres, points, or something else? Are we relative to a > window, or a screen, or an abstract desktop? Are we doing something > very different, such as using indices into arrays of 3-D points in a > scene definition? > We're not in millimeters probably, because the co-ordinates are integer values. (I know they could be real but just written as integers, and of course it's not physically impossible to build a device that draws on discrete millimetre values. But we're probably nor dealing with millimeters.) It could be points rather than pixels, fair enough (on our system, "pixel" is a bit of a fuzzy concept because the document can have several physical representations, and so we use points by default. But again, the points are reals.) Whilst we know that the function draws a rectangle, we don't know the details of the graphics system. But we do know that it caches colour at least, because the function takes four parameters to describe a rectangle. > > The point is, without context and more information (such as the > declaration of the function with parameter names, or a knowledge of its > use), you don't know enough to interpret the meaning of the parameters. > You can guess, but you could be wrong. This is exactly the same whether > it is a series of "int" parameters or some "bool" parameters, or other > generic types. > Yes, you can be wrong. But you've a pretty good idea what the call probably does, just from one line, and from an example chosen to illustrate the opposite point. And of course whilst I've spoken in terms of one line, you don't actually have only one line of context. If the graphics system was 3D and used indices into external arrays, you would know, for example. > > Such issues are well-known, as are solutions - strong typing (possible > even in C, though the language doesn't have great support for it - a > struct parameter with compound literals and designated literals one > way), named parameters, chained function calls, etc. And of course, > clear and consistent API's with good declarations and documentation are key. > Languages that allow named parameters are nice, and if I was extending C I would introduce that. The problem is that there are a few basic mathematical functions like tan() which are conventionally written tan(value), and that was then used a model for what other functions would be like. However only a few user-written functions calculate similar basic mathematical functions. Generally it make sense to write payroll(employees=emp, Nemployees=N, taxcode=1234), not payroll(emp, N, 1234); > > Standard library functions are the most commonly called functions in C code, > > and are always named in my style. > No, they are not. Names with all lower case and no word separation are > common in the C standard library for short identifiers (like "strlen"), > while underscores are common for longer identifiers (like > "memory_order_relaxed"). > > It would be nice if you were to check this kind of thing before making > pointlessly incorrect claims. > Ok. So I checked. Every single function in the standard library is written in my style, with the exception of a handful which take an _r suffix (e.g. asctime_r). I think these are recent additions. It's always isdigit(). Never is_digit() or isDigit(). The difference between my style and theirs is that the standard library abbreviates more aggressively than I would. e.g. strrchr where as I would name the same function reversestringsearch. Thats because strrchr rapidly becomes familiar to anyone using C, whilst a function written by me would be unlikely to be used very widely except in the program it was written for. > Short names are useful for things that are used often. Longer and more > descriptive names are better for things that are used more rarely. > Either way, readability is the key - for common identifiers, brevity > improves reading speed, while for less common identifiers it is helpful > to be clearer and more explicit. For longer identifiers, underscores > are vital to readability (camel-case is fine in medium cases, but can be > a poor choice when the identifier consists of several words). > There's an element of truth in that. But the basic reality is that some identiifers naturally have short words associated with them (determinant, diagonalize, identity, etc), whilst for others there is strong convention (i, x, y, N, theta, ptr). For others, there is no single short English word which describes them and wouldn't be misleading. So it's "multiply matrix with vector", turned somehow into a valid identiifer. > > Consistency is a benefit, but it is not a priority - it does not trump > readability. > You can become obsessed with consistency, I agree. But sometimes you might reject a marginally better name because it's not consistent with the system you've developed for the rest of the program. > > If you are trying to say that trying to highlight everything results in > highlighting nothing, just write that. Or better - don't bother writing > it, because it is entirely obvious. > Its obviously true. When pointed out. But not `'entirely obvious". > Have you ever used a modern editor or IDE? Do you know what "syntax > highlighting" is? That applies different appearances to different parts > of the language syntax - everything is "highlighted", but it makes the > code easier to read. > That is actually true. Coloured code is easier to read than non-coloured. > > What? I'm sorry, but you really have very little idea of what you are > talking about. I am well aware of the wide range of statuses that could > apply to slaves in the classical Roman and Greek societies - with some > having significant status, their own slaves, their own property, etc. > Most scribes were /not/ high status slaves, and were certainly not privy > to the details of politics, diplomacy and other aspects of running the > societies. There were a few who were acted more as advisors and were of > higher status. But usually a good scribe was one who did not remember > or think about the things he wrote down - he was a dictation machine, > and perhaps also required to read aloud and track accounts. For many > uses, the less he understood about what was being written, the better. > He would have had a higher status than a modern clerical worker, because writing was a relatively rare skill, and of course associated with the upper classes. He wouldn't necessarily have been anything better than a secretary, of course. The idea that you could prevent a scribe from reading what he was writing down is ridiculous. Of course if there was a way of doing this, then the principals would probably have taken it. But if a Roman senator got his scribe to write down a letter of complaint to a magistrate, the scribe would be privy to the matter. Unavoidably. > > > But the spaces are not part of the Torah. They are regarded as man-made, not > > God-given. So there must have been an early tradition of text without spaces. > I think you have no basis for that conclusion - even if we assume, for > the sake of argument, that the letters were "God-given". The paper (or > other material) and ink are all man-made, but found in every scroll of > the Torah. > > As I understand it, Kabalists do not view spaces or punctuation as > significant when trying to find hidden patterns in the letters of the > Torah. But Hebrew texts were written with spaces - there is > (apparently) no good evidence of Hebrew being written without spaces. > > However, my knowledge of these things is all indirect - I don't know any > Hebrew, I only know a little about the language and its script. > Yes. What I am saying is that for the idea that the letters were God-given whilst the spaces were man-made to take root, the society must have been familiar with text written continuously.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-24 16:48 +0100 |
| Message-ID | <uc7u52$3h9f6$1@dont-email.me> |
| In reply to | #172716 |
On 24/08/2023 15:50, Malcolm McLean wrote:
> On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote:
>> On 24/08/2023 05:53, Malcolm McLean wrote:
>>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote:
>>>>
>>>>> No they are not. drawPath(mypath, false) conveys no information.
>>>> Nor does drawRectangle(100, 200, 300, 400).
>>>>
>>> The function obviously draws a rectangle. And those values are almost
>>> certainly pixel values. If they were rbg values they would go from 0-255,
>>> and a normal raster designed for human viewing will have pixel co-ordinates
>>> in that range.
>> Is it (x1, y1, x2, y2) ? (x, y, w, h) ? (row, column, height, width) ?
>> Is the y coordinate from the top down, or bottom up? Are we in
>> pixels, millimetres, points, or something else? Are we relative to a
>> window, or a screen, or an abstract desktop? Are we doing something
>> very different, such as using indices into arrays of 3-D points in a
>> scene definition?
>>
> We're not in millimeters probably, because the co-ordinates are integer
> values. (I know they could be real but just written as integers, and of course
> it's not physically impossible to build a device that draws on discrete millimetre
> values. But we're probably nor dealing with millimeters.) It could be points
> rather than pixels, fair enough (on our system, "pixel" is a bit of a fuzzy concept
> because the document can have several physical representations, and so
> we use points by default. But again, the points are reals.)
>
> Whilst we know that the function draws a rectangle, we don't know the details
> of the graphics system. But we do know that it caches colour at least, because
> the function takes four parameters to describe a rectangle.
>>
>> The point is, without context and more information (such as the
>> declaration of the function with parameter names, or a knowledge of its
>> use), you don't know enough to interpret the meaning of the parameters.
>> You can guess, but you could be wrong. This is exactly the same whether
>> it is a series of "int" parameters or some "bool" parameters, or other
>> generic types.
>>
> Yes, you can be wrong. But you've a pretty good idea what the call probably
> does, just from one line, and from an example chosen to illustrate the
> opposite point. And of course whilst I've spoken in terms of one line, you
> don't actually have only one line of context. If the graphics system was 3D
> and used indices into external arrays, you would know, for example.
>
>>
>> Such issues are well-known, as are solutions - strong typing (possible
>> even in C, though the language doesn't have great support for it - a
>> struct parameter with compound literals and designated literals one
>> way), named parameters, chained function calls, etc. And of course,
>> clear and consistent API's with good declarations and documentation are key.
>>
> Languages that allow named parameters are nice, and if I was extending C
> I would introduce that.
That would have been far more useful than designated initialisers, which
is the same class of feature.
With the latter, I've seen actual examples like this:
typedef struct {int x, y;} Point;
Point p = {.x = 100, .y = 200};
Point q = {.y = 200, .x = 100};
Without the feature, you would have to write:
Point p = {100, 200};
Point q = {100, 200};
Which for my example is clearer.
But I suppose people can go over the top with keyword parameters too,
and write strlen(.s = S).
I found keyword parameters were more useful when there are lots of
arguments, many optional. It needs to go hand-in-hand with default values.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-24 17:35 +0000 |
| Message-ID | <20230824100406.84@kylheku.com> |
| In reply to | #172717 |
On 2023-08-24, Bart <bc@freeuk.com> wrote:
> On 24/08/2023 15:50, Malcolm McLean wrote:
>> On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote:
>>> On 24/08/2023 05:53, Malcolm McLean wrote:
>>>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote:
>>>>>
>>>>>> No they are not. drawPath(mypath, false) conveys no information.
>>>>> Nor does drawRectangle(100, 200, 300, 400).
>>>>>
>>>> The function obviously draws a rectangle. And those values are almost
>>>> certainly pixel values. If they were rbg values they would go from 0-255,
>>>> and a normal raster designed for human viewing will have pixel co-ordinates
>>>> in that range.
>>> Is it (x1, y1, x2, y2) ? (x, y, w, h) ? (row, column, height, width) ?
>>> Is the y coordinate from the top down, or bottom up? Are we in
>>> pixels, millimetres, points, or something else? Are we relative to a
>>> window, or a screen, or an abstract desktop? Are we doing something
>>> very different, such as using indices into arrays of 3-D points in a
>>> scene definition?
>>>
>> We're not in millimeters probably, because the co-ordinates are integer
>> values. (I know they could be real but just written as integers, and of course
>> it's not physically impossible to build a device that draws on discrete millimetre
>> values. But we're probably nor dealing with millimeters.) It could be points
>> rather than pixels, fair enough (on our system, "pixel" is a bit of a fuzzy concept
>> because the document can have several physical representations, and so
>> we use points by default. But again, the points are reals.)
>>
>> Whilst we know that the function draws a rectangle, we don't know the details
>> of the graphics system. But we do know that it caches colour at least, because
>> the function takes four parameters to describe a rectangle.
>>>
>>> The point is, without context and more information (such as the
>>> declaration of the function with parameter names, or a knowledge of its
>>> use), you don't know enough to interpret the meaning of the parameters.
>>> You can guess, but you could be wrong. This is exactly the same whether
>>> it is a series of "int" parameters or some "bool" parameters, or other
>>> generic types.
>>>
>> Yes, you can be wrong. But you've a pretty good idea what the call probably
>> does, just from one line, and from an example chosen to illustrate the
>> opposite point. And of course whilst I've spoken in terms of one line, you
>> don't actually have only one line of context. If the graphics system was 3D
>> and used indices into external arrays, you would know, for example.
>>
>>>
>>> Such issues are well-known, as are solutions - strong typing (possible
>>> even in C, though the language doesn't have great support for it - a
>>> struct parameter with compound literals and designated literals one
>>> way), named parameters, chained function calls, etc. And of course,
>>> clear and consistent API's with good declarations and documentation are key.
>>>
>> Languages that allow named parameters are nice, and if I was extending C
>> I would introduce that.
>
> That would have been far more useful than designated initialisers, which
> is the same class of feature.
>
> With the latter, I've seen actual examples like this:
>
> typedef struct {int x, y;} Point;
>
> Point p = {.x = 100, .y = 200};
> Point q = {.y = 200, .x = 100};
>
> Without the feature, you would have to write:
>
> Point p = {100, 200};
> Point q = {100, 200};
>
> Which for my example is clearer.
Designated initializers allow you to do these:
int array[1000000] = { [999999] = 42 };
union u { int i; double d; } x = { .d = 3.0 };
other than that, they aren't very useful.
The problem is that they are like keyword parameters
which are all optional.
They do not address the following problem: you want to add an important
new member to a structure, such that everyone place which defines
aninstance of the structure has to initialize it to some nonzero/nonnull
value.
To address this problem, you reach for macros
#define init_Point(x, y) { x, y }
If we convert our system to 3D, we can change this:
#define init_Point(x, y, z) { x, y, z }
because macro arguments are all required, all places which pass
only two parameters are diagnosed for us.
Of course, we could use this with designated initializers:
#define init_Point(xi, yi) { .x = xi, .y = yi }
They are not providing much value here, because we only have
one initializer: the one in the macro. That initializer appears
close to the struct definition the same file and is easily
maintained together.
If the structure has some integrity checks, they will catch
most bad initialization mistakes:
struct big_complex_thing {
unsigned head_magic;
/* ... */
unsigned tail_magic;
};
#define big_complex_thing_init(foo, bar, ...) \
{ BIG_COMPLEX_HEAD_MAGIC, foo, bar , ..., BIG_COMPLEX_TAIL_MAGIC }
If a big_complex_thing object does not have the correct tail magic,
something is wrong between the initializer macro and struct
declaration. Or else someone is not using the macro, like they should.
--
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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-24 18:09 +0000 |
| Message-ID | <20230824103706.618@kylheku.com> |
| In reply to | #172719 |
On 2023-08-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote: > On 2023-08-24, Bart <bc@freeuk.com> wrote: [ large amount of quoted material ] Here I go again. Sorry about the large amount of quoted material.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 09:59 +0200 |
| Message-ID | <uc9n1r$3ubvm$1@dont-email.me> |
| In reply to | #172717 |
On 24/08/2023 17:48, Bart wrote:
> On 24/08/2023 15:50, Malcolm McLean wrote:
>> On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote:
>>> On 24/08/2023 05:53, Malcolm McLean wrote:
>>>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote:
>>>>>
>>>>>> No they are not. drawPath(mypath, false) conveys no information.
>>>>> Nor does drawRectangle(100, 200, 300, 400).
>>>>>
>>>> The function obviously draws a rectangle. And those values are almost
>>>> certainly pixel values. If they were rbg values they would go from
>>>> 0-255,
>>>> and a normal raster designed for human viewing will have pixel
>>>> co-ordinates
>>>> in that range.
>>> Is it (x1, y1, x2, y2) ? (x, y, w, h) ? (row, column, height, width) ?
>>> Is the y coordinate from the top down, or bottom up? Are we in
>>> pixels, millimetres, points, or something else? Are we relative to a
>>> window, or a screen, or an abstract desktop? Are we doing something
>>> very different, such as using indices into arrays of 3-D points in a
>>> scene definition?
>>>
>> We're not in millimeters probably, because the co-ordinates are integer
>> values. (I know they could be real but just written as integers, and
>> of course
>> it's not physically impossible to build a device that draws on
>> discrete millimetre
>> values. But we're probably nor dealing with millimeters.) It could be
>> points
>> rather than pixels, fair enough (on our system, "pixel" is a bit of a
>> fuzzy concept
>> because the document can have several physical representations, and so
>> we use points by default. But again, the points are reals.)
>>
>> Whilst we know that the function draws a rectangle, we don't know the
>> details
>> of the graphics system. But we do know that it caches colour at least,
>> because
>> the function takes four parameters to describe a rectangle.
>>>
>>> The point is, without context and more information (such as the
>>> declaration of the function with parameter names, or a knowledge of its
>>> use), you don't know enough to interpret the meaning of the parameters.
>>> You can guess, but you could be wrong. This is exactly the same whether
>>> it is a series of "int" parameters or some "bool" parameters, or other
>>> generic types.
>>>
>> Yes, you can be wrong. But you've a pretty good idea what the call
>> probably
>> does, just from one line, and from an example chosen to illustrate the
>> opposite point. And of course whilst I've spoken in terms of one line,
>> you
>> don't actually have only one line of context. If the graphics system
>> was 3D
>> and used indices into external arrays, you would know, for example.
>>
>>>
>>> Such issues are well-known, as are solutions - strong typing (possible
>>> even in C, though the language doesn't have great support for it - a
>>> struct parameter with compound literals and designated literals one
>>> way), named parameters, chained function calls, etc. And of course,
>>> clear and consistent API's with good declarations and documentation
>>> are key.
>>>
>> Languages that allow named parameters are nice, and if I was extending C
>> I would introduce that.
>
> That would have been far more useful than designated initialisers, which
> is the same class of feature.
>
> With the latter, I've seen actual examples like this:
>
> typedef struct {int x, y;} Point;
>
> Point p = {.x = 100, .y = 200};
> Point q = {.y = 200, .x = 100};
>
Re-ordering like that is not often done in real code, but it is
certainly legal in C - and I agree it leads to unclear code.
> Without the feature, you would have to write:
>
> Point p = {100, 200};
> Point q = {100, 200};
>
> Which for my example is clearer.
Agreed, in this case. But arguably it is even better to write :
Point p = {.x = 100, .y = 200};
Point q = {.x = 100, .y = 200};
Using designated initialisers, but without jumbling the order, gives the
clearest result. (Of course in the case of a Point, the x, y ordering
is so ingrained that the identifiers are not really helpful.)
>
> But I suppose people can go over the top with keyword parameters too,
> and write strlen(.s = S).
>
> I found keyword parameters were more useful when there are lots of
> arguments, many optional. It needs to go hand-in-hand with default values.
Agreed.
One of the objections people have to trying to add named parameters to C
or C++ is they feel it will encourage people to make functions with too
many parameters, which is generally a bad idea anyway. I think that
objection is silly - sometimes people write functions with lots of
parameters, for good reasons or bad reasons, and it would be nice to
make such cases easier to read and easier to get correct (and harder to
get wrong).
In C, you can write something like this :
int foo(int a, int b, int c);
int test_foo(int a, int b, int c) {
return foo(a, b , c);
}
typedef struct { int a; int b; int c; } bar_params;
int bar(bar_params p);
int test_bar(int a, int b, int c) {
return bar((bar_params) { .a = a, .b = b, .c = c });
}
int test_bar2(int a, int c) {
return bar((bar_params) { .c = c, .a = a });
}
This gives you something akin to named parameters (and any parameters
you omit will default to 0). But it's ugly to write, and can be
significantly less efficient for the function call. (Usually if you've
got a function with lots of parameters, the function itself will be big,
so the call overhead is unlikely to matter in practice.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 09:46 +0200 |
| Message-ID | <uc9m7v$3u797$1@dont-email.me> |
| In reply to | #172716 |
On 24/08/2023 16:50, Malcolm McLean wrote: > On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote: >> On 24/08/2023 05:53, Malcolm McLean wrote: >>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote: >>>> > We're not in millimeters probably, because the co-ordinates are integer <snip> The discussion was not about trying to guess what these parameters might have been - it was to demonstrate that you don't know what parameters like that are just by looking at the call. You might be able to make some guesses or inferences, but in general you need to know more about the function declaration, specification, API, documentation, etc. And that applies to all kinds of parameter types - bool types are in no way special. You have agreed with me here, so let's leave that and move on. > >> >> Such issues are well-known, as are solutions - strong typing (possible >> even in C, though the language doesn't have great support for it - a >> struct parameter with compound literals and designated literals one >> way), named parameters, chained function calls, etc. And of course, >> clear and consistent API's with good declarations and documentation are key. >> > Languages that allow named parameters are nice, and if I was extending C > I would introduce that. The problem is that there are a few basic mathematical > functions like tan() which are conventionally written tan(value), and that was > then used a model for what other functions would be like. However only a few > user-written functions calculate similar basic mathematical functions. > Generally it make sense to write payroll(employees=emp, Nemployees=N, > taxcode=1234), not payroll(emp, N, 1234); There are good historical reasons for why named parameters are not common in older languages, but are more common in newer ones. And there are good technical reasons why they would be difficult to introduce to C as an afterthought. But I agree with you that they can be helpful and improve code readability, in languages that support them. > >>> Standard library functions are the most commonly called functions in C code, >>> and are always named in my style. >> No, they are not. Names with all lower case and no word separation are >> common in the C standard library for short identifiers (like "strlen"), >> while underscores are common for longer identifiers (like >> "memory_order_relaxed"). >> >> It would be nice if you were to check this kind of thing before making >> pointlessly incorrect claims. >> > Ok. So I checked. Every single function in the standard library is written in > my style, with the exception of a handful which take an _r suffix (e.g. asctime_r). > I think these are recent additions. I am looking at Annex B of the C standards. There are lots of short identifiers without word breaks, as I said - such as "isdigit". This is especially true of older function names, which come from a background of the days of assemblers and linkers with very limited characters and identifier lengths. This is part of the reason for some abbreviations being shorter than you (or I) might have liked. (We should be grateful that they use small letters and not all-caps!) There are maybe a dozen at most that have more than 10 characters, such as "isgreaterequal". Once you get to longer names, they are split with underscore - it is "atomic_flag_clear_explicit", not "atomicflagclearexplicit", which would be illegible. The type identifiers have underscores, the macros for limits, atomic memory access types, file IO constants - all have underscores. They are all over the place! No, you have /not/ checked - unless you think I was talking about K&R C and restricting identifiers to function names only. And the clear pattern of underscores being more common in newer identifiers should be a clue to you - just as the world moved on and embraced word divisions in Latin prose, so the programming world moved on and embraced word divisions in identifier names. We no longer restrict our filenames to 8.3 patterns - we no longer write highly condensed identifiers without word divisions. > It's always isdigit(). Never is_digit() or isDigit(). > The difference between my style and theirs is that the standard library abbreviates > more aggressively than I would. e.g. strrchr where as I would name the same > function reversestringsearch. Thats because strrchr rapidly becomes familiar > to anyone using C, whilst a function written by me would be unlikely to be used > very widely except in the program it was written for. > >> Short names are useful for things that are used often. Longer and more >> descriptive names are better for things that are used more rarely. >> Either way, readability is the key - for common identifiers, brevity >> improves reading speed, while for less common identifiers it is helpful >> to be clearer and more explicit. For longer identifiers, underscores >> are vital to readability (camel-case is fine in medium cases, but can be >> a poor choice when the identifier consists of several words). >> > There's an element of truth in that. More than an element. > But the basic reality is that some identiifers > naturally have short words associated with them (determinant, diagonalize, > identity, etc), whilst for others there is strong convention (i, x, y, N, theta, > ptr). For others, there is no single short English word which describes them > and wouldn't be misleading. So it's "multiply matrix with vector", turned somehow > into a valid identiifer. That's all true enough, and in no way contradicts what I said. If "det" is clear in the context (such as a local variable in a function that works with matrices), then use "det". If you need "multiply matrix with vector" to be clear (perhaps its a rarely-used global function), call it "multiply_matrix_with_vector". The only thing /wrong/ - and pretty much everyone thinks it is wrong - would be to call it "multiplymatrixwithvector". >> >> Consistency is a benefit, but it is not a priority - it does not trump >> readability. >> > You can become obsessed with consistency, I agree. But sometimes you > might reject a marginally better name because it's not consistent with > the system you've developed for the rest of the program. Think of it as an optimisation problem - different characteristics are given different weights, and your job as programmer is to pick the identifier that gives the best total outcome. Consistency has weight 1, readability has weight 10. >>> But the spaces are not part of the Torah. They are regarded as man-made, not >>> God-given. So there must have been an early tradition of text without spaces. >> I think you have no basis for that conclusion - even if we assume, for >> the sake of argument, that the letters were "God-given". The paper (or >> other material) and ink are all man-made, but found in every scroll of >> the Torah. >> >> As I understand it, Kabalists do not view spaces or punctuation as >> significant when trying to find hidden patterns in the letters of the >> Torah. But Hebrew texts were written with spaces - there is >> (apparently) no good evidence of Hebrew being written without spaces. >> >> However, my knowledge of these things is all indirect - I don't know any >> Hebrew, I only know a little about the language and its script. >> > Yes. What I am saying is that for the idea that the letters were God-given > whilst the spaces were man-made to take root, the society must have been > familiar with text written continuously. > No - again, you have no basis for that conclusion. And you could equally logically have concluded that society must have been familiar with text written without letters, only with spaces. When the same logic can be used to "prove" something that silly, you should be suspicious of your arguments. I think part of your confusion comes from your idea that the Torah is a written work, and that written works consist of letters and spaces. This is wrong on both accounts. First, the Torah is a spoken work. It was spoken long before it was written down. Rabbis memorize it - they read the scrolls as a memory aid. The letters of the Torah come from the spoken word, and spoken word does not have space characters. Kabbalah comes from the oral tradition, not the written version of the Torah (though it moved and adapted to the written work). Secondly, the writing consists of putting the letters down on the page. Spacing is like the manuscript material and ink, or the script - it is not the text, but it is other things needed to make the text legible. Indeed, spacing is "lower" than the paper and ink, because it consists of nothing at all. You do not need to have read texts with no nothingness in order to think that added nothingness is not of mystical importance. There are not aspects of the Torah scrolls divided into "God-given" and "man-made" - that is a false dichotomy. There is the "God-given" words and letters, and who cares about any of the rest of it?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 01:37 -0700 |
| Message-ID | <d3c6df71-7ef5-4fd3-83be-8b9a4315f0c4n@googlegroups.com> |
| In reply to | #172738 |
On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote: > On 24/08/2023 16:50, Malcolm McLean wrote: > > On Thursday, 24 August 2023 at 14:15:21 UTC+1, David Brown wrote: > >> On 24/08/2023 05:53, Malcolm McLean wrote: > >>> On Wednesday, 23 August 2023 at 20:29:07 UTC+1, David Brown wrote: > >>>> > > > > We're not in millimeters probably, because the co-ordinates are integer > <snip> > > The discussion was not about trying to guess what these parameters might > have been - it was to demonstrate that you don't know what parameters > like that are just by looking at the call. You might be able to make > some guesses or inferences, but in general you need to know more about > the function declaration, specification, API, documentation, etc. And > that applies to all kinds of parameter types - bool types are in no way > special. You have agreed with me here, so let's leave that and move on. > Ah but you do. As long as by "know" we mean "know beyond reasonable doubt". Of course someone could write a function called "drawRectangle" to draw, i.e. remove a rectangle from a scene. But the chance of that is so low that it can be dismissed. In this case, there were two possibilities, either an x,y width,height system or a top left, bottom right system. An dthe co-ordinates were almost certianly pixel values because they were integers, and because of their magnitude. However there was no colour, so the sytsem obviously has state. And therefore the co-ordinates might be transformed. You can tell all that, just by looking at one line, with no other context. Because the parameters are scalars, therefore they either have names or they have values, and you can draw reasonable conclusions from that. > > There are good historical reasons for why named parameters are not > common in older languages, but are more common in newer ones. And there > are good technical reasons why they would be difficult to introduce to C > as an afterthought. But I agree with you that they can be helpful and > improve code readability, in languages that support them. > I don't really see what the technical problem is. The header would have to contain the names of the parameters (most do already). Then instead of putting parameter 1 into register a and parameter 2 into register b, the compiler matches them up. If its void foo(int x, int y) and the call is foo(y=1, x=2), then the compiler puts a 2 into register a and a 1 into register b. I haven't tried to modify a compiler to do this so there might be something I haven't thought of. But it would be a fairly simple, contained change with no implications for the linker. > >>> Standard library functions are the most commonly called functions in C code, > >>> and are always named in my style. > >> No, they are not. Names with all lower case and no word separation are > >> common in the C standard library for short identifiers (like "strlen"), > >> while underscores are common for longer identifiers (like > >> "memory_order_relaxed"). > >> > >> It would be nice if you were to check this kind of thing before making > >> pointlessly incorrect claims. > >> > > Ok. So I checked. Every single function in the standard library is written in > > my style, with the exception of a handful which take an _r suffix (e.g. asctime_r). > > I think these are recent additions. > I am looking at Annex B of the C standards. There are lots of short > identifiers without word breaks, as I said - such as "isdigit". This is > especially true of older function names, which come from a background of > the days of assemblers and linkers with very limited characters and > identifier lengths. This is part of the reason for some abbreviations > being shorter than you (or I) might have liked. (We should be grateful > that they use small letters and not all-caps!) There are maybe a dozen > at most that have more than 10 characters, such as "isgreaterequal". > > Once you get to longer names, they are split with underscore - it is > "atomic_flag_clear_explicit", not "atomicflagclearexplicit", which would > be illegible. The type identifiers have underscores, the macros for > limits, atomic memory access types, file IO constants - all have > underscores. They are all over the place! > > No, you have /not/ checked - unless you think I was talking about K&R C > and restricting identifiers to function names only. > I said every function. You were talking about identifiers. Of course size_t has an underscore. Everyone knows that. And most people agree that it is horrible. And it wasn't part of C as orginally designed. > > And the clear pattern of underscores being more common in newer > identifiers should be a clue to you - just as the world moved on and > embraced word divisions in Latin prose, so the programming world moved > on and embraced word divisions in identifier names. We no longer > restrict our filenames to 8.3 patterns - we no longer write highly > condensed identifiers without word divisions. > Ritchie was a genius who knew how to design a programming language. The people who came after him were lesser men. > > > There's an element of truth in that. > More than an element. You choose names which describe the thing you are naming. Primarily. And that description might be a short English word, a long English word, or a short English phrase. That bears no relation to whether the identiifer is used a lot or used relatively infrequently. But the element of truth is that, if an indentifier is used frequently, you can get away with a short English word which, outside of context, would be ambiguous. So there is an element of truth in what you say. > > The only thing /wrong/ - and pretty much everyone thinks it is wrong - > would be to call it "multiplymatrixwithvector". > Well Caesar disagreed. Denis Ritchie disagreed. Unfortunately I can't find it, but some reasearch on human-readable urls disagreed. Whilst all you can offer is "I disagree". But you automatically disagree with things some people say. So how much weight should we give to that? > > Think of it as an optimisation problem - different characteristics are > given different weights, and your job as programmer is to pick the > identifier that gives the best total outcome. Consistency has weight 1, > readability has weight 10. > Cnsistency aids readability. Readbility of a single identifier aids readability of that identifier, but may damage the readability of the text as a whole, largely because it breaks consistency. But consistency isn't an absolute, I agree there. > > > Yes. What I am saying is that for the idea that the letters were God-given > > whilst the spaces were man-made to take root, the society must have been > > familiar with text written continuously. > > > No - again, you have no basis for that conclusion. > > And you could equally logically have concluded that society must have > been familiar with text written without letters, only with spaces. When > the same logic can be used to "prove" something that silly, you should > be suspicious of your arguments. > Are you advancing an objection that weak? > > I think part of your confusion comes from your idea that the Torah is a > written work, and that written works consist of letters and spaces. > This is wrong on both accounts. > > First, the Torah is a spoken work. It was spoken long before it was > written down. Rabbis memorize it - they read the scrolls as a memory > aid. The letters of the Torah come from the spoken word, and spoken > word does not have space characters. Kabbalah comes from the oral > tradition, not the written version of the Torah (though it moved and > adapted to the written work). > What was important to the Jews was that it was written. God's word, written down. Of course modern scholars are sceptical of that. But Jews themselves didn't believe that Torah had come about by a process of redaction by scribes working from oral tradtions in Babylon. > > Secondly, the writing consists of putting the letters down on the page. > Spacing is like the manuscript material and ink, or the script - it is > not the text, but it is other things needed to make the text legible. > Indeed, spacing is "lower" than the paper and ink, because it consists > of nothing at all. > > You do not need to have read texts with no nothingness in order to think > that added nothingness is not of mystical importance. There are not > aspects of the Torah scrolls divided into "God-given" and "man-made" - > that is a false dichotomy. There is the "God-given" words and letters, > and who cares about any of the rest of it? > The letters are given by God, the spaces added by man. So yes, there is a distinction. It doesn't matter much, but it does matter. As you yourself pointed out, when searching for "Torah codes" the spaces are excluded. Since they were not given by God, a similar search which included spaces would be invalid.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-25 08:50 +0000 |
| Message-ID | <j=2ifExxFfXU05g0F@bongo-ra.co> |
| In reply to | #172742 |
On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Of course size_t has an underscore. Everyone knows that. And most people > agree that it is horrible. "Most people" meaning you made it up.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-25 01:53 -0700 |
| Message-ID | <ae3d2d4e-71bd-4c6c-99aa-cf8b6b652175n@googlegroups.com> |
| In reply to | #172743 |
On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: > On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) > Malcolm McLean <malcolm.ar...@gmail.com> wrote: > > Of course size_t has an underscore. Everyone knows that. And most people > > agree that it is horrible. > "Most people" meaning you made it up. > We could do a straw poll. How many people like the underscore in size_t and how many think it is horrible? There are some people who think that the comittee can do no wrong, so it won't be unanimous. But I think I know where the majority will be.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-25 09:17 +0000 |
| Subject | Underscores in type names (was : C vs Haskell for XML parsing) |
| Message-ID | <BltvTW49qZtb8Sjsd@bongo-ra.co> |
| In reply to | #172744 |
On Fri, 25 Aug 2023 01:53:57 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: > > On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) > > Malcolm McLean <malcolm.ar...@gmail.com> wrote: > > > Of course size_t has an underscore. Everyone knows that. And most people > > > agree that it is horrible. > > "Most people" meaning you made it up. > > > We could do a straw poll. > How many people like the underscore in size_t and how many think it is horrible? I like it. sizetype would also have been reasonable but not sizet which would be mystifying. Note that the POSIX standard also uses the same template for naming types like off_t or pid_t . > There are some people who think that the comittee can do no wrong, Can you name one who thinks so ? > so it > won't be unanimous. But I think I know where the majority will be.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-08-25 11:35 +0100 |
| Subject | Re: Underscores in type names (was : C vs Haskell for XML parsing) |
| Message-ID | <uca05k$328$1@dont-email.me> |
| In reply to | #172745 |
On 25/08/2023 10:17, Spiros Bousbouras wrote: > On Fri, 25 Aug 2023 01:53:57 -0700 (PDT) > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >>> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>>> Of course size_t has an underscore. Everyone knows that. And most people >>>> agree that it is horrible. >>> "Most people" meaning you made it up. >>> >> We could do a straw poll. >> How many people like the underscore in size_t and how many think it is horrible? > > I like it. sizetype would also have been reasonable but not sizet which > would be mystifying. Note that the POSIX standard also uses the same template > for naming types like off_t or pid_t . 'size' has to be a common variable name, sizet is horrid, so size_t for the typedef is pretty much required. > >> There are some people who think that the comittee can do no wrong, > > Can you name one who thinks so ? > >> so it >> won't be unanimous. But I think I know where the majority will be. I like '_t's for typedefs, I don't like '_s's for structs (for _u for unions, _e for enums)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 13:42 +0200 |
| Message-ID | <uca43t$p9c$2@dont-email.me> |
| In reply to | #172744 |
On 25/08/2023 10:53, Malcolm McLean wrote: > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >>> Of course size_t has an underscore. Everyone knows that. And most people >>> agree that it is horrible. >> "Most people" meaning you made it up. >> > We could do a straw poll. > How many people like the underscore in size_t and how many think it is horrible? Here's another straw poll - how many people here kick their dogs, and how many have stopped kicking their dogs? Do you know the concept of a "false dichotomy" ? Do you understand that there could be just a fraction of a percent of programmers who like the underscore in size_t, and you would /still/ be wrong about the majority thinking it is horrible? > There are some people who think that the comittee can do no wrong, so it > won't be unanimous. But I think I know where the majority will be. I think you are wrong. I think you will find that the majority of people don't care. The type is called "size_t", so they write "size_t", without any significant like or dislike.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-25 13:59 +0000 |
| Message-ID | <dt2GM.463339$U3w1.15215@fx09.iad> |
| In reply to | #172744 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote: >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT) >> Malcolm McLean <malcolm.ar...@gmail.com> wrote: >> > Of course size_t has an underscore. Everyone knows that. And most people >> > agree that it is horrible. >> "Most people" meaning you made it up. >> >We could do a straw poll. >How many people like the underscore in size_t and how many think it is horrible? I've never heard anyone but you complain about it. Certainly the dozen or so people that participate in this thread are hardly a representative sample. I'd wager that most C programmers don't even think about it, much less care.
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web