Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #387724 > unrolled thread
| Started by | John Forkosh <john@somewhere.com> |
|---|---|
| First post | 2024-08-23 22:03 +0000 |
| Last post | 2024-08-26 02:33 +0000 |
| Articles | 20 on this page of 414 — 21 participants |
Back to article view | Back to comp.lang.c
Top 10 most common hard skills listed on resumes... John Forkosh <john@somewhere.com> - 2024-08-23 22:03 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-23 23:06 +0000
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-23 17:02 -0700
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-24 02:26 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-24 14:41 +0200
Re: Top 10 most common hard skills listed on resumes... John Forkosh <forkosh@somewhere.com> - 2024-08-25 12:09 +0000
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 17:06 +0300
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 10:54 -0400
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 18:10 +0300
Re: Top 10 most common hard skills listed on resumes... Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-26 21:36 +0100
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-25 18:47 +0200
Re: Top 10 most common hard skills listed on resumes... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-25 12:58 -0700
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-24 20:11 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-24 19:27 +0100
Re: Top 10 most common hard skills listed on resumes... Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-24 21:12 +0100
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-24 18:07 -0300
Re: Top 10 most common hard skills listed on resumes... John Forkosh <forkosh@somewhere.com> - 2024-08-25 12:18 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 10:50 -0400
Re: Top 10 most common hard skills listed on resumes... fir <fir@grunge.pl> - 2024-08-25 16:55 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-25 16:30 +0100
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 19:17 +0300
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-25 18:17 +0100
Re: Top 10 most common hard skills listed on resumes... tTh <tth@none.invalid> - 2024-08-25 18:20 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-25 18:26 +0100
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 14:21 +0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 13:40 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-28 14:51 +0100
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-29 10:41 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-30 03:18 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 05:41 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-26 12:05 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-26 13:30 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-26 14:54 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-26 12:32 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 13:07 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-28 00:49 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-28 01:39 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-28 15:57 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-28 19:26 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 00:43 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-29 11:35 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 13:35 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-29 14:10 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 16:13 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-29 15:40 +0000
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 16:45 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-29 15:58 +0000
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 17:06 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-29 18:08 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-29 13:30 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-29 22:29 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-29 15:03 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-29 23:45 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-29 16:32 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-30 00:29 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-30 02:34 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-30 06:44 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-30 13:41 -0700
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-31 07:08 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-31 12:45 -0400
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-31 14:03 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 09:45 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-01 10:44 -0700
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-01 18:47 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-01 15:01 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 13:11 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 13:14 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 14:17 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-31 19:11 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-31 19:32 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-31 16:04 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-31 15:10 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-01 13:15 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 06:30 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-31 15:31 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-01 00:37 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-31 18:17 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-31 20:01 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-31 20:26 -0700
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-01 03:04 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 13:07 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 06:39 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-08 10:12 -0400
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 16:37 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 10:46 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-09 07:03 -0400
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 13:06 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-09 08:21 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 05:46 -0700
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-09 17:29 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-09 14:25 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 05:56 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 06:57 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-17 19:02 +0200
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 16:26 -0700
Re: Top 10 most common hard skills listed on resumes... antispam@fricas.org - 2024-09-18 15:28 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-21 06:00 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-01 13:12 -0400
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-07 03:13 +0000
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-02 13:03 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-02 13:39 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-02 16:22 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-02 20:43 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-02 15:31 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-02 23:48 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-02 15:52 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-02 23:59 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-02 19:44 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-02 20:04 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-03 16:08 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 18:00 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-29 21:24 -0700
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-05 15:21 +0000
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-05 16:54 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-05 17:37 -0400
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-06 10:35 +0100
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-06 14:05 +0300
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-06 07:56 -0700
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-08 11:53 +0300
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 12:08 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-06 13:23 -0400
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-06 19:58 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-06 23:38 +0100
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 05:23 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-05 19:10 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-06 10:19 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-06 12:34 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-07 01:44 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-07 11:53 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-08 00:05 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 12:05 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-08 18:13 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 21:18 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 01:19 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-09 12:31 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-10 04:40 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 11:52 +0100
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 13:55 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 14:30 +0100
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-10 16:53 +0300
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 16:18 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-12 21:09 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 22:01 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 14:15 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 23:33 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 16:20 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-09 00:25 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 00:29 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-09 02:07 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 03:04 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 11:14 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 16:46 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 19:21 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 22:04 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 09:04 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-10 13:56 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 16:28 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-11 23:59 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-12 13:45 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-12 21:28 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-13 16:24 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-11 17:12 -0400
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 12:08 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-09 16:56 -0400
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 18:10 -0700
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 02:06 +0000
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 20:14 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-09 15:58 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 16:21 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-09 17:57 +0100
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 19:37 +0200
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-09 18:46 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 21:04 +0200
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 13:16 -0700
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 09:19 +0200
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-10 12:18 -0700
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 22:10 +0200
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-09 22:33 +0000
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 16:24 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 18:52 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 20:07 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 20:46 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 21:39 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-14 15:07 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-14 15:51 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-10 04:19 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-10 12:49 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-14 15:13 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-09 00:09 -0400
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 16:50 +0000
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-09 13:05 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 11:01 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-09 12:28 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-09 12:29 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 05:53 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 05:58 +0200
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-08 17:14 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 17:36 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-10 15:24 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 17:28 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-11 01:22 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-11 10:34 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-11 15:15 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-11 16:51 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-12 00:32 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-12 01:40 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-13 01:01 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-11 17:20 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-15 20:05 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-16 10:58 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-16 11:30 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-16 14:42 +0100
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-16 14:30 +0000
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-16 17:40 +0300
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-16 12:19 -0400
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-16 19:13 +0200
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-17 17:32 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-18 09:44 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-17 14:08 -0400
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-18 10:05 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-18 07:27 -0400
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-18 14:15 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-16 19:26 +0200
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-09-17 09:27 -0400
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-12 02:11 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-12 12:27 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-12 12:38 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-12 20:54 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-12 13:51 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-13 14:18 +0100
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 05:44 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-08 11:58 +0300
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 11:27 +0100
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-08 16:34 +0300
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-08 16:39 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 17:44 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 00:07 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 16:53 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 01:20 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-09 17:47 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 17:51 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-10 15:15 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-10 17:58 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-11 01:02 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-11 10:52 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-12 00:47 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-12 12:00 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-12 12:39 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-12 12:39 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-13 00:46 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-13 15:02 +0100
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-13 15:12 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-09-13 23:01 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-10 13:05 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 09:47 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-09 18:27 +0100
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 16:40 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-08 20:09 +0300
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 11:18 +0100
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 17:22 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-08 19:01 +0100
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-08 18:39 +0000
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 12:19 -0700
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-08 11:50 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-06 04:53 -0700
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-09-06 14:48 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-09 17:57 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-29 14:26 -0400
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-29 23:53 +0100
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-30 00:08 +0100
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-30 13:28 -0400
Re: Top 10 most common hard skills listed on resumes... Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-30 17:36 +0000
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-30 14:37 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-31 02:18 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-31 02:11 -0700
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-30 06:40 -0700
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-29 23:43 +0300
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-26 12:30 -0700
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 21:41 +0000
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-27 14:18 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-27 12:22 -0700
Re: Top 10 most common hard skills listed on resumes... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-27 12:50 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-28 00:15 +0100
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-27 17:46 -0700
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-01 07:07 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-27 18:19 -0700
Re: Top 10 most common hard skills listed on resumes... Ben Bacarisse <ben@bsb.me.uk> - 2024-08-28 15:47 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 08:18 -0700
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 21:40 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 05:40 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-25 17:59 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 19:28 +0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-25 20:12 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-25 19:24 +0100
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-26 03:43 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-27 01:33 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-27 00:47 +0100
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 07:09 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 09:37 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 10:36 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 11:32 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 11:47 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 14:51 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 15:14 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 20:54 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 07:02 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-28 11:26 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 11:30 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 11:49 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 13:43 +0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 13:02 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 15:06 +0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 14:40 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-30 09:37 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 13:49 +0300
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-28 14:25 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-08 21:34 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 11:34 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 14:36 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-09 17:11 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-09 23:58 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-10 11:20 +0200
Re: Top 10 most common hard skills listed on resumes... Waldek Hebisch <antispam@fricas.org> - 2024-09-13 02:16 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-09-13 16:25 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-09-13 18:05 +0300
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-09-13 17:32 +0000
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 13:55 +0300
Re: Top 10 most common hard skills listed on resumes... Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-27 21:13 +0100
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-08-27 21:07 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 07:03 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-28 14:01 +0300
Re: Top 10 most common hard skills listed on resumes... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-27 12:39 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-28 18:48 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 22:00 +0300
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 05:39 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 17:16 -0700
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 07:10 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 05:17 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 07:23 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 06:47 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 08:58 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 23:44 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 06:59 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-28 05:39 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 08:04 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-30 03:21 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-30 10:43 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-31 00:01 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-31 06:44 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-31 22:30 +0000
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-08-30 14:38 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-31 00:02 +0000
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-09-01 15:19 +0000
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-09-01 15:22 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-01 23:48 +0000
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 08:09 -0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 13:32 +0200
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 08:47 -0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 14:58 +0200
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 10:35 -0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 15:45 +0200
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 10:52 -0300
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 11:04 -0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 16:18 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-28 16:51 +0100
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 18:58 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 16:55 +0200
Re: Top 10 most common hard skills listed on resumes... Thiago Adams <thiago.adams@gmail.com> - 2024-08-28 14:02 -0300
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 19:13 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-28 19:29 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 19:33 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-27 15:06 +0300
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-27 12:49 +0300
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-27 12:44 +0300
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 23:50 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 06:31 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-25 18:28 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 05:38 +0000
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-25 18:23 +0200
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-25 17:58 +0200
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-25 18:51 +0200
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-25 18:36 +0200
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-25 20:11 +0300
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-25 17:48 -0700
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-26 10:54 +0300
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 17:55 -0700
Re: Top 10 most common hard skills listed on resumes... Michael S <already5chosen@yahoo.com> - 2024-08-27 12:33 +0300
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-27 19:38 -0700
Re: Top 10 most common hard skills listed on resumes... James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-27 09:45 -0400
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-31 03:56 -0700
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-26 15:46 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 04:36 +0000
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 09:44 +0200
Re: Top 10 most common hard skills listed on resumes... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-27 12:16 -0700
Re: Top 10 most common hard skills listed on resumes... David Brown <david.brown@hesbynett.no> - 2024-08-27 21:53 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 23:55 +0000
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 23:53 +0000
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-28 01:28 +0100
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-28 05:45 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-28 09:49 +0200
Re: Top 10 most common hard skills listed on resumes... Bart <bc@freeuk.com> - 2024-08-26 15:13 +0100
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 18:16 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-28 19:57 +0200
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-08-28 18:37 +0000
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-28 23:18 +0200
Re: Top 10 most common hard skills listed on resumes... scott@slp53.sl.home (Scott Lurndal) - 2024-08-28 22:11 +0000
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 13:42 -0700
Re: Top 10 most common hard skills listed on resumes... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-08-28 23:22 +0200
Re: Top 10 most common hard skills listed on resumes... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-28 22:36 -0700
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-27 04:34 +0000
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 11:11 +0200
Re: Top 10 most common hard skills listed on resumes... Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-27 21:20 +0100
Re: Top 10 most common hard skills listed on resumes... Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-31 10:14 +0200
Re: Top 10 most common hard skills listed on resumes... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-26 02:33 +0000
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-08-29 11:35 +0100 |
| Message-ID | <vapitn$3u1ub$1@dont-email.me> |
| In reply to | #387944 |
On 29/08/2024 00:43, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 28/08/2024 15:57, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 28/08/2024 00:49, Ben Bacarisse wrote:
>>>
>>>>> Indeed, and BLISS is not like that. I had hoped to shed some light on
>>>>> why there is some logic to BLISS's rather idiosyncratic design.
>>>>>
>>>>>> Given a declaration like 'int A' then:
>>>>>>
>>>>>> BLISS C
>>>>>>
>>>>>> Read or write A's value .A A
>>>>> I don't think that's right. To change the value at address A (what I
>>>>> think you mean by "write A's value") you write
>>>>> A = 42;
>>>>> in BLISS. And to add one to the value at address A you write
>>>>> A = .A + 1;
>>>>
>>>> OK. That's just makes it more bizarre than I'd thought.
>>> Curious. It's what makes it consistent, though it is definitely an
>>> uncommon approach.
>>>
>>>> The example I saw
>>>> included these lines:
>>>>
>>>> GETNUM(X); ! returns a value via X
>>>> Y = STEP(.X);
>>>> PUTNUM(.Y)
>>>>
>>>> So in an rvalue context: X reads its address; while .X reads its
>>>> value.
>>> The whole point is to remove the two contexts. A variable name is
>>> /always/ an lvalue (which is why it can be assigned). C has an implicit
>>> lvalue to rvalue conversion in the contexts you have come to expect it.
>>> BLISS does not. You always need a dot to convert to an rvalue.
>>
>> This is the kind of thing I meant a few posts back. You don't need to take
>> A (which refers to some place where you can store values), and tell it to
>> fetch that value. Most HLLs will do that without being told.
>>
>> (My point was that that was a distinguishing feature of HLLs, which is
>> missing in Forth for example.)
>
> We are talking at cross purposes then. I was not addressing anything
> about your view of what makes an HLL.
>
>>>> But in an lvalue one: Y writes its value; .Y may not be defined
>>>>
>>>> It looks asymmetric. C like most languages is symmetric, you write 'A = A'
>>>> with the same syntax on both sides.
>>> Since assignment is inherently asymmetric (you can't write 3 = A but you
>>> can write A = 3) C's syntactic symmetry hides a semantic difference.
>>> What is needed on the two sides is not the same.
>>
>> I would argue that it is exactly the same.
>
> How do you argue that, given that A=3 is allowed and 3=A is not?
I explained that. LHS and RHS can be identical terms for assignment in
pretty much every aspect, but there are extra constraints on the LHS.
In the case of :
(c?a:b) = (z?x:y);
C won't allow it, but some other languages will.
Remember that the programmer can only express their intentions in the
form of syntax.
> ...
>>>> I assume that in BLISS, A = A is legal, but does something odd like copy
>>>> A's address into itself.
>>> What's odd about that? And why call is a copy operation? Do you think
>>> of A = 42 as a copy operation? BLISS is a low-level system language.
>>
>> Why do you mean by call?
>
> Typo. I meant to write... And why call /it/ a copy-operation? Do you
> think of A = 42 as a copy operation?
If '=' means assignment, then what else is it?
Depending on language, it might be shallow, or deep, or something
depending how it works or what is being assigned.
According to Wikipedia:
"In computer programming, an assignment statement sets and/or re-sets
the value stored in the storage location(s) denoted by a variable name;
in other words, it COPIES a value into the variable"
(My emphasis.)
I don't know why you're always so contradictory. Is it a game trying to
catch me out on some pendanty? It seems to be popular here.
This subthread started with me asking which HLL goes between Assembly
and C, if C was supposedly mid-level. I don't know how it got on
discussing what exactly assignment means.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-08-29 13:35 +0100 |
| Message-ID | <87o75bwlp8.fsf@bsb.me.uk> |
| In reply to | #387967 |
Bart <bc@freeuk.com> writes: > On 29/08/2024 00:43, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 28/08/2024 15:57, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 28/08/2024 00:49, Ben Bacarisse wrote: >>>> >>>>>> Indeed, and BLISS is not like that. I had hoped to shed some light on >>>>>> why there is some logic to BLISS's rather idiosyncratic design. >>>>>> >>>>>>> Given a declaration like 'int A' then: >>>>>>> >>>>>>> BLISS C >>>>>>> >>>>>>> Read or write A's value .A A >>>>>> I don't think that's right. To change the value at address A (what I >>>>>> think you mean by "write A's value") you write >>>>>> A = 42; >>>>>> in BLISS. And to add one to the value at address A you write >>>>>> A = .A + 1; >>>>> >>>>> OK. That's just makes it more bizarre than I'd thought. >>>> Curious. It's what makes it consistent, though it is definitely an >>>> uncommon approach. >>>> >>>>> The example I saw >>>>> included these lines: >>>>> >>>>> GETNUM(X); ! returns a value via X >>>>> Y = STEP(.X); >>>>> PUTNUM(.Y) >>>>> >>>>> So in an rvalue context: X reads its address; while .X reads its >>>>> value. >>>> The whole point is to remove the two contexts. A variable name is >>>> /always/ an lvalue (which is why it can be assigned). C has an implicit >>>> lvalue to rvalue conversion in the contexts you have come to expect it. >>>> BLISS does not. You always need a dot to convert to an rvalue. >>> >>> This is the kind of thing I meant a few posts back. You don't need to take >>> A (which refers to some place where you can store values), and tell it to >>> fetch that value. Most HLLs will do that without being told. >>> >>> (My point was that that was a distinguishing feature of HLLs, which is >>> missing in Forth for example.) >> We are talking at cross purposes then. I was not addressing anything >> about your view of what makes an HLL. >> >>>>> But in an lvalue one: Y writes its value; .Y may not be defined >>>>> >>>>> It looks asymmetric. C like most languages is symmetric, you write 'A = A' >>>>> with the same syntax on both sides. >>>> Since assignment is inherently asymmetric (you can't write 3 = A but you >>>> can write A = 3) C's syntactic symmetry hides a semantic difference. >>>> What is needed on the two sides is not the same. >>> >>> I would argue that it is exactly the same. >> How do you argue that, given that A=3 is allowed and 3=A is not? > > I explained that. LHS and RHS can be identical terms for assignment in > pretty much every aspect, but there are extra constraints on the LHS. So you use "exactly the same" to mean "exactly the same except for the differences". I don't think this point needs any more discussion, do you? > In the case of : > > (c?a:b) = (z?x:y); > > C won't allow it, but some other languages will. > > Remember that the programmer can only express their intentions in the form > of syntax. > >> ... >>>>> I assume that in BLISS, A = A is legal, but does something odd like copy >>>>> A's address into itself. >>>> What's odd about that? And why call is a copy operation? Do you think >>>> of A = 42 as a copy operation? BLISS is a low-level system language. >>> >>> Why do you mean by call? >> Typo. I meant to write... And why call /it/ a copy-operation? Do you >> think of A = 42 as a copy operation? > > If '=' means assignment, then what else is it? That's was my question. You called it (in BLISS) a "copy" operation. Why did you use that term rather than just saying that "A = A assigns that address of A to the location A". I'm trying to find out if your use of the word copy rather than assign is interesting in some way. > I don't know why you're always so contradictory. Is it a game trying to > catch me out on some pendanty? It seems to be popular here. I wanted to explain how BLISS gets rid of the lvalue/rvalue distinction because you seemed to have misunderstood it. > This subthread started with me asking which HLL goes between Assembly and > C, if C was supposedly mid-level. I don't know how it got on discussing > what exactly assignment means. Because, unlike you, I want to understand you before commenting. It was a trivial question (made more complex by a typo if mine, for which I'm sorry). You found BLISS's meaning of A = A to be "odd" and you explained the "odd" by using the word "copy" rather than "assigns". I just wanted to know if there was more behind your use of the word. I don't think there is anything that needs further explanation because I think you just said "copy" when "assigns" would have done. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-08-29 14:10 +0100 |
| Message-ID | <vaps06$3vg8l$1@dont-email.me> |
| In reply to | #387979 |
On 29/08/2024 13:35, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> I explained that. LHS and RHS can be identical terms for assignment in
>> pretty much every aspect, but there are extra constraints on the LHS.
>
> So you use "exactly the same" to mean "exactly the same except for the
> differences".
No, I do mean exactly the same, both in terms of syntax and (in my
implementations, which are likely typical) internal representation of
those terms.
There are no differences other than where the type system says your code
is invalid. So are no differences when considering only valid programs.
This program in my language:
42 := 42
is valid syntax. It passes the next step too. It is caught later on.
Other languages/implementations may object earlier.
Some may make it invalid syntax via a stricter grammar, but if I try '42
= 42' in C, then I don't get a syntax error; I get a message about 42
not being an lvalue. (From what I can make of C's grammar, a constant is
allowed on the left of an assignment operator.)
>> I don't know why you're always so contradictory. Is it a game trying to
>> catch me out on some pendanty? It seems to be popular here.
>
> I wanted to explain how BLISS gets rid of the lvalue/rvalue distinction
> because you seemed to have misunderstood it.
It seems to make a dog's dinner of it. I think even in Lisp you just
write (setf a a) or something like that. And here you are assigning a's
value to itself.
(I never came across BLISS even though I used DEC equipment. I did
implement a lower level language for PDP10 though, more of a HLA. But
even there, you would write A => A to asssign A's value to itself. I
can't remember how you obtained a reference to A.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-08-29 16:13 +0100 |
| Message-ID | <871q27weeh.fsf@bsb.me.uk> |
| In reply to | #387982 |
Bart <bc@freeuk.com> writes: > On 29/08/2024 13:35, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> I explained that. LHS and RHS can be identical terms for assignment in >>> pretty much every aspect, but there are extra constraints on the LHS. >> So you use "exactly the same" to mean "exactly the same except for the >> differences". > > No, I do mean exactly the same, both in terms of syntax and (in my > implementations, which are likely typical) internal representation of those > terms. > > There are no differences other than where the type system says your code is > invalid. So are no differences when considering only valid programs. > > This program in my language: > > 42 := 42 > > is valid syntax. So what? We were talking about assignment in C. You cut the two previous quotes where it was clear we were talking about C. This is not an honest thing to do. You are arguing for the sake if it, and in a dishonest way too. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-08-29 15:40 +0000 |
| Message-ID | <20240829083200.195@kylheku.com> |
| In reply to | #387992 |
On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: > Bart <bc@freeuk.com> writes: > >> On 29/08/2024 13:35, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> I explained that. LHS and RHS can be identical terms for assignment in >>>> pretty much every aspect, but there are extra constraints on the LHS. >>> So you use "exactly the same" to mean "exactly the same except for the >>> differences". >> >> No, I do mean exactly the same, both in terms of syntax and (in my >> implementations, which are likely typical) internal representation of those >> terms. >> >> There are no differences other than where the type system says your code is >> invalid. So are no differences when considering only valid programs. >> >> This program in my language: >> >> 42 := 42 >> >> is valid syntax. > > So what? We were talking about assignment in C. You cut the two > previous quotes where it was clear we were talking about C. This is not > an honest thing to do. You are arguing for the sake if it, and in a > dishonest way too. It's also valid syntax in C, with a constraint violation that can be "caught later on" in an implementation of C, just like in Bart's language. ISO C doesn't say anything about when errors are caught, other than it being associated with translation phase 7: White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token. The resulting tokens are syntactically and semantically analyzed and translated as a translation unit. A constraint violtion like the need for an lvalue could be caught during the activity denoted by "semantically analyzed" rather than that denoted by "syntactically analyzed" which would count as "later on" with regard to syntax. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-08-29 16:45 +0100 |
| Message-ID | <87v7zjuyd8.fsf@bsb.me.uk> |
| In reply to | #387995 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 29/08/2024 13:35, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> I explained that. LHS and RHS can be identical terms for assignment in >>>>> pretty much every aspect, but there are extra constraints on the LHS. >>>> So you use "exactly the same" to mean "exactly the same except for the >>>> differences". >>> >>> No, I do mean exactly the same, both in terms of syntax and (in my >>> implementations, which are likely typical) internal representation of those >>> terms. >>> >>> There are no differences other than where the type system says your code is >>> invalid. So are no differences when considering only valid programs. >>> >>> This program in my language: >>> >>> 42 := 42 >>> >>> is valid syntax. >> >> So what? We were talking about assignment in C. You cut the two >> previous quotes where it was clear we were talking about C. This is not >> an honest thing to do. You are arguing for the sake if it, and in a >> dishonest way too. > > It's also valid syntax in C, with a constraint violation that can be > "caught later on" in an implementation of C, just like in Bart's > language. Have you taken Bart's bait and are now discussing a narrower context? The claim that C's assignment is symmetric and what is required on the two sides is exactly the same is junk. C's assignment has different syntax on each side, and what is required is even more strict. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-08-29 15:58 +0000 |
| Message-ID | <20240829084851.962@kylheku.com> |
| In reply to | #387996 |
On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: > Kaz Kylheku <643-408-1753@kylheku.com> writes: > >> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 29/08/2024 13:35, Ben Bacarisse wrote: >>>>> Bart <bc@freeuk.com> writes: >>>> >>>>>> I explained that. LHS and RHS can be identical terms for assignment in >>>>>> pretty much every aspect, but there are extra constraints on the LHS. >>>>> So you use "exactly the same" to mean "exactly the same except for the >>>>> differences". >>>> >>>> No, I do mean exactly the same, both in terms of syntax and (in my >>>> implementations, which are likely typical) internal representation of those >>>> terms. >>>> >>>> There are no differences other than where the type system says your code is >>>> invalid. So are no differences when considering only valid programs. >>>> >>>> This program in my language: >>>> >>>> 42 := 42 >>>> >>>> is valid syntax. >>> >>> So what? We were talking about assignment in C. You cut the two >>> previous quotes where it was clear we were talking about C. This is not >>> an honest thing to do. You are arguing for the sake if it, and in a >>> dishonest way too. >> >> It's also valid syntax in C, with a constraint violation that can be >> "caught later on" in an implementation of C, just like in Bart's >> language. > > Have you taken Bart's bait and are now discussing a narrower context? > > The claim that C's assignment is symmetric and what is required on the > two sides is exactly the same is junk. C's assignment has different > syntax on each side, and what is required is even more strict. In the ISO C grammar for assignment, there is a "unary expression" on the left and an "assignment expression" on the right. That's just a particular factoring of the grammar that implementors don't have to follow, if the correct results are produced. Under a parser generator tool we could have a production rule like expr '=' expr , where the '=' token has an elsewhere-declared associativity and precedence. The basic idea that the same syntactic kind of thing is on both sides of a C assignment (with an additional lvalue constraint) is valid; it's just not literally true if we are discussing the details of how ISO C expresses the grammar. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-08-29 17:06 +0100 |
| Message-ID | <87mskvuxe9.fsf@bsb.me.uk> |
| In reply to | #387998 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >> >>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 29/08/2024 13:35, Ben Bacarisse wrote: >>>>>> Bart <bc@freeuk.com> writes: >>>>> >>>>>>> I explained that. LHS and RHS can be identical terms for assignment in >>>>>>> pretty much every aspect, but there are extra constraints on the LHS. >>>>>> So you use "exactly the same" to mean "exactly the same except for the >>>>>> differences". >>>>> >>>>> No, I do mean exactly the same, both in terms of syntax and (in my >>>>> implementations, which are likely typical) internal representation of those >>>>> terms. >>>>> >>>>> There are no differences other than where the type system says your code is >>>>> invalid. So are no differences when considering only valid programs. >>>>> >>>>> This program in my language: >>>>> >>>>> 42 := 42 >>>>> >>>>> is valid syntax. >>>> >>>> So what? We were talking about assignment in C. You cut the two >>>> previous quotes where it was clear we were talking about C. This is not >>>> an honest thing to do. You are arguing for the sake if it, and in a >>>> dishonest way too. >>> >>> It's also valid syntax in C, with a constraint violation that can be >>> "caught later on" in an implementation of C, just like in Bart's >>> language. >> >> Have you taken Bart's bait and are now discussing a narrower context? >> >> The claim that C's assignment is symmetric and what is required on the >> two sides is exactly the same is junk. C's assignment has different >> syntax on each side, and what is required is even more strict. > > In the ISO C grammar for assignment, there is a "unary expression" on > the left and an "assignment expression" on the right. That's just a > particular factoring of the grammar that implementors don't have to > follow, if the correct results are produced. I can't see what it is you object to in what I wrote. I don't disagree with anything you are saying (the "correct result" being to reject a program that has, syntactically, the wrong thing on the left hand side). > Under a parser generator tool we could have a production rule like > expr '=' expr , where the '=' token has an elsewhere-declared > associativity and precedence. > > The basic idea that the same syntactic kind of thing is on both sides of > a C assignment (with an additional lvalue constraint) is valid; > it's just not literally true if we are discussing the details of how > ISO C expresses the grammar. A C program that has the wrong syntax (for example x+1) on the left hand side of an assignment must be rejected. I'm not relying on some fussy definition about how the syntax is written but making a point that what is required on each side is not the exactly same thing. Do you really disagree with that? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-08-29 18:08 +0100 |
| Message-ID | <vaq9tu$1te8$1@dont-email.me> |
| In reply to | #387999 |
On 29/08/2024 17:06, Ben Bacarisse wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>
>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 29/08/2024 13:35, Ben Bacarisse wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>>>> I explained that. LHS and RHS can be identical terms for assignment in
>>>>>>>> pretty much every aspect, but there are extra constraints on the LHS.
>>>>>>> So you use "exactly the same" to mean "exactly the same except for the
>>>>>>> differences".
>>>>>>
>>>>>> No, I do mean exactly the same, both in terms of syntax and (in my
>>>>>> implementations, which are likely typical) internal representation of those
>>>>>> terms.
>>>>>>
>>>>>> There are no differences other than where the type system says your code is
>>>>>> invalid. So are no differences when considering only valid programs.
>>>>>>
>>>>>> This program in my language:
>>>>>>
>>>>>> 42 := 42
>>>>>>
>>>>>> is valid syntax.
>>>>>
>>>>> So what? We were talking about assignment in C. You cut the two
>>>>> previous quotes where it was clear we were talking about C. This is not
>>>>> an honest thing to do. You are arguing for the sake if it, and in a
>>>>> dishonest way too.
>>>>
>>>> It's also valid syntax in C, with a constraint violation that can be
>>>> "caught later on" in an implementation of C, just like in Bart's
>>>> language.
>>>
>>> Have you taken Bart's bait and are now discussing a narrower context?
>>>
>>> The claim that C's assignment is symmetric and what is required on the
>>> two sides is exactly the same is junk. C's assignment has different
>>> syntax on each side, and what is required is even more strict.
>>
>> In the ISO C grammar for assignment, there is a "unary expression" on
>> the left and an "assignment expression" on the right. That's just a
>> particular factoring of the grammar that implementors don't have to
>> follow, if the correct results are produced.
>
> I can't see what it is you object to in what I wrote. I don't disagree
> with anything you are saying (the "correct result" being to reject a
> program that has, syntactically, the wrong thing on the left hand side).
>
>> Under a parser generator tool we could have a production rule like
>> expr '=' expr , where the '=' token has an elsewhere-declared
>> associativity and precedence.
>>
>> The basic idea that the same syntactic kind of thing is on both sides of
>> a C assignment (with an additional lvalue constraint) is valid;
>> it's just not literally true if we are discussing the details of how
>> ISO C expresses the grammar.
>
> A C program that has the wrong syntax (for example x+1) on the left hand
> side of an assignment must be rejected. I'm not relying on some fussy
> definition about how the syntax is written but making a point that what
> is required on each side is not the exactly same thing. Do you really
> disagree with that?
>
So what exactly is different about the LHS and RHS here:
A = A;
(In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A' is
also valid, there is a hidden mismatch in indirection levels between
left and right. It is asymmetric while in C it is symmetric, although
seem to disagree on that latter point.)
> A C program that has the wrong syntax (for example x+1) on the left hand
> side of an assignment must be rejected.
I think that these (with x, y having compatible scalar types):
x + 1 = y;
(x + 1) = y; // in case above was parsed differently
are both valid syntax in C. It will fail for a different reason: an '+'
term is not a valid lvalue.
So will this:
x = z;
when x and y have incompatible types, even though you must agree the
syntax is valid, and even when x is a valid lvalue.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-29 13:30 -0700 |
| Message-ID | <87h6b39imm.fsf@nosuchdomain.example.com> |
| In reply to | #388004 |
Bart <bc@freeuk.com> writes:
[...]
> So what exactly is different about the LHS and RHS here:
>
> A = A;
The RHS is evaluated to determine the current value stored in the object
named A. The LHS is evaluated to determine the object that's designated
by the name A; its current value is irrelevant.
In C terms, the RHS undergoes *lvalue conversion*, where an expression
that's an lvalue is converted to the value stored in the designated
object. The LHS does not undergo lvalue conversion.
> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A'
> is also valid, there is a hidden mismatch in indirection levels
> between left and right. It is asymmetric while in C it is symmetric,
> although seem to disagree on that latter point.)
Because BLISS, unlike C, does not have implicit lvalue conversion; the
prefix "." operator performs explicit lvalue conversion. I presume the
"." operator isn't specific to assignments.
In C, the LHS and RHS are evaluated differently. In BLISS, they're
evaluated in the same way, requiring an explicit operator to do what
done implicitly by context in C. I'd call the former asymmetric and the
latter symmetric.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-08-29 22:29 +0100 |
| Message-ID | <vaqp83$4jjo$1@dont-email.me> |
| In reply to | #388013 |
On 29/08/2024 21:30, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> So what exactly is different about the LHS and RHS here: >> >> A = A; > > The RHS is evaluated to determine the current value stored in the object > named A. The LHS is evaluated to determine the object that's designated > by the name A; its current value is irrelevant. Sure, but the same thing happens on both sides: one ends up performing a Read via that Lvalue, and the other does a Write via that Lvalue. > In C terms, the RHS undergoes *lvalue conversion*, where an expression > that's an lvalue is converted to the value stored in the designated > object. The LHS does not undergo lvalue conversion. > >> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A' >> is also valid, there is a hidden mismatch in indirection levels >> between left and right. It is asymmetric while in C it is symmetric, >> although seem to disagree on that latter point.) > > Because BLISS, unlike C, does not have implicit lvalue conversion; the > prefix "." operator performs explicit lvalue conversion. I presume the > "." operator isn't specific to assignments. But it must have that conversion on the LHS, otherwise it's A's address that is written to rather than its value, which doesn't make sense. That's why I said it was asymmetric; the RHS needs an explicit operator, the LHS doesn't. I'd initially thought that both sides needed it. > In C, the LHS and RHS are evaluated differently. In BLISS, they're > evaluated in the same way, requiring an explicit operator to do what > done implicitly by context in C. I'd call the former asymmetric and the > latter symmetric. It sounds like you've got it backwards. How can A = B be asymmetric, but A = .B be symmetric? Lots of people like to be contrary in this group!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-29 15:03 -0700 |
| Message-ID | <878qwf9ec4.fsf@nosuchdomain.example.com> |
| In reply to | #388018 |
Bart <bc@freeuk.com> writes:
> On 29/08/2024 21:30, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> So what exactly is different about the LHS and RHS here:
>>>
>>> A = A;
>> The RHS is evaluated to determine the current value stored in the
>> object
>> named A. The LHS is evaluated to determine the object that's designated
>> by the name A; its current value is irrelevant.
>
> Sure, but the same thing happens on both sides: one ends up performing
> a Read via that Lvalue, and the other does a Write via that Lvalue.
The read is done by converting the lvalue to its value, which is not an
lvalue. Please read the discussion of "lvalue conversion" in the C
standard.
>> In C terms, the RHS undergoes *lvalue conversion*, where an expression
>> that's an lvalue is converted to the value stored in the designated
>> object. The LHS does not undergo lvalue conversion.
>>
>>> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A'
>>> is also valid, there is a hidden mismatch in indirection levels
>>> between left and right. It is asymmetric while in C it is symmetric,
>>> although seem to disagree on that latter point.)
>> Because BLISS, unlike C, does not have implicit lvalue conversion;
>> the
>> prefix "." operator performs explicit lvalue conversion. I presume the
>> "." operator isn't specific to assignments.
>
> But it must have that conversion on the LHS, otherwise it's A's
> address that is written to rather than its value, which doesn't make
> sense. That's why I said it was asymmetric; the RHS needs an explicit
> operator, the LHS doesn't.
No, the address isn't written. The object is written.
The RHS evaluation determines the value currently stored in the object.
The LHS evaluation does not. That's the asymmetry.
In BLISS, the evaluation of the expression A determines the object that
the name A designates. In C, it can either do that *or* it can extract
the value currently stored in that object.
> I'd initially thought that both sides needed it.
>
>> In C, the LHS and RHS are evaluated differently. In BLISS, they're
>> evaluated in the same way, requiring an explicit operator to do what
>> done implicitly by context in C. I'd call the former asymmetric and the
>> latter symmetric.
>
> It sounds like you've got it backwards.
>
> How can A = B be asymmetric, but A = .B be symmetric?
We're talking about the "=" operator, not about a particular instance of
it.
The "=" operation in C is asymmetric because it treats the two operands
differently based on their context. The "=" operation is BLISS is
symmetric because it treats them the same (requiring an explicit lvalue
conversion on the RHS if you want the value of A).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-08-29 23:45 +0100 |
| Message-ID | <vaqtms$55ns$1@dont-email.me> |
| In reply to | #388019 |
On 29/08/2024 23:03, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/08/2024 21:30, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> So what exactly is different about the LHS and RHS here:
>>>>
>>>> A = A;
>>> The RHS is evaluated to determine the current value stored in the
>>> object
>>> named A. The LHS is evaluated to determine the object that's designated
>>> by the name A; its current value is irrelevant.
>>
>> Sure, but the same thing happens on both sides: one ends up performing
>> a Read via that Lvalue, and the other does a Write via that Lvalue.
>
> The read is done by converting the lvalue to its value, which is not an
> lvalue. Please read the discussion of "lvalue conversion" in the C
> standard.
>
>>> In C terms, the RHS undergoes *lvalue conversion*, where an expression
>>> that's an lvalue is converted to the value stored in the designated
>>> object. The LHS does not undergo lvalue conversion.
>>>
>>>> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A'
>>>> is also valid, there is a hidden mismatch in indirection levels
>>>> between left and right. It is asymmetric while in C it is symmetric,
>>>> although seem to disagree on that latter point.)
>>> Because BLISS, unlike C, does not have implicit lvalue conversion;
>>> the
>>> prefix "." operator performs explicit lvalue conversion. I presume the
>>> "." operator isn't specific to assignments.
>>
>> But it must have that conversion on the LHS, otherwise it's A's
>> address that is written to rather than its value, which doesn't make
>> sense. That's why I said it was asymmetric; the RHS needs an explicit
>> operator, the LHS doesn't.
>
> No, the address isn't written. The object is written.
>
> The RHS evaluation determines the value currently stored in the object.
> The LHS evaluation does not. That's the asymmetry.
>
> In BLISS, the evaluation of the expression A determines the object that
> the name A designates. In C, it can either do that *or* it can extract
> the value currently stored in that object.
So if C was to behave the same way as BLISS:
int a, b, c;
b = 23; // sets b to 23
a = *b; // sets a to that 23 in b
c = *a + *b; // sets c to 46
a = b; // attempts to set a to b's address (&b)
You would say that this is now symmetric, but C normal C wasn't?
I get you...
... not really! We'll just have to disagree. My comments are based on
having implemented this stuff myriad times on multiple targets, but I
must have obviously have been misunderstanding it all that time.
Opening a drawer A to put something in, is a totally different thing to
opening the same drawer A to take something out; of course!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-29 16:32 -0700 |
| Message-ID | <874j72aos8.fsf@nosuchdomain.example.com> |
| In reply to | #388020 |
Bart <bc@freeuk.com> writes:
[...]
> ... not really! We'll just have to disagree.
[...]
OK.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-08-30 00:29 +0100 |
| Message-ID | <875xrivrg0.fsf@bsb.me.uk> |
| In reply to | #388004 |
Bart <bc@freeuk.com> writes: > On 29/08/2024 17:06, Ben Bacarisse wrote: >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >> >>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>> >>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>> Bart <bc@freeuk.com> writes: >>>>>> >>>>>>> On 29/08/2024 13:35, Ben Bacarisse wrote: >>>>>>>> Bart <bc@freeuk.com> writes: >>>>>>> >>>>>>>>> I explained that. LHS and RHS can be identical terms for assignment in >>>>>>>>> pretty much every aspect, but there are extra constraints on the LHS. >>>>>>>> So you use "exactly the same" to mean "exactly the same except for the >>>>>>>> differences". >>>>>>> >>>>>>> No, I do mean exactly the same, both in terms of syntax and (in my >>>>>>> implementations, which are likely typical) internal >>>>>>> representation of those >>>>>>> terms. >>>>>>> >>>>>>> There are no differences other than where the type system says >>>>>>> your code is >>>>>>> invalid. So are no differences when considering only valid programs. >>>>>>> >>>>>>> This program in my language: >>>>>>> >>>>>>> 42 := 42 >>>>>>> >>>>>>> is valid syntax. >>>>>> >>>>>> So what? We were talking about assignment in C. You cut the two >>>>>> previous quotes where it was clear we were talking about C. This is not >>>>>> an honest thing to do. You are arguing for the sake if it, and in a >>>>>> dishonest way too. >>>>> >>>>> It's also valid syntax in C, with a constraint violation that can be >>>>> "caught later on" in an implementation of C, just like in Bart's >>>>> language. >>>> >>>> Have you taken Bart's bait and are now discussing a narrower context? >>>> >>>> The claim that C's assignment is symmetric and what is required on the >>>> two sides is exactly the same is junk. C's assignment has different >>>> syntax on each side, and what is required is even more strict. >>> >>> In the ISO C grammar for assignment, there is a "unary expression" on >>> the left and an "assignment expression" on the right. That's just a >>> particular factoring of the grammar that implementors don't have to >>> follow, if the correct results are produced. >> I can't see what it is you object to in what I wrote. I don't disagree >> with anything you are saying (the "correct result" being to reject a >> program that has, syntactically, the wrong thing on the left hand side). >> >>> Under a parser generator tool we could have a production rule like >>> expr '=' expr , where the '=' token has an elsewhere-declared >>> associativity and precedence. >>> >>> The basic idea that the same syntactic kind of thing is on both sides of >>> a C assignment (with an additional lvalue constraint) is valid; >>> it's just not literally true if we are discussing the details of how >>> ISO C expresses the grammar. >> A C program that has the wrong syntax (for example x+1) on the left hand >> side of an assignment must be rejected. I'm not relying on some fussy >> definition about how the syntax is written but making a point that what >> is required on each side is not the exactly same thing. Do you really >> disagree with that? > > So what exactly is different about the LHS and RHS here: > > A = A; Do you think (or claim) that what is /required/ on each side of an assignment in C is exactly the same thing? The expression on the LHS is required to be a modifiable lvalue expression. That does not apply to the expression on right hand side. A = A; might or might not be valid C because different kinds of expression are required on each side and assignment. If A not a modifiable lvalue, it can appear on the RHS but not on the LHS. >> A C program that has the wrong syntax (for example x+1) on the left hand >> side of an assignment must be rejected. > > I think that these (with x, y having compatible scalar types): > > x + 1 = y; > (x + 1) = y; // in case above was parsed differently > > are both valid syntax in C. It will fail for a different reason: an '+' > term is not a valid lvalue. The compiler must tell you that neither is valid C. That's because what is required on each side of assignment is not exactly the same thing. It's a distraction to argue about why each is not valid C as both have errors that require diagnostic at compile time. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-08-30 02:34 +0000 |
| Message-ID | <20240829191404.887@kylheku.com> |
| In reply to | #388023 |
On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: > Bart <bc@freeuk.com> writes: > >> On 29/08/2024 17:06, Ben Bacarisse wrote: >>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>> >>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>>> >>>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>>>> Bart <bc@freeuk.com> writes: >>>>>>> >>>>>>>> On 29/08/2024 13:35, Ben Bacarisse wrote: >>>>>>>>> Bart <bc@freeuk.com> writes: >>>>>>>> >>>>>>>>>> I explained that. LHS and RHS can be identical terms for assignment in >>>>>>>>>> pretty much every aspect, but there are extra constraints on the LHS. >>>>>>>>> So you use "exactly the same" to mean "exactly the same except for the >>>>>>>>> differences". >>>>>>>> >>>>>>>> No, I do mean exactly the same, both in terms of syntax and (in my >>>>>>>> implementations, which are likely typical) internal >>>>>>>> representation of those >>>>>>>> terms. >>>>>>>> >>>>>>>> There are no differences other than where the type system says >>>>>>>> your code is >>>>>>>> invalid. So are no differences when considering only valid programs. >>>>>>>> >>>>>>>> This program in my language: >>>>>>>> >>>>>>>> 42 := 42 >>>>>>>> >>>>>>>> is valid syntax. >>>>>>> >>>>>>> So what? We were talking about assignment in C. You cut the two >>>>>>> previous quotes where it was clear we were talking about C. This is not >>>>>>> an honest thing to do. You are arguing for the sake if it, and in a >>>>>>> dishonest way too. >>>>>> >>>>>> It's also valid syntax in C, with a constraint violation that can be >>>>>> "caught later on" in an implementation of C, just like in Bart's >>>>>> language. >>>>> >>>>> Have you taken Bart's bait and are now discussing a narrower context? >>>>> >>>>> The claim that C's assignment is symmetric and what is required on the >>>>> two sides is exactly the same is junk. C's assignment has different >>>>> syntax on each side, and what is required is even more strict. >>>> >>>> In the ISO C grammar for assignment, there is a "unary expression" on >>>> the left and an "assignment expression" on the right. That's just a >>>> particular factoring of the grammar that implementors don't have to >>>> follow, if the correct results are produced. >>> I can't see what it is you object to in what I wrote. I don't disagree >>> with anything you are saying (the "correct result" being to reject a >>> program that has, syntactically, the wrong thing on the left hand side). >>> >>>> Under a parser generator tool we could have a production rule like >>>> expr '=' expr , where the '=' token has an elsewhere-declared >>>> associativity and precedence. >>>> >>>> The basic idea that the same syntactic kind of thing is on both sides of >>>> a C assignment (with an additional lvalue constraint) is valid; >>>> it's just not literally true if we are discussing the details of how >>>> ISO C expresses the grammar. >>> A C program that has the wrong syntax (for example x+1) on the left hand >>> side of an assignment must be rejected. I'm not relying on some fussy >>> definition about how the syntax is written but making a point that what >>> is required on each side is not the exactly same thing. Do you really >>> disagree with that? >> >> So what exactly is different about the LHS and RHS here: >> >> A = A; > > Do you think (or claim) that what is /required/ on each side of an > assignment in C is exactly the same thing? The expression on the LHS is > required to be a modifiable lvalue expression. That does not apply to > the expression on right hand side. "modifiable lvalue" is a semantic attribute which depends on type and qualification. An array is an lvalue, but not modifiable. A const-qualified expression is also not a modififiable lvalue. Bart is insisting that these attributes are not a matter of syntax. If you regard the processing of these semantic attributes to be part of syntax (under the model of an attribute grammar), then it can be regarded as syntax. I think that what ISO C means by syntax does rule that out. That also applies in more trivial situations. For instance, the grammar rules for declaration specifiers admit this as valid syntax: unsigned double float char x; It's an invalid combination of specifiers ruled out by a constraints paragraph. The constraint can be readily identified as syntactic (it governs combinations of tokens), yet in ISO C, it is outside of the formal syntax. >> I think that these (with x, y having compatible scalar types): >> >> x + 1 = y; >> (x + 1) = y; // in case above was parsed differently >> >> are both valid syntax in C. It will fail for a different reason: an '+' >> term is not a valid lvalue. > > The compiler must tell you that neither is valid C. That's because what > is required on each side of assignment is not exactly the same thing. > It's a distraction to argue about why each is not valid C as both have > errors that require diagnostic at compile time. Bart is only saying that it's valid syntax, not that it's valid C. According to the ISO C syntax (not taking into account contraints, which are not syntax) that view is justified. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-08-30 06:44 -0700 |
| Message-ID | <86cylqw2f8.fsf@linuxsc.com> |
| In reply to | #388025 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote: > >> Bart <bc@freeuk.com> writes: >> >>> I think that these (with x, y having compatible scalar types): >>> >>> x + 1 = y; >>> (x + 1) = y; // in case above was parsed differently >>> >>> are both valid syntax in C. It will fail for a different reason: >>> an '+' term is not a valid lvalue. >> >> The compiler must tell you that neither is valid C. That's >> because what is required on each side of assignment is not >> exactly the same thing. It's a distraction to argue about why >> each is not valid C as both have errors that require diagnostic >> at compile time. > > Bart is only saying that it's valid syntax, not that it's valid C. > > According to the ISO C syntax (not taking into account contraints, > which are not syntax) that view is justified. The second line is syntactically well-formed. The first line is not.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-30 13:41 -0700 |
| Message-ID | <871q2568vl.fsf@nosuchdomain.example.com> |
| In reply to | #388035 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> I think that these (with x, y having compatible scalar types):
>>>>
>>>> x + 1 = y;
>>>> (x + 1) = y; // in case above was parsed differently
>>>>
>>>> are both valid syntax in C. It will fail for a different reason:
>>>> an '+' term is not a valid lvalue.
>>>
>>> The compiler must tell you that neither is valid C. That's
>>> because what is required on each side of assignment is not
>>> exactly the same thing. It's a distraction to argue about why
>>> each is not valid C as both have errors that require diagnostic
>>> at compile time.
>>
>> Bart is only saying that it's valid syntax, not that it's valid C.
>>
>> According to the ISO C syntax (not taking into account contraints,
>> which are not syntax) that view is justified.
>
> The second line is syntactically well-formed. The first line is
> not.
Right, because the LHS of an assignment is a unary-expression.
`(x + 1)` can be parsed as a unary-expression, but `x + 1` cannot.
However, the compilers I've tried produce the same diagnostic (not a
syntax error message) for both. Probably they use a tweaked grammar
that allows more a general expression as the LHS of an assignment,
and catch errors later in semantic analysis, for the purpose of
producing diagnostics that are easier to understand. It's obvious
that in `x + 1 = y`, the programmer (probably) intended `x + 1`
to be the LHS of an assignment. These compilers (I tried gcc,
clang, and tcc) are clever enough to recognize that.
For most programmers (in my opinion and apparently in the opinions
of those compiler developers), the fact that the two intended
assignments are invalid for different technical reasons is less
important than understanding that they're invalid, and in a way
that helps the programmer figure out how to correct them.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-08-31 07:08 +0000 |
| Message-ID | <20240830232138.772@kylheku.com> |
| In reply to | #388040 |
On 2024-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> I think that these (with x, y having compatible scalar types):
>>>>>
>>>>> x + 1 = y;
>>>>> (x + 1) = y; // in case above was parsed differently
>>>>>
>>>>> are both valid syntax in C. It will fail for a different reason:
>>>>> an '+' term is not a valid lvalue.
>>>>
>>>> The compiler must tell you that neither is valid C. That's
>>>> because what is required on each side of assignment is not
>>>> exactly the same thing. It's a distraction to argue about why
>>>> each is not valid C as both have errors that require diagnostic
>>>> at compile time.
>>>
>>> Bart is only saying that it's valid syntax, not that it's valid C.
>>>
>>> According to the ISO C syntax (not taking into account contraints,
>>> which are not syntax) that view is justified.
>>
>> The second line is syntactically well-formed. The first line is
>> not.
>
> Right, because the LHS of an assignment is a unary-expression.
> `(x + 1)` can be parsed as a unary-expression, but `x + 1` cannot.
> However, the compilers I've tried produce the same diagnostic (not a
> syntax error message) for both. Probably they use a tweaked grammar
> that allows more a general expression as the LHS of an assignment,
> and catch errors later in semantic analysis, for the purpose of
> producing diagnostics that are easier to understand. It's obvious
> that in `x + 1 = y`, the programmer (probably) intended `x + 1`
> to be the LHS of an assignment. These compilers (I tried gcc,
> clang, and tcc) are clever enough to recognize that.
A standard operator precedence parsing algorithm such as Shunting Yard
cannot help but parse that.
The operator tokens + and = have to be
assigned a precedence and associativity level, and so the parse has to
be (x + 1) = y or else x + (1 = y).
But precedence, in general, doesn't have to be ordered! It doesn't have
to have levels, or even partial ordering with transitivity. Precedence
can be such that for any pair of operators, we arbitrarily assign which
one is higher than the other, without regard for anything else.
Also: precedence can depend on order. It can be that in
X op1 Y op2 Z, where op1 is to the left of op2, op1 has
the higher precedence. But in X op2 Y op1 Z, op2 might have
the higher precedence. Or one order could have a defined
precedence but not the other.
In the C grammar, assignment breaks the cascading sequence. Whereas
most earlier rules refer to their immediate predecessors.
(e.g. additive builds on multiplicative), assignment looks all
the way back to unary. What this means is that the assignment operator
has no defined precedence with regard to all the intermediate
operators between it and unary. Or, at least, when the other operator
is to the left:
x + 1 = y // + =: no defined precedence: ambiguous: syntax error
y = x + 1 // = +: defined precedence: good syntax
When the precedence is not defined in one of the two orders,
you can safely adopt the one from the other order, provided
everything is still diagnosed that should be diagnosed.
The precedence not being defined means that the following parse
tree fragment is invalid:
=
+ y
x 1
it cannot be that + is a left child of =. So the parse could be
allowed by defining the precedence; and then we can detect the invalid
condition by walking the parse tree, looking for assignment nodes that
have a left child that has no precedence relationship to assignment.
But as an AST it is valid because that same AST shape can be forced by
parentheses, and parentheses disappear in abstract syntax.
Any invalid syntax condition that can be removed using parentheses is
not worth enforcing at the parse level. If it's wrong to assign to x +
1, you also need to diagnose when it's (x + 1). It's better to have
a single rule which catches both.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-08-31 12:45 -0400 |
| Message-ID | <vavhbn$12i2n$1@dont-email.me> |
| In reply to | #388047 |
On 8/31/24 03:08, Kaz Kylheku wrote: > On 2024-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >> However, the compilers I've tried produce the same diagnostic (not a >> syntax error message) for both. Probably they use a tweaked grammar >> that allows more a general expression as the LHS of an assignment, >> and catch errors later in semantic analysis, for the purpose of >> producing diagnostics that are easier to understand. It's obvious >> that in `x + 1 = y`, the programmer (probably) intended `x + 1` >> to be the LHS of an assignment. These compilers (I tried gcc, >> clang, and tcc) are clever enough to recognize that. > > A standard operator precedence parsing algorithm such as Shunting Yard > cannot help but parse that. True, which is an example of why a precedence parsing algorithm is inappropriate for parsing C, which is not defined in terms of precedence levels.
[toc] | [prev] | [next] | [standalone]
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web