Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-28 02:27 -0400 |
| Articles | 20 on this page of 638 — 29 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 20:53 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:47 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:48 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:48 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 12:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:09 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:34 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:13 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:52 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:16 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 20:47 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 22:38 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:28 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:05 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 18:31 +0200
Re: Taming The Switch-Statement Bob Duff <invalid@invalid.com> - 2026-10-19 19:38 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 17:03 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:45 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 05:01 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 00:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:34 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:18 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-18 23:51 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:56 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 19:37 -0700
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:13 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:17 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:56 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:15 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:33 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-19 08:47 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 18:28 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 22:11 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 16:11 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:02 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:18 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 02:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 12:22 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-19 23:41 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:18 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:27 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:38 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 19:25 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 00:16 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 16:10 -0700
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:39 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 02:49 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:07 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 11:20 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:29 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 16:40 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 23:33 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 00:01 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 17:05 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 12:45 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 13:21 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 11:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:21 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 15:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:36 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 15:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 17:22 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 17:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 19:04 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:36 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:36 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 23:10 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 22:55 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 17:19 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 19:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:56 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 19:24 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:30 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 21:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 23:43 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 00:56 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:55 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-21 07:22 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 01:56 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:10 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:17 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 13:22 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:29 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:43 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-21 13:02 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 08:57 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-22 12:56 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 17:00 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 16:54 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 21:09 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-22 12:46 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-23 09:37 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 14:21 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-23 22:40 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 18:33 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-24 22:26 +0000
Modelling self/this? (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-25 00:56 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-24 16:38 -0700
Re: Taming The Switch-Statement steve g <Sgonedes1977@gmail.com> - 2026-10-28 01:13 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 22:33 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-24 12:58 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-24 21:42 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-25 10:51 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-25 13:54 -0700
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-25 20:30 +0000
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Blaine <cactus_DAC@yahoo.com> - 2026-10-26 10:28 -0600
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:26 -0400
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 15:50 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Blaine <cactus_DAC@yahoo.com> - 2026-10-28 10:34 -0600
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:25 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:35 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:40 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-22 16:42 -0700
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-22 18:38 -0600
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-23 04:23 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-23 01:09 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:23 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:28 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 11:02 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-11-01 12:09 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 02:50 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-21 11:19 +0200
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-21 09:29 -0600
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-22 00:33 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 09:51 +0200
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:07 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 12:11 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:20 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 14:16 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:03 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:32 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:42 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-26 19:39 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:03 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-28 05:56 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:06 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:21 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-28 14:24 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 15:52 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:45 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 17:00 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:06 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:11 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:03 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:39 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:59 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:13 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 20:56 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:40 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:46 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 11:51 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:18 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 21:49 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:23 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:25 -0700
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-27 22:39 +0000
Re: Taming The Switch-Statement Dan Purgert <dan@djph.net> - 2026-10-27 22:44 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-27 23:00 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 16:33 -0700
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-27 20:06 -0600
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:21 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 16:00 +0100
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-28 10:35 -0600
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 11:59 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 23:25 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:28 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:32 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 22:16 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:08 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 08:31 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 09:13 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 09:24 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-28 11:09 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:10 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-28 09:04 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:25 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 00:39 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 08:23 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 12:02 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 23:31 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-11-05 06:39 -0800
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-11-06 12:26 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-11-06 19:47 -0800
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:51 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:32 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:47 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:11 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:17 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:50 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-26 23:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:01 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:28 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:55 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 09:50 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 01:12 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:43 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 09:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 11:51 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 12:57 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:10 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 12:14 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:22 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:30 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:48 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-27 13:54 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:19 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:20 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:24 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:36 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 17:13 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 18:45 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-27 18:16 +0000
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 19:21 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 20:42 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:16 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 21:36 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:53 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:05 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-30 11:16 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:43 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:55 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 15:01 -0700
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:30 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:38 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:41 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 12:31 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-31 10:54 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 08:27 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-30 11:47 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 11:39 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 12:21 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 14:30 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 13:38 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 18:14 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 13:27 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-30 15:36 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-30 12:04 -0700
Python is the universal language (Was: BizFuss (was Re: Taming The Switch-Statement)) gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-30 20:10 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 11:36 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-28 05:33 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:45 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-29 07:34 -0700
Re: Taming The Switch-Statement steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:27 -0400
Page 17 of 32 — ← Prev page 1 … 15 16 [17] 18 19 … 32 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-17 21:40 +0100 |
| Message-ID | <11b0mfv$j5ll$1@dont-email.me> |
| In reply to | #403245 |
On 17/10/2026 18:58, Dan Cross wrote: > In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> On 17/10/2026 04:19, Dan Cross wrote: >>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> Those are considered more productive. >>> >>> ...and you think that's because of the syntax, and not the high >>> level nature of those languages? >> >> It's a combination. > > Riiiight. So greatly simplifying syntax, all other things being equal, does not increase productivity at all? Gotcha. > Yes. C's declaration syntax is famously abstruse; film at 11. And ... that's it? Just accept it? How about doing something about it! I'm angry because to me C was so unusable that I had to create and maintain my own products over decades. Then I later found that C had insinuated itself into every API and every open source product I wanted to use. Even ABIs, supposedly language-neutral, pay deference to it. Even as a compiler target, there was no other choice. So I ended having to deal with it anyway, but thankfully avoided have to write it. >> If C had used LTR type syntax and somebody >> proposed using inside-out back-and-forth syntax like 'void(*)(void)', >> they'd think they were having a laugh, as it would be ridiculous. > > Unknowable. You do know; you just don't want to admit it. (Imagine introducing C declarations into a current language.) > Then your point is minor at best. Here's a thought experiment: > suppose I suddenly came to my senses and agreed with everything > you say: I'm willing to totally toss out C and adopt Bart's > language yesterday. THIS IS NOT ABOUT MY LANGUAGE! Why hasn't there long been an alternative systems language that didn't have C's crazy syntax and stupid quirks? I mean like 30-50 years ago. Yes, mine has lots of examples of how some alternative features could work; so what? I am not selling my language. > Where do I get a compiler? What learning > resources exist? Oh, and I need it to generate code for an > ARM Cortex-M0 part; does it do that? I also need RV64GC and > x86_64 and probably aarch64, too. Might want to throw in > Xtensa while we're at it: does your compiler do all of that? > What if I need a debugger? Oh, and I need to use crypto > libraries that are supplied from a vendor; they use the C ABI. > What's the inter-op story like? My language was for in-house use; it was never intended as a product. (If you really want to try it, I can supply an ASM file for you to build, but it works on Windows. I can no longer supply a transpiled C version that part work on Linux; I have destroyed my C-related projects.) The C API (not ABI) point is valid, and another bugbear. Why can't APIs be expressed in a language-agnostic manner? This would help other languages that also need to solve the problem of creating bindings to libraries that primarily use a C API. C is a terrible choice for a cross-language API, as too many C-isms creep in (like C macros, or vaguely defined types, including the famous 'plain char' that exists in no other language, which is neither signed nor unsigned, and above all C preprocessor features). > Good for you. Totally irrelevant to the history of C. It means that meagre hardware resources don't have to compromise the design of a language, especially when it comes to syntax. So you can't use limited resources as an excuse for its questionable choices. Actually some choices actually made it harder to parse.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 14:32 +0200 |
| Message-ID | <11b2e9r$14ag7$1@dont-email.me> |
| In reply to | #403248 |
On 17/10/2026 22:40, bart wrote: > On 17/10/2026 18:58, Dan Cross wrote: >> In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 17/10/2026 04:19, Dan Cross wrote: >>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> >>>> wrote: >> Yes. C's declaration syntax is famously abstruse; film at 11. I'm not sure it is. It is different from what you find in some other languages, and it is certainly possible to write declarations in C that are hard to comprehend. But it is possible to do that in any programming language, and equally you can write clear declarations in C. It is very rare that I have to think about the syntax of declarations when I write C code, or when I read C code - maybe that's just my own experience, but it is simply not an issue for me. Mind you, I don't write code with the rubbish that you bring up as "examples" - maybe my experience is different from that of other people. > > And ... that's it? Just accept it? How about doing something about it! > What, exactly, do you think any of us should do about it? Let's hear a clear, realistic, concrete plan for how people here, the readers of comp.lang.c, can go about changing the syntax for C declarations. Note that continually posting complaints to people who did not design the C language, do not implement C compilers, and are not part of the C standards committee, is not a realistic or concrete plan for change. Nor is continually badgering people to "admit" that C is a terrible language.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-19 01:19 +0000 |
| Message-ID | <11b3r71$6me$1@reader2.panix.com> |
| In reply to | #403248 |
In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 17/10/2026 18:58, Dan Cross wrote:
>> In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>> On 17/10/2026 04:19, Dan Cross wrote:
>>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>>> Those are considered more productive.
>>>>
>>>> ...and you think that's because of the syntax, and not the high
>>>> level nature of those languages?
>>>
>>> It's a combination.
>>
>> Riiiight.
>
>So greatly simplifying syntax, all other things being equal, does not
>increase productivity at all? Gotcha.
Logical fallacy. I didn't say it did not; I said the languages
you pointed out as being "more productive" than C had other
attributes that make them more productive that you ignored in
your fervor to focus solely on syntax.
I see that you convenient snipped out my comment about C++,
which is the direct counter example. C++ shares much syntax
with C, but also has attributes that make it (generally) more
productive than C; for example, a broad standard library of
generic types and a useful `std::string` type.
Go and Rust both similarly share lots of syntactic elements with
C, yet both are also broadly more "productive".
>> Yes. C's declaration syntax is famously abstruse; film at 11.
>
>And ... that's it? Just accept it? How about doing something about it!
One time, shortly before I deployed to Afghanistan, my (then)
girlfriend and I were sleeping in my apartment in the far
northern reaches of Manhattan when a very (VERY) loud party
started blaring music outside; it was about 1am, and it woke us
both up. "Well, aren't you going to _do_ something about it?"
she asked me, to which I replied, "what, exactly, would you like
me to do?"
I survived that deployment, but the relationship did not.
>I'm angry because to me C was so unusable that I had to create and
>maintain my own products over decades.
"Had" is a strong word; dare I say it...a subjective word.
In fact, there have been all kinds of alternatives for years.
In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU,
BLISS, and so on. You yourself admit you started from Algol68.
By the late 1980s you had Oberon, decent versions of ML, C++
and Objective-C, etc; by the 1990s, there were more than you
could shake a stick at. Now? Take your pick.
You never "had" to use your own language.
>Then I later found that C had insinuated itself into every API and every
>open source product I wanted to use. Even ABIs, supposedly
>language-neutral, pay deference to it. Even as a compiler target, there
>was no other choice.
>
>So I ended having to deal with it anyway, but thankfully avoided have to
>write it.
See my earlier post. That ecosystem is one of the things that
makes C _useful_. /eyeroll
>>> If C had used LTR type syntax and somebody
>>> proposed using inside-out back-and-forth syntax like 'void(*)(void)',
>>> they'd think they were having a laugh, as it would be ridiculous.
>>
>> Unknowable.
>
>You do know; you just don't want to admit it. (Imagine introducing C
>declarations into a current language.)
No, really; C's declaration syntax was inspired by FORTRAN, and
generations of scientists and engineers have managed that
language just fine. Generations of programmers have handled C's
all right as well.
>> Then your point is minor at best. Here's a thought experiment:
>> suppose I suddenly came to my senses and agreed with everything
>> you say: I'm willing to totally toss out C and adopt Bart's
>> language yesterday.
>
>THIS IS NOT ABOUT MY LANGUAGE!
Then why do you keep bringing your language up, showing snippets
of its syntax, and so on?
>Why hasn't there long been an alternative systems language that didn't
>have C's crazy syntax and stupid quirks? I mean like 30-50 years ago.
There...have been? And still are?
>Yes, mine has lots of examples of how some alternative features could
>work; so what? I am not selling my language.
Oh good, so you'll stop bringing it up?
>> Where do I get a compiler? What learning
>> resources exist? Oh, and I need it to generate code for an
>> ARM Cortex-M0 part; does it do that? I also need RV64GC and
>> x86_64 and probably aarch64, too. Might want to throw in
>> Xtensa while we're at it: does your compiler do all of that?
>> What if I need a debugger? Oh, and I need to use crypto
>> libraries that are supplied from a vendor; they use the C ABI.
>> What's the inter-op story like?
>
>My language was for in-house use; it was never intended as a product.
>
>(If you really want to try it, I can supply an ASM file for you to
>build, but it works on Windows. I can no longer supply a transpiled C
>version that part work on Linux;
Not really, no. I don't do Windows, and I have no desire to
waste my time mucking about with random assembler to get it to
run on something I do have.
But this sort of thing is exactly what I'm talking about: your
language is not useful beyond a userbase of one. You solved a
set of "problems" that you defined for yourself, whether they
were real or not, and now are now sitting here trying to use
that as evidence about a general argument based on false
premises ("there was no alternative! I _had_ to do my own
thing!" "Oh, can I look at it?" "Oh, no; it only works for me,
on my laptop." "....").
>I have destroyed my C-related projects.)
Uh, ok.
>The C API (not ABI) point is valid, and another bugbear. Why can't APIs
>be expressed in a language-agnostic manner? This would help other
>languages that also need to solve the problem of creating bindings to
>libraries that primarily use a C API.
In fact, there have been efforts to do this for _years_. From
heavy weight IDLs and ORBs to wrappers like `swig`, and all of
the languages that used common ABIs (like the VAX Calling
Standard). They all suffer from one of two primary categories
of problems: a) either the mechanisms are too heavyweight or
cumbersome for easy use, or b) the semantics of languages vary
far too much between languages, so even if you can do something
simple like define compatible data types, language A may not be
able to meet all the constraints imposed by language B.
>C is a terrible choice for a cross-language API, as too many C-isms
>creep in (like C macros, or vaguely defined types, including the famous
>'plain char' that exists in no other language, which is neither signed
>nor unsigned, and above all C preprocessor features).
That's why ABIs matter.
Look at the Vax-11 Procedure Calling and Condition Handling
Standard from VMS 2.0; they simply wrote down what this stuff
meant, and you could call between essentially any language on
that system, whether it was C, Fortran, Bliss, COBOL, or
whatever.
>> Good for you. Totally irrelevant to the history of C.
>
>It means that meagre hardware resources don't have to compromise the
>design of a language, especially when it comes to syntax.
>
>So you can't use limited resources as an excuse for its questionable
>choices. Actually some choices actually made it harder to parse.
The team that created C was familiar with, and rather liked,
Richard Martin's BCPL. B was created as sort of a chopped down
BCPL that could fit on the PDP-7, a machine with 4KW of 18-bit
core memory, at an access time of ~1.5ms, where most
instructions touch memory twice. Oh, and that machine was
running a multitasking, multiuser operating system and was
self-hosting. And you are seriously comparing your single-user
home PC with 64k of RAM to that environment? I'm not sure you
know what "hardware limitations" are.
As mentioned, C came from B, once they got a PDP-11; it was an
incremental evolution of a language they already had. The type
syntax you find so distasteful was inspired by FORTRAN.
It's so weird to me that you make such absolute pronouncements
about C and the choices that into its design, but are so
ajbectly ignorant of the actual history. Bluntly, you just are
not very well informed about it to make cogent comments.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-19 09:18 +0000 |
| Message-ID | <11b4n9g$4fik$2@paganini.bofh.team> |
| In reply to | #403301 |
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>>C is a terrible choice for a cross-language API, as too many C-isms
>>creep in (like C macros, or vaguely defined types, including the famous
>>'plain char' that exists in no other language, which is neither signed
>>nor unsigned, and above all C preprocessor features).
>
> That's why ABIs matter.
>
> Look at the Vax-11 Procedure Calling and Condition Handling
> Standard from VMS 2.0; they simply wrote down what this stuff
> meant, and you could call between essentially any language on
> that system, whether it was C, Fortran, Bliss, COBOL, or
> whatever.
That is getting off-topic, but I looked at VMS documentation.
Simple cases are described with a lot of details. But I was
unable to find general case. Say, given array of structs
containing notrivial types like arrays inside. It seems that
for such types it is essentially "whatever language processor
decides to do" and the other end must know the convention.
Which seem to be exactly what happens on other platforms.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-19 12:00 +0000 |
| Message-ID | <11b50pe$ekp$1@reader2.panix.com> |
| In reply to | #403310 |
In article <11b4n9g$4fik$2@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>>C is a terrible choice for a cross-language API, as too many C-isms
>>>creep in (like C macros, or vaguely defined types, including the famous
>>>'plain char' that exists in no other language, which is neither signed
>>>nor unsigned, and above all C preprocessor features).
>>
>> That's why ABIs matter.
>>
>> Look at the Vax-11 Procedure Calling and Condition Handling
>> Standard from VMS 2.0; they simply wrote down what this stuff
>> meant, and you could call between essentially any language on
>> that system, whether it was C, Fortran, Bliss, COBOL, or
>> whatever.
>
>That is getting off-topic, but I looked at VMS documentation.
>Simple cases are described with a lot of details. But I was
>unable to find general case. Say, given array of structs
>containing notrivial types like arrays inside. It seems that
>for such types it is essentially "whatever language processor
>decides to do" and the other end must know the convention.
>Which seem to be exactly what happens on other platforms.
I imagine in that case one would use an array descriptor to
describe the array, and then a more specific descriptor (or set
of) to describe the structure of each element of the array.
In any event, the thing they did that's relevant here is
describing the properties of the basic types (what the VAX-11
run-time library reference manual calls, "atomic types", which
should not be confused with what we now call atomic types, that
have specific properties on multi-CPU systems; the VMS 2.0 docs
just meant the primitive data types understood by the VAX
hardware; bytes words, long/quad/octowords, and so on).
The point I was trying to make, and how it's relevant to C, is
that this is an early-ish example of what we now would think of
as an ABI, and it made (say) inter-language procedures calls
tractable. I don't know quite how to articulate it in a way
that won't kick over the language-lawyer hornet's nest, but
informally, the C standard doesn't mandate any particular ABI,
and indeed, tries to steer clear of such things to the extent
that it can. Bart complains about the need to deal with the "C
API", but really, he's referring to ABI issues ("is `char`
signed or not?" The ISO C doesn't say, but within each ABI, we
know.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 12:47 +0100 |
| Message-ID | <11b500f$216c4$1@dont-email.me> |
| In reply to | #403301 |
On 19/10/2026 02:19, Dan Cross wrote:
> In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote:
> I see that you convenient snipped out my comment about C++,
> which is the direct counter example.
I don't want to discuss C++. That language is abominable, other than as
the go-to example of language design going very wrong.
> "Had" is a strong word; dare I say it...a subjective word.
>
> In fact, there have been all kinds of alternatives for years.
> In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU,
> BLISS, and so on. You yourself admit you started from Algol68.
> By the late 1980s you had Oberon, decent versions of ML, C++
> and Objective-C, etc; by the 1990s, there were more than you
> could shake a stick at. Now? Take your pick.
>
> You never "had" to use your own language.
OK. But they HAD to create C? There were quite a few languages in the
early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL
and B. So why a new one?
Anyway you don't know my circumstances. My homemade machine had
absolutely ZERO software. I literally had to start from binary machine
code, as there was no keyboard at first (more below).
I also never used Algol68; I'd only seen it in a book.
In my job later I was an engineer, not a programmer, and there was no
budget for software such as compilers. But they would anyway have been a
nightmare to install (floppy disk formats were not standard!), and would
been hopelessly slow to use.
The language I ended up creating was perfect for my needs and compiled
more or less instantly.
>> You do know; you just don't want to admit it. (Imagine introducing C
>> declarations into a current language.)
>
> No, really; C's declaration syntax was inspired by FORTRAN, and
> generations of scientists and engineers have managed that
> language just fine.
FORTRAN syntax looked nothing like C! Unless you mean the general
pattern of 'INTEGER A, B' which was shared by half of all languages.
(I spent a year writing FORTRAN on mainframes and minicomputers.)
> Generations of programmers have handled C's
> all right as well.
How many gave up because it was too much? How many still struggle with
it and have to employ those 4 or 5 workarounds which I mention
elsewhere? How much has it affected productivity?
Your statement is meaningless. Maybe some task (in any sphere) takes 17
steps to achieve. People will manage. But then somebody figures out how
to do it in 3 steps; that's better right?
No, according to you: let's stick with 17 steps; people have always
managed, and 10 million people can't be wrong!
> Then why do you keep bringing your language up, showing snippets
> of its syntax, and so on?
Suppose that language didn't exist. I guess then it would be OK to bring
up hypothetical new features and bits of syntax here? People do it all
the time (even Keith did today, of all people).
But if those examples come from an actual, working and proven
implementation, which lend them more weight, then it is not allowed and
the examples then become irrelevant?
I guess it is not playing the game in that case?
>> Why hasn't there long been an alternative systems language that didn't
>> have C's crazy syntax and stupid quirks? I mean like 30-50 years ago.
>
> There...have been? And still are?
In that case, why has C itself been so heavily used, in OSes, drivers,
and endless libraries, rather than one those which you suggest I adopt?
I needed a language that worked at a lower level, could access hardware,
had inline assembly, had a weak type system that allowed all sorts of
underhand methods /to get things done/.
And that is exactly what I created in the early 80s, along with, as it
turned out, very fast implementations.
C would also have been a good fit, and presumably why it was so popular
for actual systems programming tasks.
So WHAT C does is good; HOW it does it is bad - in my opinion, and lots
of others. The difference is others have be work with it, while I had
the choice of persevering with mine.
Still, this is C in 2026:
#include <stdint.h>
uint8_t a, b, c;
This is mine in 1981 and in 2026
byte a, b, c
>> Yes, mine has lots of examples of how some alternative features could
>> work; so what? I am not selling my language.
>
> Oh good, so you'll stop bringing it up?
Forget the actual language: why is not possible to concentrate on some
specific feature or approach, and consider that in isolation and without
bias?
It either has merit or it hasn't. In any case, when I posted a link to
that document about my language, people (especially JP) said it was
derivative with nothing new.
So that's OK then? Just pretend some feature has been used in some more
famous language.
> Not really, no. I don't do Windows,
OK. I mentioned it because some people don't believe my language exists.
I have posted links to working versions over the years, but I usually
found that a waste of time, as now. (I still had to prepare and test the
version I'd have linked to.)
> But this sort of thing is exactly what I'm talking about: your
> language is not useful beyond a userbase of one.
That is 100% not true. It would be useful to anyone working on Windows
or even Linux. But it was never intended as a product used by other
people. As I said I'm not selling it, and would not want to support it.
> You solved a
> set of "problems" that you defined for yourself, whether they
> were real or not,
The scope of my language seems to overlap with the scope of C.
and now are now sitting here trying to use
> that as evidence about a general argument based on false
> premises ("there was no alternative! I _had_ to do my own
> thing!"
I gave you my circumstances above. What would /you/ have done?
> That's why ABIs matter.
You're confusing APIs and ABIs.
ABIs are a matter for compilers. Translating APIs into a set of bindings
for another language is someone else's job.
>> So you can't use limited resources as an excuse for its questionable
>> choices. Actually some choices actually made it harder to parse.
>
> The team that created C was familiar with, and rather liked,
> Richard Martin's BCPL. B was created as sort of a chopped down
> BCPL that could fit on the PDP-7, a machine with 4KW of 18-bit
> core memory, at an access time of ~1.5ms, where most
> instructions touch memory twice. Oh, and that machine was
> running a multitasking, multiuser operating system and was
> self-hosting. And you are seriously comparing your single-user
> home PC with 64k of RAM to that environment? I'm not sure you
> know what "hardware limitations" are.
My first machine actually had 256 bytes of RAM, no input, no output, and
unreliable cassette tape storage made with shift registers and counters.
I had ZERO existing software. No money. I didn't work in academia, nor
in a company, had no people to help. There weren't lots of other,
existing machines and terminals lying around to prepare programs on.
Yes the hardware was more compact and cheaper compared with 1970
(although SRAM still cost £24,000,000 per GB -- in 1981 money!) but I
was lacking everything else.
In any case, we're talking about C. Was a PDP 11/20 less powerful than a
2.5MHz Z80 with the 32KB I ended up with? I've no idea. But the crude
language I created FROM NOTHING still looked like this:
int a, b, c
println a + b
> As mentioned, C came from B, once they got a PDP-11; it was an
> incremental evolution of a language they already had. The type
> syntax you find so distasteful was inspired by FORTRAN.
Please give an example of FORTRAN that looks like C.
> It's so weird to me that you make such absolute pronouncements
> about C and the choices that into its design, but are so
> ajbectly ignorant of the actual history. Bluntly, you just are
> not very well informed about it to make cogent comments.
How does knowing the history in such detail help? If a feature stinks,
it stinks.
See my post yesterday about the impact choosing a prefix dereference op
instead of postfix made on the language. It was probably even more
far-reaching than stated.
And yet Pascal was right there!
That choice had nothing to with limited hardware; it was just the wrong one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 14:08 +0200 |
| Message-ID | <11b518m$1q18k$4@dont-email.me> |
| In reply to | #403314 |
On 19/10/2026 13:47, bart wrote: > On 19/10/2026 02:19, Dan Cross wrote: >> In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >> I see that you convenient snipped out my comment about C++, >> which is the direct counter example. > > I don't want to discuss C++. That language is abominable, other than as > the go-to example of language design going very wrong. And yet it is another /massively/ successful language. Perhaps you are correct that C and C++ are terrible designs - but that would mean "good" and "bad" language design has nothing much to do with how successful a language is, or how many people manage to use the language to write good, working, useful software. Mind you, we have no examples of languages that you consider "good" language design, other than your own languages. > >> "Had" is a strong word; dare I say it...a subjective word. >> >> In fact, there have been all kinds of alternatives for years. >> In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU, >> BLISS, and so on. You yourself admit you started from Algol68. >> By the late 1980s you had Oberon, decent versions of ML, C++ >> and Objective-C, etc; by the 1990s, there were more than you >> could shake a stick at. Now? Take your pick. >> >> You never "had" to use your own language. > > OK. But they HAD to create C? There were quite a few languages in the > early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL > and B. So why a new one? Check off "whataboutism" on the logical fallacy bingo card ! > >> Generations of programmers have handled C's >> all right as well. > > How many gave up because it was too much? How many still struggle with > it and have to employ those 4 or 5 workarounds which I mention > elsewhere? How much has it affected productivity? I have never heard of anyone giving up C because of the declaration syntax. Have you? Once you have removed pathological examples, I have not seen anyone but C newbies have trouble with real-world C declarations - and having trouble when you are new to a language is perfectly normal for all languages. And by "workarounds", do you mean language features for working with types? I have heard people complain about C's declaration syntax, and heard people say it is weird, or ugly, or counter-intuitive - but not that it actually causes real productivity problems, real bugs, or chases people away from the language. Any point you may have had has been long lost in your wild exaggerations.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-19 17:22 +0000 |
| Message-ID | <11b5jl1$s7r$1@reader2.panix.com> |
| In reply to | #403314 |
In article <11b500f$216c4$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 19/10/2026 02:19, Dan Cross wrote: >> I see that you convenient snipped out my comment about C++, >> which is the direct counter example. > >I don't want to discuss C++. That language is abominable, other than as >the go-to example of language design going very wrong. Oh. You don't _want_ to; I see. So you want to make statements about the relative "productivity" of languages but ignore the most prominent counter example to your argument because you don't _want_ to discuss C++. >> "Had" is a strong word; dare I say it...a subjective word. >> >> In fact, there have been all kinds of alternatives for years. >> In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU, >> BLISS, and so on. You yourself admit you started from Algol68. >> By the late 1980s you had Oberon, decent versions of ML, C++ >> and Objective-C, etc; by the 1990s, there were more than you >> could shake a stick at. Now? Take your pick. >> >> You never "had" to use your own language. > >OK. But they HAD to create C? Doesn't matter. They did. You weren't there; you don't know why they made the decisions they made, whether they gave this or that serious consideration and dismissed it, or were unaware of one thing or another, what constraints they were operating under, etc. It is _so easy_ to sit here and throw stones at people toiling away in the 1960's because they made decisions you don't like. But, bluntly, you haven't put in the work to have an opinion: you are ignorant of the history, and actively resist even simple things like reading the standard to back up your assertions; when you're shown to be incorrect, you double down or (yes) move the goalposts by making some other statement. You came up with your toy language and compiler in the 80s; more than a decade after C. It's cute that you felt you _had_ to do that, but you were in a completely different context than the 1127 folks at Bell Labs who created C. >There were quite a few languages in the >early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL >and B. So why a new one? B _was_ a new language. Pascal as a useful language beyond pedagogy postdates C. Pretty much the rest of this is discussed in DMR's C history paper, which I'm willing to bet you haven't bothered to read. >Anyway you don't know my circumstances. My homemade machine had >absolutely ZERO software. I literally had to start from binary machine >code, as there was no keyboard at first (more below). Next you'll tell us you went to the beach and picked up sand so you could smelt it and create your own silicon wafers, right? You described its capabilities. It was vastly more capable than a PDP-7, and it had only one user: you. >I also never used Algol68; I'd only seen it in a book. You said yourself you modeled your language on Algol68; whether you had used it or not is irrelevant. >In my job later I was an engineer, not a programmer, and there was no >budget for software such as compilers. But they would anyway have been a >nightmare to install (floppy disk formats were not standard!), and would >been hopelessly slow to use. > >The language I ended up creating was perfect for my needs and compiled >more or less instantly. You said you could not use a compiler and then literally described using a compiler. >>> You do know; you just don't want to admit it. (Imagine introducing C >>> declarations into a current language.) >> >> No, really; C's declaration syntax was inspired by FORTRAN, and >> generations of scientists and engineers have managed that >> language just fine. > >FORTRAN syntax looked nothing like C! Unless you mean the general >pattern of 'INTEGER A, B' which was shared by half of all languages. That was literally the thing you said you address with left-to-right syntax, and that anyone who proposed such would be laughed at. Now it's fine, just not in C. Because C is bad. Or something. >(I spent a year writing FORTRAN on mainframes and minicomputers.) I'm sure no one else here has done that. (*rolls eyes*) >> Generations of programmers have handled C's >> all right as well. > >How many gave up because it was too much? How many still struggle with >it and have to employ those 4 or 5 workarounds which I mention >elsewhere? How much has it affected productivity? > >Your statement is meaningless. Maybe some task (in any sphere) takes 17 >steps to achieve. People will manage. But then somebody figures out how >to do it in 3 steps; that's better right? Maybe, maybe not. There may well be other considerations that factor into that decision. >No, according to you: let's stick with 17 steps; people have always >managed, and 10 million people can't be wrong! So by this metric, it's cool if a pilot just jumps into an airliner, turns it on, and takes off? The rest of the pre-flight checklist is just busywork, amirite? >> Then why do you keep bringing your language up, showing snippets >> of its syntax, and so on? > >Suppose that language didn't exist. I guess then it would be OK to bring >up hypothetical new features and bits of syntax here? People do it all >the time (even Keith did today, of all people). > >But if those examples come from an actual, working and proven >implementation, which lend them more weight, then it is not allowed and >the examples then become irrelevant? If you want to discuss C on its merits, then discuss C. Unfortunately for you that would probably mean you'd have to actually read the relevant documentation. Do you _really_ think that the people who post here regularly are not aware that, say, other variable declaration syntaxes exist that are less messy than C's? No, seriously, don't give me some other example from your language, answer that question honestly: do you _really_ believe that no one here understands that fact, or just outright disbelieves it? >I guess it is not playing the game in that case? >>> Why hasn't there long been an alternative systems language that didn't >>> have C's crazy syntax and stupid quirks? I mean like 30-50 years ago. >> >> There...have been? And still are? > >In that case, why has C itself been so heavily used, in OSes, drivers, >and endless libraries, rather than one those which you suggest I adopt? I can think of any number of reasons: legacy, compatibility, tool availability, in some cases just personal preference. For any one of these, I'm sure that someone has already told you sometime in the last six months. My repeating them is unlikely to have any effect. >I needed a language that worked at a lower level, could access hardware, >had inline assembly, had a weak type system that allowed all sorts of >underhand methods /to get things done/. >[snip same stuff over again] No one cares. >[snip] >I gave you my circumstances above. What would /you/ have done? Probably not spent years seething about how the rest of the world is wrong for making decisions I would not have. >[snip] >> That's why ABIs matter. > >You're confusing APIs and ABIs. > >ABIs are a matter for compilers. Translating APIs into a set of bindings >for another language is someone else's job. You really don't understand how multilangauge environments work, do you? Maybe have a look at an ABI document at some point. >[snip sob story about walking uphill both ways in the snow] >But the crude >language I created FROM NOTHING still looked like this: > > int a, b, c > println a + b Ok. Don't really care. >> As mentioned, C came from B, once they got a PDP-11; it was an >> incremental evolution of a language they already had. The type >> syntax you find so distasteful was inspired by FORTRAN. > >Please give an example of FORTRAN that looks like C. Why? What would that show? If you'd get over yourself for ten minutes and read the HOPL paper on C, you may see this: |Fortran influenced the syntax of declarations: B declarations |begin with a specifier like `auto` or `static`, followed by a |list of names, and C not only followed this style but |ornamented it by placing its type keywords at the start of |declarations. (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) >> It's so weird to me that you make such absolute pronouncements >> about C and the choices that into its design, but are so >> ajbectly ignorant of the actual history. Bluntly, you just are >> not very well informed about it to make cogent comments. > >How does knowing the history in such detail help? If a feature stinks, >it stinks. Much of your ranting amounts to, "how could anyone have possibly thought this was a good idea?" Perhaps if you looked into the history a bit, you may become enlightened as to why anybody possibly thought it was a good idea. >See my post yesterday about the impact choosing a prefix dereference op >instead of postfix made on the language. It was probably even more >far-reaching than stated. > >And yet Pascal was right there! Amazingly, ALGOL W used syntax much closer to C's, despite being the immediate predecessor of Pascal. >That choice had nothing to with limited hardware; it was just the wrong one. One final quote from HOPL: |Although we entertained occasional thoughts about implementing |one of the major languages of the time like Fortran, PL/I, or |Algol 68, such a project seemed hopelessly large for our |resources: much simpler and smaller tools were called for. All |these languages influenced our work, but it was more fun to do |things on our own. So, they were aware of all the languages you've cited as influences. And yet they decided to do things differently. Perhaps they had their reasons. They are not (in the case of Ken) and were not (sadly, in the case of Dennis) idiiots or fools. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 20:34 +0100 |
| Message-ID | <11b5rce$2c5f4$1@dont-email.me> |
| In reply to | #403330 |
On 19/10/2026 18:22, Dan Cross wrote: > In article <11b500f$216c4$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> On 19/10/2026 02:19, Dan Cross wrote: >>> I see that you convenient snipped out my comment about C++, >>> which is the direct counter example. >> >> I don't want to discuss C++. That language is abominable, other than as >> the go-to example of language design going very wrong. > > Oh. You don't _want_ to; I see. So you want to make statements > about the relative "productivity" of languages but ignore the > most prominent counter example to your argument because you > don't _want_ to discuss C++. > >>> "Had" is a strong word; dare I say it...a subjective word. >>> >>> In fact, there have been all kinds of alternatives for years. >>> In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU, >>> BLISS, and so on. You yourself admit you started from Algol68. >>> By the late 1980s you had Oberon, decent versions of ML, C++ >>> and Objective-C, etc; by the 1990s, there were more than you >>> could shake a stick at. Now? Take your pick. >>> >>> You never "had" to use your own language. >> >> OK. But they HAD to create C? > > Doesn't matter. They did. You weren't there; you don't know > why they made the decisions they made, whether they gave this or > that serious consideration and dismissed it, or were unaware of > one thing or another, what constraints they were operating > under, etc. > > It is _so easy_ to sit here and throw stones at people toiling > away in the 1960's because they made decisions you don't like. > But, bluntly, you haven't put in the work to have an opinion: > you are ignorant of the history, and actively resist even simple > things like reading the standard to back up your assertions; > when you're shown to be incorrect, you double down or (yes) move > the goalposts by making some other statement. > > You came up with your toy language and compiler in the 80s; more > than a decade after C. It's cute that you felt you _had_ to do > that, but you were in a completely different context than the > 1127 folks at Bell Labs who created C. > >> There were quite a few languages in the >> early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL >> and B. So why a new one? > > B _was_ a new language. Pascal as a useful language beyond > pedagogy postdates C. Pretty much the rest of this is discussed > in DMR's C history paper, which I'm willing to bet you haven't > bothered to read. > >> Anyway you don't know my circumstances. My homemade machine had >> absolutely ZERO software. I literally had to start from binary machine >> code, as there was no keyboard at first (more below). > > Next you'll tell us you went to the beach and picked up sand so > you could smelt it and create your own silicon wafers, right? > > You described its capabilities. It was vastly more capable than > a PDP-7, and it had only one user: you. > >> I also never used Algol68; I'd only seen it in a book. > > You said yourself you modeled your language on Algol68; whether > you had used it or not is irrelevant. > >> In my job later I was an engineer, not a programmer, and there was no >> budget for software such as compilers. But they would anyway have been a >> nightmare to install (floppy disk formats were not standard!), and would >> been hopelessly slow to use. >> >> The language I ended up creating was perfect for my needs and compiled >> more or less instantly. > > You said you could not use a compiler and then literally > described using a compiler. > >>>> You do know; you just don't want to admit it. (Imagine introducing C >>>> declarations into a current language.) >>> >>> No, really; C's declaration syntax was inspired by FORTRAN, and >>> generations of scientists and engineers have managed that >>> language just fine. >> >> FORTRAN syntax looked nothing like C! Unless you mean the general >> pattern of 'INTEGER A, B' which was shared by half of all languages. > > That was literally the thing you said you address with > left-to-right syntax, and that anyone who proposed such would be > laughed at. Now it's fine, just not in C. Because C is bad. > Or something. > >> (I spent a year writing FORTRAN on mainframes and minicomputers.) > > I'm sure no one else here has done that. (*rolls eyes*) > >>> Generations of programmers have handled C's >>> all right as well. >> >> How many gave up because it was too much? How many still struggle with >> it and have to employ those 4 or 5 workarounds which I mention >> elsewhere? How much has it affected productivity? >> >> Your statement is meaningless. Maybe some task (in any sphere) takes 17 >> steps to achieve. People will manage. But then somebody figures out how >> to do it in 3 steps; that's better right? > > Maybe, maybe not. There may well be other considerations that > factor into that decision. > >> No, according to you: let's stick with 17 steps; people have always >> managed, and 10 million people can't be wrong! > > So by this metric, it's cool if a pilot just jumps into an > airliner, turns it on, and takes off? The rest of the > pre-flight checklist is just busywork, amirite? > >>> Then why do you keep bringing your language up, showing snippets >>> of its syntax, and so on? >> >> Suppose that language didn't exist. I guess then it would be OK to bring >> up hypothetical new features and bits of syntax here? People do it all >> the time (even Keith did today, of all people). >> >> But if those examples come from an actual, working and proven >> implementation, which lend them more weight, then it is not allowed and >> the examples then become irrelevant? > > If you want to discuss C on its merits, then discuss C. > Unfortunately for you that would probably mean you'd have to > actually read the relevant documentation. > > Do you _really_ think that the people who post here regularly > are not aware that, say, other variable declaration syntaxes > exist that are less messy than C's? No, seriously, don't give > me some other example from your language, answer that question > honestly: do you _really_ believe that no one here understands > that fact, or just outright disbelieves it? > >> I guess it is not playing the game in that case? >>>> Why hasn't there long been an alternative systems language that didn't >>>> have C's crazy syntax and stupid quirks? I mean like 30-50 years ago. >>> >>> There...have been? And still are? >> >> In that case, why has C itself been so heavily used, in OSes, drivers, >> and endless libraries, rather than one those which you suggest I adopt? > > I can think of any number of reasons: legacy, compatibility, > tool availability, in some cases just personal preference. For > any one of these, I'm sure that someone has already told you > sometime in the last six months. My repeating them is unlikely > to have any effect. > >> I needed a language that worked at a lower level, could access hardware, >> had inline assembly, had a weak type system that allowed all sorts of >> underhand methods /to get things done/. >> [snip same stuff over again] > > No one cares. > >> [snip] >> I gave you my circumstances above. What would /you/ have done? > > Probably not spent years seething about how the rest of the > world is wrong for making decisions I would not have. > >> [snip] >>> That's why ABIs matter. >> >> You're confusing APIs and ABIs. >> >> ABIs are a matter for compilers. Translating APIs into a set of bindings >> for another language is someone else's job. > > You really don't understand how multilangauge environments work, > do you? Maybe have a look at an ABI document at some point. > >> [snip sob story about walking uphill both ways in the snow] >> But the crude >> language I created FROM NOTHING still looked like this: >> >> int a, b, c >> println a + b > > Ok. Don't really care. > >>> As mentioned, C came from B, once they got a PDP-11; it was an >>> incremental evolution of a language they already had. The type >>> syntax you find so distasteful was inspired by FORTRAN. >> >> Please give an example of FORTRAN that looks like C. > > Why? What would that show? > > If you'd get over yourself for ten minutes and read the HOPL > paper on C, you may see this: > > |Fortran influenced the syntax of declarations: B declarations > |begin with a specifier like `auto` or `static`, followed by a > |list of names, and C not only followed this style but > |ornamented it by placing its type keywords at the start of > |declarations. > (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) > >>> It's so weird to me that you make such absolute pronouncements >>> about C and the choices that into its design, but are so >>> ajbectly ignorant of the actual history. Bluntly, you just are >>> not very well informed about it to make cogent comments. >> >> How does knowing the history in such detail help? If a feature stinks, >> it stinks. > > Much of your ranting amounts to, "how could anyone have possibly > thought this was a good idea?" Perhaps if you looked into the > history a bit, you may become enlightened as to why anybody > possibly thought it was a good idea. > >> See my post yesterday about the impact choosing a prefix dereference op >> instead of postfix made on the language. It was probably even more >> far-reaching than stated. >> >> And yet Pascal was right there! > > Amazingly, ALGOL W used syntax much closer to C's, despite being > the immediate predecessor of Pascal. > >> That choice had nothing to with limited hardware; it was just the wrong one. > > One final quote from HOPL: > |Although we entertained occasional thoughts about implementing > |one of the major languages of the time like Fortran, PL/I, or > |Algol 68, such a project seemed hopelessly large for our > |resources: much simpler and smaller tools were called for. All > |these languages influenced our work, but it was more fun to do > |things on our own. > > So, they were aware of all the languages you've cited as > influences. And yet they decided to do things differently. > > Perhaps they had their reasons. They are not (in the case of > Ken) and were not (sadly, in the case of Dennis) idiiots or > fools. If you're going to shit over everything I say, ignore points and keep changing the subject, then OK you win, I lose. Satisfied?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-20 00:35 +0200 |
| Message-ID | <11b65v0$1kr9u$8@dont-email.me> |
| In reply to | #403330 |
On 2026-10-19 19:22, Dan Cross wrote: > In article <11b500f$216c4$1@dont-email.me>, bart <bc@freeuk.com> wrote: [...] >> I also never used Algol68; I'd only seen it in a book. > > You said yourself you modeled your language on Algol68; whether > you had used it or not is irrelevant. It may be worth the observation we could make here in the flood of bart's posts; most (if not all) features or ideas he seems to have adopted only on a lexical or syntactical level. Given what he gave as examples I have strong doubts that this should be attributed to Algol 68 in its "whole glory". - Syntactical inspiration; maybe. - More than that? - I'd be astonished. [...] > > One final quote from HOPL: > |Although we entertained occasional thoughts about implementing > |one of the major languages of the time like Fortran, PL/I, or > |Algol 68, such a project seemed hopelessly large for our > |resources: much simpler and smaller tools were called for. All > |these languages influenced our work, but it was more fun to do > |things on our own. > > So, they were aware of all the languages you've cited as > influences. And yet they decided to do things differently. Somewhere in a (meanwhile historic; 1990's?) document I read about someone (D.R.?) say that the influence of Algol 68 would be hardly seen in practice (or some such). - It's generally hard to tell if someone adopted concepts from some another specific language or read the language description to just dismiss all their ideas. ;-) In case of "C" and Algol 68, while I indeed see a couple adopted things, they are so rare, lacking the semantic context, or have been realized in a very stripped down variant, that it's hard to speak about being (in a more substantial way) "influenced" by it. To not stress my brain unnecessarily here's what a search suggests: Type Composition, Unions and Casts, Syntax and Operators, and Type Names & Structure. (I could add a few more, but I'd keep it terse.) Type Compositions: fine, but also no rocket science back then. Unions: a completely different concept in "C". Casts: hardly necessary in Algol 68 (primarily used for references). Syntax: beyond block structure, a completely different thing in "C". Operators: Not comparable in many respects. Type Names: 'bool', 'string', 'complex', etc., in original "C"? No. So I agree with the mentioned paper that it's hard to find this Algol 68 inspiration in "C"; and certainly not as a characterizing property of the language. With knowledge and a sharp eye you just find some (often only faint) traces as remains (that might as well have had another origin in some cases as we may infer from the list). Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 00:04 +0100 |
| Message-ID | <11b67mj$2gqlv$1@dont-email.me> |
| In reply to | #403343 |
On 19/10/2026 23:35, Janis Papanagnou wrote: > On 2026-10-19 19:22, Dan Cross wrote: >> In article <11b500f$216c4$1@dont-email.me>, bart <bc@freeuk.com> wrote: > [...] >>> I also never used Algol68; I'd only seen it in a book. >> >> You said yourself you modeled your language on Algol68; whether >> you had used it or not is irrelevant. > > It may be worth the observation we could make here in the flood of > bart's posts; most (if not all) features or ideas he seems to have > adopted only on a lexical or syntactical level. Given what he gave > as examples I have strong doubts that this should be attributed to > Algol 68 in its "whole glory". - Syntactical inspiration; maybe. - > More than that? - I'd be astonished. Syntax was part-influenced by Algol 60 (DEC), Algol 68, Pascal, Fortran and Ada. It was also case-insensitive (most of them). And expression-based (Algol 68). Type system and semantics were mine and befitted a low level systems language running on and for very low-end hardware.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-20 01:03 +0000 |
| Message-ID | <11b6ekh$d2qm$1@paganini.bofh.team> |
| In reply to | #403314 |
bart <bc@freeuk.com> wrote:
>
> OK. But they HAD to create C? There were quite a few languages in the
> early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL
> and B. So why a new one?
You ignore fact that Ritche wanted reasonably fast code from
very simple compiler. Around 1970 that meant in particular
pointer arithmetic. Also, address operator allowed simple
interfacing between pointer-oriented code and use of variables.
It is hard to imagine getting similar effect with different
semantics. IIUC C was not the only language going in this
direction, but mainstream languages were different.
Concerning specific languages, there was FORTRAN 66, it had 'do'
loop as only structured control structure, there rest of control
was via gotos. And the only data structure were array. Without
extentions FORTRAN 66 was unsuitable for system work, and arguably
for non-numeric work even early C was nicer than FORTRAN 66.
For reasonable speed FORTRAN 66 needed an optimizer which led
to compiler too big to run on a small machine.
PL/I had most needed features. But PL/I was a big language,
to run on small machine they would have to take tiny subset
and then add extentions. Basicaly they would end up with a
language which is very far from PL/I.
Similarly, BCPL was too complicated, B and C were simplifications
and adaptations small machine.
I think that Pascal was too late: nominally it was created earlier
but I think that it was available to Bell Labs only after they
did initial work leading to C. And Pascal shared problem of
speed on small machines. Note that later UCSD Pascal which
run on micros compiled to interpreted bytecode, which significantly
reduced performance.
> FORTRAN syntax looked nothing like C! Unless you mean the general
> pattern of 'INTEGER A, B' which was shared by half of all languages.
I think more pattern of
INTEGER A(20), B
which has similar structure to C variable declarations. Of course,
FORTRAN had no pointers (and structures or unions), so Ritche had
to invent syntax for them.
IMO C suffers because typedef was added late in the game and
function prototypes are much later. Prototypes need types and
to get it one needs "hole" in variable declaration. Where the
hole should be is specified by the C syntax, but placement of
hole is probably least clear aspect of declarations.
IMO C declaration syntax was a mistake, but as real life shows
it was not a fatal mistake, people can adapt. Note that in
eighties C position among system languages was not as strong as
it is now. In particular there were quite decent Modula 2
compilers and ony many machines Pascal was competitive too.
But there were no mass migration from C to other languages.
In fact C was gaining use and other languages lost their position.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-20 02:44 +0000 |
| Message-ID | <11b6ki2$2kohl$2@dont-email.me> |
| In reply to | #403360 |
On Tue, 20 Oct 2026 01:03:15 -0000 (UTC), Waldek Hebisch wrote: > Similarly, BCPL was too complicated, B and C were simplifications > and adaptations small machine. BCPL was a very bare-bones language -- it didn’t even have structs, or even much in the way of types. Every variable was an “integer”. Naming the variable didn’t return its value, but its address; you had to use an explicit “dereference” operator to get the variable value. C was certainly a more complicated language than BCPL.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 15:11 +0100 |
| Message-ID | <11b7sqn$32pr5$1@dont-email.me> |
| In reply to | #403360 |
On 20/10/2026 02:03, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>>
>> OK. But they HAD to create C? There were quite a few languages in the
>> early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL
>> and B. So why a new one?
>
> You ignore fact that Ritche wanted reasonably fast code from
> very simple compiler.
According to DC's quote from HOPL, it was also more fun to create a new
language.
> PL/I had most needed features. But PL/I was a big language,
> to run on small machine they would have to take tiny subset
> and then add extentions. Basicaly they would end up with a
> language which is very far from PL/I.
There were PL/360 and PL/M, although those were more specific, more
'machine-oriented' languages. (I implemented one for PDP10 but it was a
port of a systems language from a GEC machine.)
Anyway, a more general subset could have been used.
> Similarly, BCPL was too complicated, B and C were simplifications
> and adaptations small machine.
>
> I think that Pascal was too late: nominally it was created earlier
> but I think that it was available to Bell Labs only after they
> did initial work leading to C. And Pascal shared problem of
> speed on small machines. Note that later UCSD Pascal which
> run on micros compiled to interpreted bytecode, which significantly
> reduced performance.
It would not have been hard to use Pascal as a starting point for a
workable systems language. Wirth wouldn't have approved, but his
languages were too pure, too academic; some of us had things we needed
to get done!
Here I mean adapting Pascal for a competing systems language.
In my hands some aspects would be simplified (eg. no nested functions,
no closures), thus making it easier to generate decent code with a
simple compiler.
>
>> FORTRAN syntax looked nothing like C! Unless you mean the general
>> pattern of 'INTEGER A, B' which was shared by half of all languages.
>
> I think more pattern of
>
> INTEGER A(20), B
>
> which has similar structure to C variable declarations.
OK. That was typical for the time. But in Fortran it didn't get much
more complicated than that. Maybe 2D arrays and so on.
> Of course,
> FORTRAN had no pointers (and structures or unions), so Ritche had
> to invent syntax for them.
There were three languages from that era that I know had pointers or
references, and which allowed composing arbitrary types with arrays and
pointers, two of which were Algol68 and Pascal.
Both used a 100% LTR form.
The other was C. There, several choices were made:
* To start with that Fortran style except that [] are used
* To decree that that 'A[20]' syntax is supposed to match indexing of
A as it might appear in an expression
* To introduce "*" as a prefix dereference operator in expressions ...
* ... which then means that a prefix "*" appears in the declaration too
* A further complication was to allow function pointers within that a
declaration list
* Yet one more which came later was to add 'const', where placement now
gets confusing
But to stay with pointers, take this expression:
*A[i]
C precedence rules mean this is parsed as *(A[i]), which means that a
type written as 'T *A[N]' must be an array of pointers to T (I had to
think for a few seconds!).
But suppose you wanted a pointer to array of T? The expression for that
would be:
(*A)[i]
And so the declaration has to be 'T (*A)[N]' too.
So it is unfortunate that parentheses used to control precedence in an
expression now also have to appear in type declarations (where they are
often next to () used for parameter lists, for further confusion).
==============================================
So, what would have happened with a postfix deref op? (Ignore whether
'*' would still be a good choice.) My first example would be this:
A*[i]
Here, it would mean that A is dereferenced, then indexed; A must then be
a pointer to an array of T.
But suppose we wanted the original array of pointers to T, where you
index first then dereference. That is written like this:
A[i]*
You simply swap the order of [] and *.
So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
array/pointer and pointer/array, both within expressions and within
type-declarations.
How about that? Further, most of the type-spec is now LTR; only the
base-type has to stay on the left. Access terms in expressions will be
fully LTR.
> IMO C suffers because typedef was added late in the game and
> function prototypes are much later. Prototypes need types and
> to get it one needs "hole" in variable declaration. Where the
> hole should be is specified by the C syntax, but placement of
> hole is probably least clear aspect of declarations.
I thought that 'hole' was where 'int A[10]' mean one thing in normal
declaration but another within a parameter list.
> IMO C declaration syntax was a mistake, but as real life shows
> it was not a fatal mistake, people can adapt.
A mistake that could so easily have been avoid by choosing a different
precedence as shown above. Did none of the thousand people working at
Bell Labs (according to a comment in DC's follow-ip) spot this and say
anything?
Had no-one even glanced at a Pascal spec, if there was no working copy?
It would have transformed C type syntax.
(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original
eventually deprecated.
But this is a common theme of mine whether I perceive a problem that
people grudgingly admit might not be idea. But nothing was ever done to
fix it even after decades.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 17:02 +0200 |
| Message-ID | <11b7vqd$2m8c9$6@dont-email.me> |
| In reply to | #403379 |
On 20/10/2026 16:11, bart wrote: > The other was C. There, several choices were made: > > * To start with that Fortran style except that [] are used > > * To decree that that 'A[20]' syntax is supposed to match indexing of > A as it might appear in an expression > > * To introduce "*" as a prefix dereference operator in expressions ... > > * ... which then means that a prefix "*" appears in the declaration too > > * A further complication was to allow function pointers within that a > declaration list I don't see a problem with that. If you need to declare a function pointer, you need to declare it in a declaration list. To me, the big disadvantage of C's declaration syntax is that it lets you declare things of different (but related) types in the same declaration. I don't have a problem with : int (*my_func_pointer)(int); int my_array[20]; but I /do/ have a problem with : int (*my_func_pointer)(int), my_array[20]; or, more common and therefore worse : int * a, b; The way to deal with this is, of course, simply not writing such mixed declarations. But some people /do/ - living with other peoples' code is the bane of all programmers. I am confident that there could have been a nicer syntax, and function pointer (or function type) syntax is particularly ugly. But it works well enough in practice that I cannot see it as a problem or even inconvenience. > > * Yet one more which came later was to add 'const', where placement now > gets confusing Some people do find it hard to understand the difference between : const int * p; int * const q; const int * const r; I note that this is despite the clear left-to-right nature of "const" here. Many newbie mistakes with const will be caught by the compiler, and once you get used to it, you should be fine. > > But to stay with pointers, take this expression: > > *A[i] > > C precedence rules mean this is parsed as *(A[i]), which means that a > type written as 'T *A[N]' must be an array of pointers to T (I had to > think for a few seconds!). If you instead forget that you can declare more than one thing in one declaration, you can write : T* A[i]; Then it is quite clear. > > But suppose you wanted a pointer to array of T? The expression for that > would be: > > (*A)[i] > > And so the declaration has to be 'T (*A)[N]' too. Yes. Declaration syntax follows usage. (If you don't like the operator precedence, or the fact that dereferencing is pre-fix in C, unlike, say, Pascal, then that's an orthogonal dislike.) > > So it is unfortunate that parentheses used to control precedence in an > expression now also have to appear in type declarations (where they are > often next to () used for parameter lists, for further confusion). You know how to use typedefs to make code clearer. Complicated types are a minority. Most object declarations are either things, arrays of things, or pointers to things - not combinations of these. And most function declarations are just function declarations, not arrays of function pointers or other complex types. > > ============================================== > > So, what would have happened with a postfix deref op? (Ignore whether > '*' would still be a good choice.) My first example would be this: > > A*[i] > > Here, it would mean that A is dereferenced, then indexed; A must then be > a pointer to an array of T. > > But suppose we wanted the original array of pointers to T, where you > index first then dereference. That is written like this: > > A[i]* > > You simply swap the order of [] and *. > > So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating > array/pointer and pointer/array, both within expressions and within > type-declarations. Agreed. But does that make a significant difference? I don't think so. I'd have to see a lot more real-life examples to get a feeling for whether postfix dereference would be better or worse than prefix - saving the occasional parentheses is not sufficient. > > How about that? Further, most of the type-spec is now LTR; only the > base-type has to stay on the left. Access terms in expressions will be > fully LTR. > >> IMO C suffers because typedef was added late in the game and >> function prototypes are much later. Prototypes need types and >> to get it one needs "hole" in variable declaration. Where the >> hole should be is specified by the C syntax, but placement of >> hole is probably least clear aspect of declarations. > > I thought that 'hole' was where 'int A[10]' mean one thing in normal > declaration but another within a parameter list. That's a different thing entirely. (And while I don't find it confusing that array and pointer parameters mean the same thing in C, I do see it as a wasted opportunity for better static checking and optimisation of code.) > >> IMO C declaration syntax was a mistake, but as real life shows >> it was not a fatal mistake, people can adapt. > > A mistake that could so easily have been avoid by choosing a different > precedence as shown above. Did none of the thousand people working at > Bell Labs (according to a comment in DC's follow-ip) spot this and say > anything? I suspect the folks at Bell Labs were too busy writing real code to be bothered by how confused you would be with artificially complex types. Life is full of little decisions that, with hindsight, might have been sub-optimal choices but are nonetheless good enough in practice. C's declaration syntax is one of those decisions. It's worth learning from that and picking a clearer syntax for new languages, but it is not worth obsessing over its use in existing languages. > > Had no-one even glanced at a Pascal spec, if there was no working copy? > It would have transformed C type syntax. > > (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have > been added. This could have been done 50 years ago, with the original > eventually deprecated. It /is/ too late - far, far too late. It would be a terrible idea to add a new postfix dereference operator to give two different operators with no benefit other than very occasionally reducing the need for parentheses. If "*p" really bothers you, write "p[0]" instead (in expressions, not type declarations). > > But this is a common theme of mine whether I perceive a problem that > people grudgingly admit might not be idea. But nothing was ever done to > fix it even after decades.) > What is the common theme? You pick something that lots of people consider as "it's maybe uglier than it need be, but it works fine in practice" and pretend that you alone discovered the issue? Then you go completely haywire about how terrible and unbelievable it is, call the C designers idiots and claim to be a genius because your irrelevant language does something different? Then comes the paranoia, and claims that no one will "admit there is a problem", and the absurd insistence that we all "do something about it". Eventually the thread dies away, until you bring up the same shit half a year later. For years, and years, and years. Is that the common theme you are talking about?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 21:07 +0100 |
| Message-ID | <11b8hln$3be6n$1@dont-email.me> |
| In reply to | #403381 |
On 20/10/2026 16:02, David Brown wrote:
> On 20/10/2026 16:11, bart wrote:
>
>> The other was C. There, several choices were made:
>>
>> * To start with that Fortran style except that [] are used
>>
>> * To decree that that 'A[20]' syntax is supposed to match indexing of
>> A as it might appear in an expression
>>
>> * To introduce "*" as a prefix dereference operator in expressions ...
>>
>> * ... which then means that a prefix "*" appears in the declaration too
>>
>> * A further complication was to allow function pointers within that a
>> declaration list
>
> I don't see a problem with that. If you need to declare a function
> pointer, you need to declare it in a declaration list.
>
> To me, the big disadvantage of C's declaration syntax is that it lets
> you declare things of different (but related) types in the same
> declaration.
Yes, but that doesn't bite so much because it is uncommon.
> or, more common and therefore worse :
>
> int * a, b;
(See below.)
>> * Yet one more which came later was to add 'const', where placement now
>> gets confusing
>
> Some people do find it hard to understand the difference between :
>
> const int * p;
> int * const q;
> const int * const r;
>
> I note that this is despite the clear left-to-right nature of "const" here.
I was going to say it was right-to-left, but it can be considered both
and thus not clear:
const int const * const p;
1 2 3
const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.
(Both also can be in the middle with compound types like 'long long'!)
const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type 'pointer
to', so it could apply to that directly.
What about this however:
int * const * p;
1 2 3
I think here, const 2 applies to * 1, which is to it's left, and can't
apply to 'p' as that is the other side of the * 3.
Fair to say that is a complete mess, and it is error prone.
With a LTR syntax that a postfix deref would achieve, 'const' would
always be written immediately to the left of any * modifiers. (It is
meaningless for arrays and functions.)
It is never applied directly to a variable name.
For base types, it can be applied on the left, but C would still allow
it on the right or in the middle, or all three with duplicates.
That means there would be an ambiguity here where there is no identifier
between 'int' and 'const':
(const int const *)
For such reasons I would restrict base type const to be only on the left.)
> Complicated types are a minority.
I've showed even simple types or trying to use 'const' get becomes
confusing.
>> So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
>> array/pointer and pointer/array, both within expressions and within
>> type-declarations.
>
> Agreed.
>
> But does that make a significant difference? I don't think so.
It would make a HUGE difference:
(1) It helps to fix that confusion above
(2) You don't need parentheses so no need to remember if you want
(*A)[] or *A[]. Those will disappear from expressions too; less
clutter all round.
(3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so
that actual array pointers, which are more type-safe, could start to
appear more in C rather than the current T* idiom
(4) For pointers to structs, these are the patterns:
prefix * With -> With postfix *
(*P).m P->m P*.m
(**P).m (*P)->m P**.m
(***P).m (**P)->m P***.m
Which column looks the tidiest?
(5) With prefix *, a pointer type looks like 'T*'; notice the * is on
the right, not left! With postfix *, it would all be consistent. You
also wouldn't have 'T*A'; that would be an error (T* only happens
when there is no name)
(6) Your 'int * a, b' example would become:
int a *, b;
Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.
It doesn't fix everything, so you'd still have this:
int p* = &a;
p* = a;
To fix this requires that all modifiers apply to the base type. But this
would be a massive change. The above is merely what happens when *
becomes postfix.
>> A mistake that could so easily have been avoid by choosing a different
>> precedence as shown above. Did none of the thousand people working at
>> Bell Labs (according to a comment in DC's follow-ip) spot this and say
>> anything?
>
> I suspect the folks at Bell Labs were too busy writing real code to be
> bothered by how confused you would be with artificially complex types.
So you agree the process was very different compared to that which lead
to Ada for example? Just a couple of guys left to do their own thing.
(Maybe they were respected enough that no one dared to offer any
constructive criticism, or if they did then it was dismissed. As happens
here.)
>>
>> (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
>> been added. This could have been done 50 years ago, with the original
>> eventually deprecated.
>
> It /is/ too late - far, far too late. It would be a terrible idea to
> add a new postfix dereference operator to give two different operators
> with no benefit other than very occasionally reducing the need for
> parentheses.
But a special operator P->m to do the same job as (*P).m was fine! The
new op would eliminate the need for ->.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 11:20 +0200 |
| Message-ID | <11ba045$3peq3$1@dont-email.me> |
| In reply to | #403385 |
On 20/10/2026 22:07, bart wrote: > On 20/10/2026 16:02, David Brown wrote: >> On 20/10/2026 16:11, bart wrote: >> >>> The other was C. There, several choices were made: >>> >>> * To start with that Fortran style except that [] are used >>> >>> * To decree that that 'A[20]' syntax is supposed to match indexing of >>> A as it might appear in an expression >>> >>> * To introduce "*" as a prefix dereference operator in expressions ... >>> >>> * ... which then means that a prefix "*" appears in the declaration too >>> >>> * A further complication was to allow function pointers within that a >>> declaration list >> >> I don't see a problem with that. If you need to declare a function >> pointer, you need to declare it in a declaration list. >> >> To me, the big disadvantage of C's declaration syntax is that it lets >> you declare things of different (but related) types in the same >> declaration. > > Yes, but that doesn't bite so much because it is uncommon. > Unfortunately not - but it is uncommon to mix objects and function declarations, or objects of wildly different real types. >> or, more common and therefore worse : >> >> int * a, b; > > (See below.) > >>> * Yet one more which came later was to add 'const', where placement now >>> gets confusing >> >> Some people do find it hard to understand the difference between : >> >> const int * p; >> int * const q; >> const int * const r; >> >> I note that this is despite the clear left-to-right nature of "const" >> here. > I was going to say it was right-to-left, but it can be considered both > and thus not clear: > > const int const * const p; > 1 2 3 > > const 1 applies to the basetype to its right. > const 2 applies to the basetype to its left. These are redundant - they do the same thing. (I'd have preferred if the ordering rules were strict - allowing only "const int" or "int const" - but at least people are usually consistent in their style.) > > (Both also can be in the middle with compound types like 'long long'!) > > const 3 is tricky: I think it applies to the * to its left, since it > says that the pointer value itself is const. But 'p' has type 'pointer > to', so it could apply to that directly. Yes - it is "p" that is const, not the "*". > > What about this however: > > int * const * p; > > 1 2 3 > > I think here, const 2 applies to * 1, which is to it's left, and can't > apply to 'p' as that is the other side of the * 3. *p is of type "int * const" - thus you can use "*p" to access a pointer-to-int, but you can't use *p to change that pointer-to-int. Fortunately, such types are rare. > > Fair to say that is a complete mess, and it is error prone. No, it is not at all fair to say that. It is fair to say that a different way of writing types might make it easier to understand - but that's a /long/ way from saying it is "a complete mess". And you can't call it "error prone" unless you know that people regularly use such declarations, and often have bugs in their code as a result of doing so incorrectly. I think that is an unrealistic claim. I appreciate that it can be difficult to see exactly what that type means, unless you use such a construct regularly - but there is no benefit in wild exaggeration. And I don't think /any/ alternative syntax would make it easy to understand what that type really is, what it can do and what it cannot do, or why you might want it. > > With a LTR syntax that a postfix deref would achieve, 'const' would > always be written immediately to the left of any * modifiers. (It is > meaningless for arrays and functions.) You can write this in C++ : // This bit is only needed once template <typename T> using ptr = T *; // p is a pointer to a const pointer to an int ptr<const ptr<int>> p; That's LTR syntax. Sure, it also has < > parentheses, but that's a minor point since the ordering of the components is what apparently matters so much. Or you can write : typedef int * p_int; const p_int * p; Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to an int. These are different ways to write the same type, including one that is LTR, and the main hinder to understanding remains the same - what is the type for? > > It is never applied directly to a variable name. > > For base types, it can be applied on the left, but C would still allow > it on the right or in the middle, or all three with duplicates. What do you mean "base types" ? Do you mean that C lets you write const long int a; long const int a; const int long a; int const long a; long int const a; int long const a; ? If that's your complaint, then I agree with that one - I would be happier if C had allowed only "const long int;" here. But I think most programmers are consistent in the style they use (though some prefer "east const"). > > That means there would be an ambiguity here where there is no identifier > between 'int' and 'const': > > (const int const *) > > For such reasons I would restrict base type const to be only on the left.) >> Complicated types are a minority. > > I've showed even simple types or trying to use 'const' get becomes > confusing. No, you haven't. You have shown that /you/ claim to be confused by types with "const". Most C programmers, once they are used to the language, do not find it confusing in common and simple types. You do not get to invent meaningless complicated types, claim that you don't understand them, and use that as evidence that C's declaration syntax is "a complete mess". At best, all you can show is that for complex types, C's syntax can require more thought to write or understand than some alternative syntaxes might. But we've all known that for decades. > >>> So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating >>> array/pointer and pointer/array, both within expressions and within >>> type-declarations. >> >> Agreed. >> >> But does that make a significant difference? I don't think so. > > It would make a HUGE difference: Your points below are all true, but IMHO all very minor, and do not add up to anything much. They might be enough to tip the balance when developing a new language where you are trying to decide whether your dereference operator should be prefix or postfix, but they are not enough to cause any concern in a language that has chosen prefix. > > (1) It helps to fix that confusion above Your invented confusion. > > (2) You don't need parentheses so no need to remember if you want > (*A)[] or *A[]. Those will disappear from expressions too; less > clutter all round. That doesn't matter in practice. > > (3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so > that actual array pointers, which are more type-safe, could start to > appear more in C rather than the current T* idiom I don't see that as significant. I do agree that the decay of expressions using array types into pointer types is a source of error in C code - though I do not think it is as bad as you do. I would have been happier if arrays were value types and the expressions did not decay to pointer expressions without manual intervention (like taking the address of the first element). In my C++ code, I make a lot of use of std::array<> types for that purpose - in my C code, it is not uncommon for me to have arrays wrapped in a struct. But I just don't see pointer-to-array expressions to be common enough for the difference you describe to be important. > > (4) For pointers to structs, these are the patterns: > > prefix * With -> With postfix * > > (*P).m P->m P*.m > (**P).m (*P)->m P**.m > (***P).m (**P)->m P***.m > > Which column looks the tidiest? Far and away the most common - by orders of magnitude - are pointers to structs. "p->m" looks fine to me, and I prefer it to "p*.m". A pointer to a pointer to a struct is rare enough that it is a good thing for the syntax to stand out - with a postfix dereference, I'd probably still use parentheses and write "(p*)->m". > > (5) With prefix *, a pointer type looks like 'T*'; notice the * is on > the right, not left! With postfix *, it would all be consistent. You > also wouldn't have 'T*A'; that would be an error (T* only happens > when there is no name) The C declaration syntax is "declaration follows use". If "*" were a postfix operator, then the declaration of a pointer-to-int would become: int p*; while the type of p would be "int *". So you would still have an inconsistency there, unless you also changed the way C has its declarations. > > (6) Your 'int * a, b' example would become: > > int a *, b; > > Much easier, even with that space, to see that '*' does not belong to > the base type but is a modifier for that variable. It's still bad. I don't think finding a way to make it easier to write bad code is a good idea. > > It doesn't fix everything, so you'd still have this: > > int p* = &a; > p* = a; > > To fix this requires that all modifiers apply to the base type. But this > would be a massive change. The above is merely what happens when * > becomes postfix. So basically, the suggestion would change some very minor things - mostly in subjective ways - and not actually do anything for aspects of the language where there is more of a consensus that C is sub-optimal. And for this, you would want a fundamental change to one of the most used operators in all C code! > >>> A mistake that could so easily have been avoid by choosing a >>> different precedence as shown above. Did none of the thousand people >>> working at Bell Labs (according to a comment in DC's follow-ip) spot >>> this and say anything? >> >> I suspect the folks at Bell Labs were too busy writing real code to be >> bothered by how confused you would be with artificially complex types. > > So you agree the process was very different compared to that which lead > to Ada for example? Just a couple of guys left to do their own thing. I don't see how you reach that conclusion from what I wrote. It is, however, true that C was designed by a small number of people working closely together, rather than a large committee-based design process involving lots of people. > > (Maybe they were respected enough that no one dared to offer any > constructive criticism, or if they did then it was dismissed. As happens > here.) I have no insight into the culture at Bell Labs at the time, but that sounds extraordinarily unlikely. Feel free to offer some constructive criticism some time, and we will see if it is dismissed. Note that "constructive criticism" involves more than "It's C, and I hate everything about C because it is connected to *nix, and I hate everything about *nix because it is connected to C". And even if you occasionally have a valid criticism about C, it is not "constructive" criticism because we did not design the language, and we do not dictate how it could be changed or how it is used. > >>> >>> (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have >>> been added. This could have been done 50 years ago, with the original >>> eventually deprecated. >> >> It /is/ too late - far, far too late. It would be a terrible idea to >> add a new postfix dereference operator to give two different operators >> with no benefit other than very occasionally reducing the need for >> parentheses. > > But a special operator P->m to do the same job as (*P).m was fine! The > new op would eliminate the need for ->. > The -> operator was added to C in 1972 ! It is not new - it has always been part of the language beyond its early prototype versions.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 12:29 +0100 |
| Message-ID | <11ba7na$3sh37$1@dont-email.me> |
| In reply to | #403403 |
On 21/10/2026 10:20, David Brown wrote: > On 20/10/2026 22:07, bart wrote: >> On 20/10/2026 16:02, David Brown wrote: >>> On 20/10/2026 16:11, bart wrote: >>>> * A further complication was to allow function pointers within that a >>>> declaration list >>> To me, the big disadvantage of C's declaration syntax is that it lets >>> you declare things of different (but related) types in the same >>> declaration. >> >> Yes, but that doesn't bite so much because it is uncommon. >> > > Unfortunately not - but it is uncommon to mix objects and function > declarations, or objects of wildly different real types. That's what I meant. >> const int const * const p; >> 1 2 3 >> >> const 1 applies to the basetype to its right. >> const 2 applies to the basetype to its left. > > These are redundant - they do the same thing. (I'd have preferred if > the ordering rules were strict - allowing only "const int" or "int > const" - but at least people are usually consistent in their style.) > >> >> (Both also can be in the middle with compound types like 'long long'!) >> >> const 3 is tricky: I think it applies to the * to its left, since it >> says that the pointer value itself is const. But 'p' has type 'pointer >> to', so it could apply to that directly. > > Yes - it is "p" that is const, not the "*". I would disagree. This type can also be written as: (const int const * const) There is no 'p' to apply to. The type describes a pointer to an integer. The first two consts say, redundantly, that the integer value is const. The third must then apply to the pointer. >> >> What about this however: >> >> int * const * p; >> >> 1 2 3 >> >> I think here, const 2 applies to * 1, which is to it's left, and can't >> apply to 'p' as that is the other side of the * 3. > > *p is of type "int * const" - thus you can use "*p" to access a pointer- > to-int, but you can't use *p to change that pointer-to-int. But what exactly does this 'const' apply to? I'm suggesting any 'const' applies either to the base type (the one on the left) or to a particular '*'. In that case the latter 'const's must apply right-to-left to the preceding '*'. >> Fair to say that is a complete mess, and it is error prone. > > No, it is not at all fair to say that. It is fair to say that a > different way of writing types might make it easier to understand - but > that's a /long/ way from saying it is "a complete mess". And you can't > call it "error prone" unless you know that people regularly use such > declarations, and often have bugs in their code as a result of doing so > incorrectly. I think that is an unrealistic claim. If there's any confusion about which const applies to which type element, then mistakes can be made. > You can write this in C++ : > > // This bit is only needed once > template <typename T> using ptr = T *; > > // p is a pointer to a const pointer to an int > ptr<const ptr<int>> p; > > > That's LTR syntax. Sure, it also has < > parentheses, but that's a > minor point since the ordering of the components is what apparently > matters so much. That it is LTR is now irrelevant because I find that incomprehensible anyway. You've turned a linear chain a nested structure ... oh never mind, I don't even want to go there with C++. > > Or you can write : > > typedef int * p_int; > const p_int * p; > > Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to > an int. So, a common pattern with you is to use workarounds so that you effectively emulate LTR type patterns. Because they are easier to work with and understand. So you do appreciate how they facilitate things, even though they introduce an extra level of indirection and also disseminate the type information across the program. But you want to underplay how useful it would be to have natural LTR type declarations within a syntax. > These are different ways to write the same type, including one that is > LTR, and the main hinder to understanding remains the same - what is the > type for? If you create a type alias voluntarily (I don't mean structs where either a tag or a typedef needs to be created) then yes the name should impart something useful. But in my view this is often taken too far. Sometimes you have structs where every member has a different user-type. When you look further, you find they are all ints. That is just obfuscation. (I would accept enumeration types if the compiler can employ that info to improve type safety, but that seems to be limited.) >> I've showed even simple types or trying to use 'const' get becomes >> confusing. > > No, you haven't. OK. That is not surprising. >> It would make a HUGE difference: > > Your points below are all true, but IMHO all very minor, and do not add > up to anything much. It would eliminate half the issues with C's type syntax. Probably CDECL wouldn't need to exist. Lots of () disappear. It would make pointers-to-arrays more viable. But that's nothing in your view. OK again. > Your invented confusion. > That doesn't matter in practice. > I don't see that as significant. > > I do agree that the decay of expressions using array types into pointer > types is a source of error in C code - though I do not think it is as > bad as you do. I didn't say anything about, and that wouldn't be affected. > But I just don't see pointer-to-array expressions to be common enough > for the difference you describe to be important. If you're passing arrays to a function by-reference then the natural way is to a have a pointer to the array. C can do that, but nobody ever does so, probably because indexing is then so ugly. With my idea, (*A)[i] turns into A*[i], a bit less ugly. (In my language, it was A^[i]. However, some years ago I relaxed the rules to allow such in-between derefs to be dropped - the compiler will reinsert them as needed. So indexing looks like A[i], and there is the extra type safety of working with actual arrays, not pointers to things that may or may not be arrays. But then I also have pass-by-reference which achieves the same thing.) >> (4) For pointers to structs, these are the patterns: >> >> prefix * With -> With postfix * >> >> (*P).m P->m P*.m >> (**P).m (*P)->m P**.m >> (***P).m (**P)->m P***.m >> >> Which column looks the tidiest? > > Far and away the most common - by orders of magnitude - are pointers to > structs. "p->m" looks fine to me, and I prefer it to "p*.m". But where's the consistency? Sometimes "." is used for member selection, and sometimes "->". And with two pointer levels, you need both! (Again in my language, all those * (or ^) in the right column can be dropped. Some loss of transparency, but much, much cleaner code. But TBF, this could also be done in C without needing postfix *.) >> (5) With prefix *, a pointer type looks like 'T*'; notice the * is on >> the right, not left! With postfix *, it would all be consistent. You >> also wouldn't have 'T*A'; that would be an error (T* only happens >> when there is no name) > > The C declaration syntax is "declaration follows use". If "*" were a > postfix operator, then the declaration of a pointer-to-int would become: > > int p*; > > while the type of p would be "int *". So you would still have an > inconsistency there, unless you also changed the way C has its > declarations. The point is that currently you have 'int*' for the type, '*p' to declare p, and '*p' in expressions. The '*' switches sides for the bare type! >> (6) Your 'int * a, b' example would become: >> >> int a *, b; >> >> Much easier, even with that space, to see that '*' does not belong to >> the base type but is a modifier for that variable. > > It's still bad. I don't think finding a way to make it easier to write > bad code is a good idea. It wouldn't stay bad for long! Because if the intention was to declare two pointers, then it's easier to see that this is wrong. > So basically, the suggestion would change some very minor things - > mostly in subjective ways - and not actually do anything for aspects of > the language where there is more of a consensus that C is sub-optimal. > And for this, you would want a fundamental change to one of the most > used operators in all C code! Obviously you can't change prefix * now. A postfix /alternative/, in addition to prefix *, could have been introduced decades ago. So by the time /you/ encountered C, you might have been using the latter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 16:40 +0200 |
| Message-ID | <11bais3$1042$1@dont-email.me> |
| In reply to | #403410 |
On 21/10/2026 13:29, bart wrote: > On 21/10/2026 10:20, David Brown wrote: >> On 20/10/2026 22:07, bart wrote: >>> On 20/10/2026 16:02, David Brown wrote: >>>> On 20/10/2026 16:11, bart wrote: > >>>>> * A further complication was to allow function pointers within that a >>>>> declaration list > >>>> To me, the big disadvantage of C's declaration syntax is that it >>>> lets you declare things of different (but related) types in the same >>>> declaration. >>> >>> Yes, but that doesn't bite so much because it is uncommon. >>> >> >> Unfortunately not - but it is uncommon to mix objects and function >> declarations, or objects of wildly different real types. > > That's what I meant. Ok. It's nice to agree sometimes! > >>> const int const * const p; >>> 1 2 3 >>> >>> const 1 applies to the basetype to its right. >>> const 2 applies to the basetype to its left. >> >> These are redundant - they do the same thing. (I'd have preferred if >> the ordering rules were strict - allowing only "const int" or "int >> const" - but at least people are usually consistent in their style.) >> >>> >>> (Both also can be in the middle with compound types like 'long long'!) >>> >>> const 3 is tricky: I think it applies to the * to its left, since it >>> says that the pointer value itself is const. But 'p' has type >>> 'pointer to', so it could apply to that directly. >> >> Yes - it is "p" that is const, not the "*". > > I would disagree. This type can also be written as: > > (const int const * const) > > There is no 'p' to apply to. The type describes a pointer to an integer. > The first two consts say, redundantly, that the integer value is const. > > The third must then apply to the pointer. Yes. But "the pointer" is the thing you are declaring. I don't think it is worth belabouring this. > >>> >>> What about this however: >>> >>> int * const * p; >>> >>> 1 2 3 >>> >>> I think here, const 2 applies to * 1, which is to it's left, and >>> can't apply to 'p' as that is the other side of the * 3. >> >> *p is of type "int * const" - thus you can use "*p" to access a >> pointer- to-int, but you can't use *p to change that pointer-to-int. > > But what exactly does this 'const' apply to? The type of "*p" - the thing that "p" points to. > > I'm suggesting any 'const' applies either to the base type (the one on > the left) or to a particular '*'. > > In that case the latter 'const's must apply right-to-left to the > preceding '*'. You can view it that way. There is a style known as "east const" that aims to put "const" on the right where possible (thus "int const", rather than "const int"), so that it always applies to the thing immediately to its left. I have never liked the style, but it is arguably more consistent. > >>> Fair to say that is a complete mess, and it is error prone. >> >> No, it is not at all fair to say that. It is fair to say that a >> different way of writing types might make it easier to understand - >> but that's a /long/ way from saying it is "a complete mess". And you >> can't call it "error prone" unless you know that people regularly use >> such declarations, and often have bugs in their code as a result of >> doing so incorrectly. I think that is an unrealistic claim. > > If there's any confusion about which const applies to which type > element, then mistakes can be made. Mistakes can always be made. And mistakes can always be found, and fixed. The questions are, are mistakes made often, are they made more often than they would be with a different syntax, are the mistakes left undiscovered, and are they consequential? I don't think so - so I don't see the syntax as "error prone". Again, I do not think the C declaration syntax is the nicest or clearest to be found, compared to some languages - but I do not think it is nearly as bad in practice as some people make out. > >> You can write this in C++ : >> >> // This bit is only needed once >> template <typename T> using ptr = T *; >> >> // p is a pointer to a const pointer to an int >> ptr<const ptr<int>> p; >> >> >> That's LTR syntax. Sure, it also has < > parentheses, but that's a >> minor point since the ordering of the components is what apparently >> matters so much. > > That it is LTR is now irrelevant because I find that incomprehensible > anyway. You've turned a linear chain a nested structure ... oh never > mind, I don't even want to go there with C++. Your LTR form /is/ a nested structure - it's just that with this C++ format (which I have never seen anyone use in practice), the nesting is explicit. >> >> Or you can write : >> >> typedef int * p_int; >> const p_int * p; >> >> Thus p is a pointer to a "const p_int", where a "p_int" is a pointer >> to an int. > > So, a common pattern with you is to use workarounds so that you > effectively emulate LTR type patterns. Because they are easier to work > with and understand. I'm offering you an alternative, because /you/ find the normal C syntax confusing. /I/ would not write that, because I don't find the C syntax here confusing or difficult to read. And mostly I would not write "int * const * p" because I have no idea when such a type might be useful. (If I knew, then maybe I would give it a specific name.) > > So you do appreciate how they facilitate things, even though they > introduce an extra level of indirection and also disseminate the type > information across the program. I appreciate that you are easily confused and have trouble with C syntax. I recommend you do one of two things - stop worrying about imaginary types with no meaning, or learn to use typedef so that they are not so scary for you. > > But you want to underplay how useful it would be to have natural LTR > type declarations within a syntax. > I don't see LTR syntax as making a /significant/ or fundamental difference. There will be a narrow range of complex types where the C syntax is getting hard to follow, but an LTR syntax is easier, but beyond that LTR is equally impenetrable. The issue for complex types is not the syntax, it is the complexity of the type - and you handle that by breaking things down into manageable sections. Let us put some numbers into this. (To be clear - these numbers are pulled out of the air, and "real" values will depend on the reader, the context, the details of the real code, real alternative syntax, etc.) Let us say that C syntax is comprehensible with up to 4 parts - where a "part" is a "const", a "*", "[n]" - in addition to the base type. With an LTR syntax, let us say it is comprehensible up to 5 parts. Then there is no doubt - the LTR syntax /is/ clearer. But does it actually matter, in practice? Most declarations require no more than 3 parts - with the great majority clustered at 0 or 1 parts. Who cares if it is difficult to read a type declaration you almost never need? And then if you have something really complicated - 6 parts or more - it is equally incomprehensible with LTR and C syntax, and should be handled by divide-and-conquer just like anything complicated in programming. This is why I can agree that the C syntax is not optimal, that an LTR syntax can be clearer, and yet it does not actually matter and the C syntax works fine in practice. >> These are different ways to write the same type, including one that is >> LTR, and the main hinder to understanding remains the same - what is >> the type for? > > If you create a type alias voluntarily (I don't mean structs where > either a tag or a typedef needs to be created) then yes the name should > impart something useful. > > But in my view this is often taken too far. Sometimes you have structs > where every member has a different user-type. When you look further, you > find they are all ints. That is just obfuscation. Every good thing can be taken too far - but there are lots of good reasons for having multiple typedefs that all coincidentally happen to boil down to "int". > > (I would accept enumeration types if the compiler can employ that info > to improve type safety, but that seems to be limited.) I agree that C enumeration types are not as "strong" as I'd like. Compiler static analysis can help in many ways, but it would be better (for me) if they were strongly typed and scoped. > >>> I've showed even simple types or trying to use 'const' get becomes >>> confusing. >> >> No, you haven't. > > OK. That is not surprising. > >>> It would make a HUGE difference: >> >> Your points below are all true, but IMHO all very minor, and do not >> add up to anything much. > > It would eliminate half the issues with C's type syntax. Probably CDECL > wouldn't need to exist. Lots of () disappear. It would make pointers-to- > arrays more viable. > > But that's nothing in your view. OK again. CDECL has never needed to exist. So few () are needed in declarations that it doesn't matter if they are there or not. Pointers to arrays work fine if you want to use them, but they are not often used in C - primarily because of the array-to-pointer decay in expressions, not because of the declaration syntax or the prefix dereferencing operator. > >> Your invented confusion. > > >> That doesn't matter in practice. > >> I don't see that as significant. >> >> I do agree that the decay of expressions using array types into >> pointer types is a source of error in C code - though I do not think >> it is as bad as you do. > > I didn't say anything about, and that wouldn't be affected. > Ok. > >> But I just don't see pointer-to-array expressions to be common enough >> for the difference you describe to be important. > > > If you're passing arrays to a function by-reference then the natural way > is to a have a pointer to the array. C can do that, but nobody ever does > so, probably because indexing is then so ugly. > > With my idea, (*A)[i] turns into A*[i], a bit less ugly. Predictions are of course speculative, but I could not see that making noticeable difference. C programmers rarely use pointers to arrays because they rarely give advantages over pointers to the first element of an array, the decay in expressions means it is easy to make mistakes, and you often need to make a pointer to the first element anyway. If array expressions did not decay to pointer expressions, and array parameters were passed as values, it would be a very different matter. > >>> (4) For pointers to structs, these are the patterns: >>> >>> prefix * With -> With postfix * >>> >>> (*P).m P->m P*.m >>> (**P).m (*P)->m P**.m >>> (***P).m (**P)->m P***.m >>> >>> Which column looks the tidiest? >> >> Far and away the most common - by orders of magnitude - are pointers >> to structs. "p->m" looks fine to me, and I prefer it to "p*.m". > > But where's the consistency? Sometimes "." is used for member selection, > and sometimes "->". And with two pointer levels, you need both! The consistency is that you almost always have a pointer to a struct, so you can consistently use p->m. There is no need to change that for consistency with a much rarer usage. And of course "." is used for member selection when you have a struct object, or when you have already dereferenced a pointer to a struct. >>> (6) Your 'int * a, b' example would become: >>> >>> int a *, b; >>> >>> Much easier, even with that space, to see that '*' does not belong to >>> the base type but is a modifier for that variable. >> >> It's still bad. I don't think finding a way to make it easier to >> write bad code is a good idea. > > It wouldn't stay bad for long! Because if the intention was to declare > two pointers, then it's easier to see that this is wrong. It is bad (according to my personal style preferences) if your intentionally declare an int and a pointer to an int in the same line. I am not talking about mistakes here - a mixup between an int and an int* will almost certainly result in a compilation failure and the code will quickly be fixed to give valid C code. C lets you write "int *a, b;" - it is legal C. There are lots of things you can write in C that I think are bad code, even though they may be intentional and work as intended. (And even though others will, naturally, have different opinions.) I would be against any change to C syntax that made it /easier/ for people to write such declarations - whether intentional or by mistake. > >> So basically, the suggestion would change some very minor things - >> mostly in subjective ways - and not actually do anything for aspects >> of the language where there is more of a consensus that C is sub- >> optimal. And for this, you would want a fundamental change to one of >> the most used operators in all C code! > > Obviously you can't change prefix * now. A postfix /alternative/, in > addition to prefix *, could have been introduced decades ago. So by the > time /you/ encountered C, you might have been using the latter. > I first used C on a very small scale in the late 1980's, so that was quite a few decades ago. I expect that a postfix dereferencing operator would have worked fine instead of a prefix one - it works fine in Pascal. I don't think it would have been "better" in any significant way. Two separate dereferencing operators with no difference except the prefix vs. postfix positioning would have been a very bad idea, no matter when it were introduced - it would have been a totally unnecessary complication, just adding confusion and inconsistency. But even if you were right here, it is no more realistic to go back 4 decades to add this new postfix dereferencing operator as it is to go back 5 decades and pick that one in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-20 23:33 +0300 |
| Message-ID | <20261020233337.00004699@yahoo.com> |
| In reply to | #403379 |
On Tue, 20 Oct 2026 15:11:35 +0100 bart <bc@freeuk.com> wrote: > On 20/10/2026 02:03, Waldek Hebisch wrote: > > bart <bc@freeuk.com> wrote: > >> > >> OK. But they HAD to create C? There were quite a few languages in > >> the early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of > >> course BCPL and B. So why a new one? > > > > You ignore fact that Ritche wanted reasonably fast code from > > very simple compiler. > > According to DC's quote from HOPL, it was also more fun to create a > new language. > > > > PL/I had most needed features. But PL/I was a big language, > > to run on small machine they would have to take tiny subset > > and then add extentions. Basicaly they would end up with a > > language which is very far from PL/I. > > There were PL/360 and PL/M, although those were more specific, more > 'machine-oriented' languages. (I implemented one for PDP10 but it was > a port of a systems language from a GEC machine.) > PL/M is approximately contemporary to C, most likely Ritchie had first compiler working few months before Kildall. But input language of the early C compilers was likely further away from what it evolved later than early PL/M to later its variant. C was self-hosted on minicomputer from the beginning. PL/M originally required more powerful and expensive host. Eventually PL/M host requirements were reduced below those of C, but it took couple of years. > Anyway, a more general subset could have been used. > I suppose that you wholeheartedly agree. I don't. I never found computer language design fun. > > > Similarly, BCPL was too complicated, B and C were simplifications > > and adaptations small machine. > > > > I think that Pascal was too late: nominally it was created earlier > > but I think that it was available to Bell Labs only after they > > did initial work leading to C. And Pascal shared problem of > > speed on small machines. Note that later UCSD Pascal which > > run on micros compiled to interpreted bytecode, which significantly > > reduced performance. > > It would not have been hard to use Pascal as a starting point for a > workable systems language. Wirth wouldn't have approved, but his > languages were too pure, too academic; some of us had things we > needed to get done! > > Here I mean adapting Pascal for a competing systems language. > Pascal without several extensions does not seem suitable for system programming. > In my hands some aspects would be simplified (eg. no nested > functions, no closures), thus making it easier to generate decent > code with a simple compiler. > But then, it's not Pascal. And still needs extensions. > > > > >> FORTRAN syntax looked nothing like C! Unless you mean the general > >> pattern of 'INTEGER A, B' which was shared by half of all > >> languages. > > > > I think more pattern of > > > > INTEGER A(20), B > > > > which has similar structure to C variable declarations. > > OK. That was typical for the time. But in Fortran it didn't get much > more complicated than that. Maybe 2D arrays and so on. > > > Of course, > > FORTRAN had no pointers (and structures or unions), so Ritche had > > to invent syntax for them. > > There were three languages from that era that I know had pointers or > references, and which allowed composing arbitrary types with arrays > and pointers, two of which were Algol68 and Pascal. > > Both used a 100% LTR form. > > The other was C. There, several choices were made: > > * To start with that Fortran style except that [] are used > > * To decree that that 'A[20]' syntax is supposed to match indexing of > A as it might appear in an expression > > * To introduce "*" as a prefix dereference operator in expressions ... > > * ... which then means that a prefix "*" appears in the declaration > too > > * A further complication was to allow function pointers within that a > declaration list > > * Yet one more which came later was to add 'const', where placement > now gets confusing > > But to stay with pointers, take this expression: > > *A[i] > > C precedence rules mean this is parsed as *(A[i]), which means that a > type written as 'T *A[N]' must be an array of pointers to T (I had to > think for a few seconds!). > > But suppose you wanted a pointer to array of T? The expression for > that would be: > > (*A)[i] > > And so the declaration has to be 'T (*A)[N]' too. > > So it is unfortunate that parentheses used to control precedence in > an expression now also have to appear in type declarations (where > they are often next to () used for parameter lists, for further > confusion). > > ============================================== > > So, what would have happened with a postfix deref op? (Ignore whether > '*' would still be a good choice.) My first example would be this: > > A*[i] > > Here, it would mean that A is dereferenced, then indexed; A must then > be a pointer to an array of T. > > But suppose we wanted the original array of pointers to T, where you > index first then dereference. That is written like this: > > A[i]* > > You simply swap the order of [] and *. > > So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating > array/pointer and pointer/array, both within expressions and within > type-declarations. > > How about that? Further, most of the type-spec is now LTR; only the > base-type has to stay on the left. Access terms in expressions will > be fully LTR. > > > IMO C suffers because typedef was added late in the game and > > function prototypes are much later. Prototypes need types and > > to get it one needs "hole" in variable declaration. Where the > > hole should be is specified by the C syntax, but placement of > > hole is probably least clear aspect of declarations. > > I thought that 'hole' was where 'int A[10]' mean one thing in normal > declaration but another within a parameter list. > > > IMO C declaration syntax was a mistake, but as real life shows > > it was not a fatal mistake, people can adapt. > > A mistake that could so easily have been avoid by choosing a > different precedence as shown above. Did none of the thousand people > working at Bell Labs (according to a comment in DC's follow-ip) spot > this and say anything? > Methinks there were less than 100 people exposed to C before it became too late. May be, just 50. > Had no-one even glanced at a Pascal spec, if there was no working > copy? It would have transformed C type syntax. > > (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have > been added. This could have been done 50 years ago, with the original > eventually deprecated. > > But this is a common theme of mine whether I perceive a problem that > people grudgingly admit might not be idea. But nothing was ever done > to fix it even after decades.) > It was. There are many new languages. Today, C sees little use outside of small to mid-sized mocrocontrollers and OS kernels. Most user-layer applications on general purpose computers are written in newer languages.
[toc] | [prev] | [next] | [standalone]
Page 17 of 32 — ← Prev page 1 … 15 16 [17] 18 19 … 32 Next page →
Back to top | Article view | comp.lang.c
csiph-web