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 613 — 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 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 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 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 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 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-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: BizFuss (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 08:27 +0000
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 31 — ← Prev page 1 … 15 16 [17] 18 19 … 31 Next page →
| 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]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 00:01 +0100 |
| Message-ID | <11b8rrh$3eu2m$1@dont-email.me> |
| In reply to | #403388 |
On 20/10/2026 21:33, Michael S wrote: > On Tue, 20 Oct 2026 15:11:35 +0100 > bart <bc@freeuk.com> wrote: > I suppose that you wholeheartedly agree. I don't. I never found computer > language design fun. The fun part is afterwards when you use your very own language. Quite a way to get there though. > Methinks there were less than 100 people exposed to C before it became > too late. May be, just 50. Were you there? You seem confident of those figures! I've no idea what went on, myself; I can only speculate. > >> 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. I still see C everywhere, for example in the APIs of libraries like SDL, STB, GTK, OpenGL, Raylib, GMP, plus the APIs for many Windows subsystems, plus Linux. It's also popular as a target language for compilers (when LLVM is too much). Amateur compiler writers also seem to love creating C or C subset compilers more than any other language (they perceive it as simpler than it really is). And many language projects are still written in C, or at bootstrapped with C. This is all desktop machines still. Of course many are also migrating to products like Rust, Go and Zig. For me, the fact that there's still an appetite for a language of this class is one reason I still persist with mine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 13:22 +0200 |
| Message-ID | <11b2a6d$131h6$1@dont-email.me> |
| In reply to | #403234 |
On 17/10/2026 13:34, bart 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. > >> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >> much. Fixed in Go and Rust, but also, I doubt you've ever in >> your life had a variable of type array of array of length 8 of >> a pointer to a pointer to a function returning an array of >> pointers to char. Finding the most ridiculous example you can >> is not really evidence of anything besides your weird obsession > > That was the first one I saw online next to a quote from K&R and I > assumed it was from the book. In fact the example from the book is this: > > char (*(*x())[])() > > I've no idea what the means either. The point is not that the examples > are ridiculous, but that they are hard to convert to and from LTR form > which is how we think. With LTR syntax it becomes utterly trivial to > read or write them, no matter how complex. > > (There's a tool called CDECL that translates types from C syntax to LTR > English or vice versa. It calls the C versions 'gibberish'. This is a > real thing!) > Putting that example in cdecl gives : "declare x as function returning pointer to array of pointer to function returning char" To me, that is just as much gibberish as the original C. No syntax is going to make sense of it - no amount of "ref" or "func" or pre-fix array notation will help. If you want complex types in a programming language, make them out of simpler, named types that express what you are trying to achieve. I think any decent typed programming language will have a way to do this - for C, "typedef" is your friend here. (And do /not/ reply by bringing up examples you have cherry-picked from code you have found, as though it was my fault they wrote incomprehensible code.) > >> with finding abstruse corner cases and holding them up as >> reasons to dislike C. > > The first example I gave was the simplest form of function pointer, > where the syntax is 'void(*)(void)'. Hardly a corner case, and it > rapidly goes downhill. Name the types at the point where they are clear, and build them up from there. typedef void (*fp_void)(void); > > If meeting C for the first time, that does not bode well. If the > designers did not care about this, that does not inspire confidence in > the rest of the language. C is not, and has never claimed to be, a beginner-friendly language. It is designed to be efficient while remaining quite a small language, which means that there are parts that are harder to use correctly, details that are important to understand, and it has plenty of scope to write code that is unclear. It works well for responsible programmers who learn the language and code carefully - but you have to learn more before you can understand and use it than, say, BASIC or Python.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 14:12 +0200 |
| Message-ID | <11b2d46$3pvda$5@dont-email.me> |
| In reply to | #403261 |
On 2026-10-18 13:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> [...]
>> char (*(*x())[])()
>> [...]
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
There's different things here with the C-declaration.
* Complexity of expression; as you say below this can be alleviated by
structuring with "subtypes" and 'typedef'.
* Cryptic syntax with many (spurious but in "C" necessary) parenthesis.
* Mixed/mangled order of component concerning its logical structure.
The 'cdecl' tool helps with point 2 and 3. - So I consider it to be
quite useful! (Although I have to admit that I've never used it myself
in practice because (for my code) I try to not compose overly complex
type definitions; and when it gets complex point 1 applies.) Especially
if you have to work with third-party code it can spare you some time,
though.
>
> To me, that is just as much gibberish as the original C. No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
I assume you're here commenting on some of bart's adopted syntactical
decisions.
FWIW; why I prefer some other language design decisions is exactly that
they use syntaxes with such keywords. They typically reduce the number
of parentheses and other "graph" characters thereby reducing the effect
of code appearing quickly more cryptic than necessary, they make the
definition more clear and better readable (IMO). Keeping (in addition)
the logical order of its components also helps IMO to easier understand
the declaration construct.
To be frank, it's beyond me why anyone wouldn't admire such consistent
declaration syntaxes. (And if bart has adopted those principles that's
certainly not a bad thing. YMMV.)
>
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
Yes. This is what we can do about the "complexity" aspect of the topic.
Janis
> [snip]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 14:33 +0100 |
| Message-ID | <11b2hr6$15thq$1@dont-email.me> |
| In reply to | #403261 |
On 18/10/2026 12:22, David Brown wrote:
> On 17/10/2026 13:34, bart 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.
>>
>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as
>>> much. Fixed in Go and Rust, but also, I doubt you've ever in
>>> your life had a variable of type array of array of length 8 of
>>> a pointer to a pointer to a function returning an array of
>>> pointers to char. Finding the most ridiculous example you can
>>> is not really evidence of anything besides your weird obsession
>>
>> That was the first one I saw online next to a quote from K&R and I
>> assumed it was from the book. In fact the example from the book is this:
>>
>> char (*(*x())[])()
>>
>> I've no idea what the means either. The point is not that the examples
>> are ridiculous, but that they are hard to convert to and from LTR form
>> which is how we think. With LTR syntax it becomes utterly trivial to
>> read or write them, no matter how complex.
>>
>> (There's a tool called CDECL that translates types from C syntax to
>> LTR English or vice versa. It calls the C versions 'gibberish'. This
>> is a real thing!)
>>
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
>
> To me, that is just as much gibberish as the original C.
That doesn't matter - the problem is not even knowing what it
represents. (That it is an actual function is a surprise. That you can't
easily tell is crazy.)
In practice there will be actual types that start to look like
gibberish, full of *, () and [] that must be in exactly the right place.
Then maybe you want to construct a pointer to such a type or an array of
it - where will be the new * or [] go? Where will the variable name go
for that matter?
This should be simple enough to do in a language without needing to
follow some back-and-forth algorithm, or use an external tool, or need
to decompose them into multiple levels using 'typedef', or need to
disambiguate with parentheses.
Typedef decomposition can be useful when types are genuinely complex (or
parts of them are used/shared elsewhere), but it should not be a crutch
for an unusable type syntax.
In any case, for me the threshold at which I need help is low. I
couldn't do these for example:
* Array of function pointers (say taking no params and returning void)
* Pointer to array of function pointers
* Function returning pointer to array (of int)
* Pointer to function returning pointer to array (int)
My tool tells me the answers are these:
void (*[])(void)
void (*(*)[])(void)
int (*(void))[]
int (*(*)(void))[]
Still gobbledygook, sorry, and these are hardly that complex or
unrealistic. (Other than 'pointer to array' being an uncommon C idiom.
It's only uncommon because other C syntax choices make it ungainly to
work with.)
Of those four lines, one is an actual function; another is a pointer to
a function. Plus there is an array, and a pointer to something else. But
this is not obvious at a glance, because the key part is buried in the
middle. In an LTR scheme, it would be first.
> No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
It will tell you what it is, which is a start. Those four examples I
gave would look like this:
[]ref proc # 'proc' is 'func -> void'
ref []ref proc
func -> ref []int
ref func -> ref []int
Using a scheme I once proposed for C, to work side-by-side with the
current syntax, I believe it would be like this:
[]*func()void
*[]*func()void p, q;
func F()*[]int {}
*func()*[]int
Variable names would go on the right as in the second example. For that
actual function however, an earlier name looks better and matches other
languages.
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
>
> (And do /not/ reply by bringing up examples you have cherry-picked from
> code you have found, as though it was my fault they wrote
> incomprehensible code.)
But that is going to happen. You will come across such types.
> C is not, and has never claimed to be, a beginner-friendly language.
If something is needlessly complex and unintuitive, that will be the
case for everyone.
For beginners to C, it is just an unnecessary obstacle. I can see many
giving up on it for that reason.
One way to simplify types is to use 'typeof' (I've no idea whether it is
still an extension or now standardised). That means being able to write:
typeof(int*) p, q, r;
instead of: 'int *p, *q, *r' which is too tempting to write as 'int* p,
q, r'.
This solves another issue where the type of any declared variable is
split up into up three pieces in three different places:
int a, b, *c[10];
The type of 'c' comprises 'int', '*' before the name, and '[]' after the
name. This makes it hard to share too. 'typeof' allows this (or along
these lines):
typeof(int*[]) x, y, z;
The type is in one tidy place, and it can be shared. This is how C
should have worked in the first place, and it wouldn't have needed that
untidy 'typeof()'.
> It
> is designed to be efficient while remaining quite a small language,
C's type declarations are actually harder to parse than a conventional
LTR scheme. That means a more complex compiler front-end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:27 +0200 |
| Message-ID | <11b2l06$16mof$1@dont-email.me> |
| In reply to | #403269 |
On 18/10/2026 15:33, bart wrote: > On 18/10/2026 12:22, David Brown wrote: >> On 17/10/2026 13:34, bart 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. >>> >>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >>>> much. Fixed in Go and Rust, but also, I doubt you've ever in >>>> your life had a variable of type array of array of length 8 of >>>> a pointer to a pointer to a function returning an array of >>>> pointers to char. Finding the most ridiculous example you can >>>> is not really evidence of anything besides your weird obsession >>> >>> That was the first one I saw online next to a quote from K&R and I >>> assumed it was from the book. In fact the example from the book is this: >>> >>> char (*(*x())[])() >>> >>> I've no idea what the means either. The point is not that the >>> examples are ridiculous, but that they are hard to convert to and >>> from LTR form which is how we think. With LTR syntax it becomes >>> utterly trivial to read or write them, no matter how complex. >>> >>> (There's a tool called CDECL that translates types from C syntax to >>> LTR English or vice versa. It calls the C versions 'gibberish'. This >>> is a real thing!) >>> >> >> Putting that example in cdecl gives : >> >> "declare x as function returning pointer to array of pointer to >> function returning char" >> >> To me, that is just as much gibberish as the original C. > > That doesn't matter - the problem is not even knowing what it > represents. That is, shall we say, a strange attitude. Gibberish (since that seems to be the preferred term here) is gibberish, no matter the language or representation, and is equally meaningless and useless. > (That it is an actual function is a surprise. That you can't > easily tell is crazy.) You can tell it very easy from the C - the final bit is parentheses. > > In practice there will be actual types that start to look like > gibberish, full of *, () and [] that must be in exactly the right place. Not in my code, or the code I work with - types are clear to me. Again, experiences can vary. (Of course the syntactical elements must be in the right place!) > > Then maybe you want to construct a pointer to such a type or an array of > it - where will be the new * or [] go? Where will the variable name go > for that matter? Use a typedef. Or since C23, use type inference - that can save naming and identifying types when things get complex, and makes it easier to write more general code. Like all language features, there are times when it is appropriate, and times when it is inappropriate. But if you've got something "foo" (an object, function, type, etc.) and you want an array of 26 of that type, type inference makes that simple - the type of "foo" is "typeof(foo)" : typeof(foo) xs[26]; If you want a pointer to the object "foo", "auto * p = &foo;". This is, IMHO, a nice addition in C23, but it would have been nicer to have had it earlier. (It's been a gcc extension for a long time.) > > This should be simple enough to do in a language without needing to > follow some back-and-forth algorithm, or use an external tool, or need > to decompose them into multiple levels using 'typedef', or need to > disambiguate with parentheses. You just /have/ to whine, don't you? Whenever you complain - usually due to ignorance or prejudice - that something is difficult or complicated in C, and someone tells you how it can be handled simply and clearly, you are unable to simply say "Okay, thanks - that's good to know" or "Sorry, I was wrong, I thought it was hard". You can't help but call things workarounds, or complicated, or get your knickers in a twist about having to use a language feature that for some reason you hate.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 17:09 +0100 |
| Message-ID | <11b2qv0$19h68$1@dont-email.me> |
| In reply to | #403272 |
On 18/10/2026 15:27, David Brown wrote:
> On 18/10/2026 15:33, bart wrote:
>> On 18/10/2026 12:22, David Brown wrote:
>>> To me, that is just as much gibberish as the original C.
>>
>> That doesn't matter - the problem is not even knowing what it represents.
>
> That is, shall we say, a strange attitude. Gibberish (since that seems
> to be the preferred term here) is gibberish, no matter the language or
> representation, and is equally meaningless and useless.
'Gibberish' here refers to the representation, whether the type being
described is made-up nonsense or real.
You may want to know what some complex type is for many reasons, you
don't necessarily need to understand what it means or why it was used.
(For example I might come across a type in a C API that I want to
convert to another language.)
>> (That it is an actual function is a surprise. That you can't easily
>> tell is crazy.)
>
> You can tell it very easy from the C - the final bit is parentheses.
Both actual function declarations and function pointers end in (...).
Function definitions will have { towards the end of the signature which
is more of a clue.
But it is telling that pretty much every language using C-style syntax
has chosen to use a keyword (fn, fun, func, function or other) to
introduce a function signature.
>> In practice there will be actual types that start to look like
>> gibberish, full of *, () and [] that must be in exactly the right place.
>
> Not in my code, or the code I work with - types are clear to me. Again,
> experiences can vary.
What are you saying here, that your types never involve * () or []? That
is hard to believe.
> (Of course the syntactical elements must be in
> the right place!)
Isn't that the problem? C makes it tricky. Here are two very
straightforward declarations from my projects:
ref []ichar stringtable # ichar is ref char
[N]ref proc(T) handlertable
These are the C versions:
char *(*stringtable)[];
void (*handlertable[N)(T);
They involve * () and [] that must all be in the right place, in the
right nesting order. In C, parentheses are used to alter precedences as
well as for parameter lists. This not a thing in LTR forms.
Additionally, in C, you can sometimes mix up the order of * and [], but
since a T* value can be indexed, and a T[] value can be dereferenced,
those errors might still compile.
So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm
that you shouldn't need to do X, Y and Z; if you do then it's a
language problem.
> Use a typedef. Or since C23, use type inference - that can save naming
> and identifying types when things get complex,
OK, that's a fifth kind of workaround! Although it is more of an
unrelated feature.
>> This should be simple enough to do in a language without needing to
>> follow some back-and-forth algorithm, or use an external tool, or need
>> to decompose them into multiple levels using 'typedef', or need to
>> disambiguate with parentheses.
>
> You just /have/ to whine, don't you? Whenever you complain - usually
I thought it was, for a change, a civil exchange up to now.
I'm saying that type syntax should useful without having to resort to
any of those four workarounds I mentioned.
If that happens because syntax choices (rather than genuine complexity)
would otherwise result in gibberish, then that is a failing in the language.
> complicated in C, and someone tells you how it can be handled simply and
> clearly,
No. Stuff like this is simple and clear:
ref proc
ref func -> void
* func()void
Since whatever the type, you can always read off exactly what it is from
left to right.
This is gibberish:
void(*)(void)
void(*)() (C23)
>unable to simply say "Okay, thanks - that's good to > know" or "Sorry,
I was wrong, I thought it was hard". You can't help
> but call things workarounds, or complicated, or get your knickers in a
> twist about having to use a language feature that for some reason you hate.
This one is universally disliked and even the language creators said it
was a mistake. I didn't realise that opinion was even controversial.
[toc] | [prev] | [next] | [standalone]
Page 17 of 31 — ← Prev page 1 … 15 16 [17] 18 19 … 31 Next page →
Back to top | Article view | comp.lang.c
csiph-web