Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #386767 > unrolled thread
| Started by | aotto1968 <aotto1968@t-online.de> |
|---|---|
| First post | 2024-07-04 17:16 +0200 |
| Last post | 2024-07-07 20:29 +0200 |
| Articles | 20 on this page of 312 — 23 participants |
Back to article view | Back to comp.lang.c
technology discussion → does the world need a "new" C ? aotto1968 <aotto1968@t-online.de> - 2024-07-04 17:16 +0200
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 01:05 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 02:30 -0500
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 07:52 +0000
Re: technology discussion → does the world need a "new" C ? yeti <yeti@tilde.institute> - 2024-07-05 09:12 +0042
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 01:09 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 08:25 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 04:19 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-05 12:20 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 08:28 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-05 23:40 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 22:30 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-06 19:01 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 13:47 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:41 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:42 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:04 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 23:28 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-07 12:35 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 14:57 -0500
Re: technology discussion → does the world need a "new" C ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-06 11:23 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 13:46 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 20:15 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 17:01 -0500
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 02:24 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 01:39 -0500
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 11:46 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:23 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 03:51 -0500
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 04:23 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 14:26 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 14:33 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 16:37 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-09 18:54 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 20:03 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 13:23 -0500
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:38 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 23:55 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-07 10:03 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 15:10 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-07 19:22 -0400
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-08 00:02 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-08 12:39 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 16:31 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 15:54 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 16:58 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 17:29 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 18:22 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 14:14 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 00:15 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 19:08 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 21:28 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 14:23 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 00:35 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 13:51 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:32 +0100
Re: technology discussion → does the world need a "new" C ? Thiago Adams <thiago.adams@gmail.com> - 2024-07-10 11:26 -0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 15:49 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 17:09 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 08:48 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-10 20:14 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:28 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:13 +0300
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-11 08:41 +0000
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 12:15 +0300
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-11 10:02 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 11:17 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:20 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 11:56 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 22:49 +0000
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 07:02 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-11 15:19 -0500
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 14:29 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-11 16:42 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 18:30 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-10 21:39 +0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 20:04 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:31 +0300
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:49 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 14:00 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 06:26 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 15:04 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 11:53 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 20:56 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 13:29 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 21:36 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 07:53 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 12:03 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:51 +0200
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 14:36 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:13 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:32 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-13 11:46 +0200
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-13 11:37 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 14:42 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-17 19:31 +0200
Re: Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-17 18:49 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 08:46 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 12:46 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:39 +0100
Re: Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-12 14:17 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-12 13:50 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 21:37 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 14:00 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 07:54 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:44 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 14:59 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:39 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 21:04 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 11:46 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 18:44 -0700
Re: technology discussion → does the world need a "new" C ? Thiago Adams <thiago.adams@gmail.com> - 2024-07-12 08:51 -0300
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:26 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 18:29 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:28 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 11:54 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 17:48 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 00:01 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 01:21 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 02:29 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 18:36 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:54 +0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 11:04 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 13:25 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:41 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 12:22 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 17:58 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 18:25 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 11:27 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 08:00 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:12 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 12:21 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 12:14 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 09:54 -0700
Re: technology discussion ? does the world need a "new" C ? dave_thompson_2@comcast.net - 2024-08-25 17:16 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 18:09 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-01 19:01 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-02 12:10 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-02 15:18 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 06:04 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-15 23:56 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-16 03:37 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-16 18:15 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 06:15 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-17 19:07 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 12:52 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-26 09:37 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-26 21:28 -0700
Wording discussion (was Re: technology discussion) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-27 14:21 +0200
Re: Wording discussion (was Re: technology discussion) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:09 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:03 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 00:26 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 06:43 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-29 08:07 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-16 22:41 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 15:22 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 08:58 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:33 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 13:38 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 16:42 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 11:52 +0000
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 15:35 +0300
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 15:42 +0300
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 15:07 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 16:31 +0300
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:49 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 15:44 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 12:13 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 02:01 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-13 04:39 -0500
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 12:35 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 14:43 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 12:38 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-17 16:34 +0300
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 16:56 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 01:43 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 13:48 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-15 15:33 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 17:08 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 01:08 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-16 12:10 +0300
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 02:18 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-16 12:38 +0300
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:28 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 11:40 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 11:17 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 11:42 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 11:00 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 16:31 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 00:54 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 18:03 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-19 09:26 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-19 12:22 +0300
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 14:14 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-19 21:18 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 10:56 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-17 12:26 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-17 11:38 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 15:19 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-17 07:41 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-17 18:07 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-17 18:22 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-18 12:35 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 01:01 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-19 01:57 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 02:30 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-19 12:29 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-20 00:33 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-20 12:42 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 10:04 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:45 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 16:51 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 14:36 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 23:22 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-15 23:29 +0000
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 01:46 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-15 18:21 -0700
Re: technology discussion → does the world need a "new" C ? tTh <tth@none.invalid> - 2024-08-16 03:37 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:14 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-15 14:52 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-17 19:07 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-17 12:53 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 09:46 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 05:05 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 14:41 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-18 14:00 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 18:01 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 14:25 -0500
Re: technology discussion → does the world need a "new" C ? vallor <vallor@cultnix.org> - 2024-07-18 22:23 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 12:40 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-13 13:35 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 01:09 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 07:34 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:35 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 16:54 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 16:40 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:46 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:47 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 22:40 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 16:00 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:38 +0200
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 22:32 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 00:04 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 16:50 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 01:38 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 18:18 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 11:12 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:05 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 03:19 +0000
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 18:31 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 13:05 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-09 18:39 +0300
Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-09 16:20 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 13:55 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-09 16:22 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 16:43 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 09:41 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-10 12:59 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:52 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 22:10 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-08 00:28 -0400
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 10:53 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:01 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 04:29 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 21:56 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 01:22 -0400
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 06:05 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 14:28 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 19:53 +0100
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 04:27 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 02:38 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 10:58 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 15:36 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:45 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:18 -0400
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 18:35 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:23 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 05:55 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 03:07 -0400
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 02:52 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 11:27 +0000
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:23 +0100
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 05:42 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-05 14:31 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 10:48 -0500
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 01:38 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 19:00 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 04:36 +0200
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:25 +0000
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:24 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:55 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:34 -0400
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 00:57 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 03:16 -0400
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:51 +0000
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:46 +0200
Re: technology discussion → does the world need a "new" C ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-11 13:57 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 14:50 +0100
Re: technology discussion → does the world need a "new" C ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-11 12:44 -0700
Re: technology discussion → does the world need a "new" C ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-12 12:17 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-11 12:09 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:15 -0700
Re: technology discussion ? does the world need a "new" C ? dave_thompson_2@comcast.net - 2024-08-25 16:59 -0400
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 04:29 +0200
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 01:46 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 10:21 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:04 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-07 01:36 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 18:39 -0700
Re: technology discussion → does the world need a "new" C ? lexi hale <lexi@hale.su> - 2024-07-05 21:54 +0200
Re: technology discussion → does the world need a "new" C ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-07 06:35 +0200
Re: technology discussion → does the world need a "new" C ? aotto1968 <aotto1968@t-online.de> - 2024-07-07 20:29 +0200
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-10 20:14 +0300 |
| Message-ID | <20240710201454.0000527e@yahoo.com> |
| In reply to | #387004 |
On Wed, 10 Jul 2024 08:48:05 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > bart <bc@freeuk.com> writes: > > > I earlier asked this: > > > > "So if arrays aren't passed by value in C, and they aren't passed > > by reference, then how the hell ARE they passed?!" > > They aren't. C allows lots of things to be passed as an argument > to a function: several varieties of numeric values, structs, > unions, and pointers, including both pointers to object types and > pointers to function types. C does not have a way for a function > to take an argument that is either an array or a function. There > is a way to take pointers to those things, but not the things > themselves. Arrays and functions are second-class values in C. > I'd like to see an example of the language that permits ahead-of-time compilation and has functions as first-class values.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-07-10 21:28 +0200 |
| Message-ID | <v6mnch$21n94$1@dont-email.me> |
| In reply to | #387007 |
On 10/07/2024 19:14, Michael S wrote:
> On Wed, 10 Jul 2024 08:48:05 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> I earlier asked this:
>>>
>>> "So if arrays aren't passed by value in C, and they aren't passed
>>> by reference, then how the hell ARE they passed?!"
>>
>> They aren't. C allows lots of things to be passed as an argument
>> to a function: several varieties of numeric values, structs,
>> unions, and pointers, including both pointers to object types and
>> pointers to function types. C does not have a way for a function
>> to take an argument that is either an array or a function. There
>> is a way to take pointers to those things, but not the things
>> themselves. Arrays and functions are second-class values in C.
>>
>
> I'd like to see an example of the language that permits ahead-of-time
> compilation and has functions as first-class values.
>
Haskell is the first the comes to mind for me, but you could pick any
compiled functional programming language.
I am by no means a Haskell expert, and I am not at all familiar with the
way the language is compiled. But it is quite clear that it is an
example of a language that has functions as first-class objects, and
which is ahead-of-time compiled. The example below defines an
int-to-int function "doubler", and also a function-to-function function
"doTwice", and a function quadrupler that is defined as the result of
applying the higher-order function doTwice to doubler. These are all
compiled to assembly.
<https://godbolt.org/z/Tb7hGYsdv>
module Example where
doubler :: Int -> Int
doubler x = 2 * x
doTwice :: (Int -> Int) -> (Int -> Int)
doTwice f x = f (f x)
quadrupler = doTwice doubler
shouldBeEighty = quadrupler 20
You can write much the same in C++ using lambdas (which are objects and
can be passed around and returned as such) and templates (which are
needed because the type of lambdas is hidden). Unfortunately, this also
means that the functions don't get individually generated functions in
assembly:
<https://godbolt.org/z/KvPWz3n8z>
auto doubler = [](int x) -> int { return 2 * x; };
auto doTwice = [](auto f) -> auto
{
return [f](int x) -> int { return f(f(x)); };
};
auto quadrupler = doTwice(doubler);
auto shouldBeEiqhty = quadrupler(20);
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-11 11:13 +0300 |
| Message-ID | <20240711111357.00007712@yahoo.com> |
| In reply to | #387012 |
On Wed, 10 Jul 2024 21:28:15 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 10/07/2024 19:14, Michael S wrote:
> > On Wed, 10 Jul 2024 08:48:05 -0700
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> bart <bc@freeuk.com> writes:
> >>
> >>> I earlier asked this:
> >>>
> >>> "So if arrays aren't passed by value in C, and they aren't passed
> >>> by reference, then how the hell ARE they passed?!"
> >>
> >> They aren't. C allows lots of things to be passed as an argument
> >> to a function: several varieties of numeric values, structs,
> >> unions, and pointers, including both pointers to object types and
> >> pointers to function types. C does not have a way for a function
> >> to take an argument that is either an array or a function. There
> >> is a way to take pointers to those things, but not the things
> >> themselves. Arrays and functions are second-class values in C.
> >>
> >
> > I'd like to see an example of the language that permits
> > ahead-of-time compilation and has functions as first-class values.
> >
>
> Haskell is the first the comes to mind for me, but you could pick any
> compiled functional programming language.
>
> I am by no means a Haskell expert, and I am not at all familiar with
> the way the language is compiled. But it is quite clear that it is
> an example of a language that has functions as first-class objects,
> and which is ahead-of-time compiled. The example below defines an
> int-to-int function "doubler", and also a function-to-function
> function "doTwice", and a function quadrupler that is defined as the
> result of applying the higher-order function doTwice to doubler.
> These are all compiled to assembly.
>
> <https://godbolt.org/z/Tb7hGYsdv>
>
>
> module Example where
>
> doubler :: Int -> Int
> doubler x = 2 * x
>
> doTwice :: (Int -> Int) -> (Int -> Int)
> doTwice f x = f (f x)
>
> quadrupler = doTwice doubler
>
> shouldBeEighty = quadrupler 20
>
>
>
> You can write much the same in C++ using lambdas (which are objects
> and can be passed around and returned as such) and templates (which
> are needed because the type of lambdas is hidden). Unfortunately,
> this also means that the functions don't get individually generated
> functions in assembly:
>
> <https://godbolt.org/z/KvPWz3n8z>
>
> auto doubler = [](int x) -> int { return 2 * x; };
>
> auto doTwice = [](auto f) -> auto
> {
> return [f](int x) -> int { return f(f(x)); };
> };
>
> auto quadrupler = doTwice(doubler);
>
> auto shouldBeEiqhty = quadrupler(20);
>
I fail to see a material difference between first class function values
in Haskell and C++ and first class function pointer values in C:
int doubler(int x) {
return x*2;
}
int doTwice(int (*foo)(int), int x) {
return foo(foo(x));
}
int quadrupler(int x) {
return doTwice(doubler, x);
}
I am willing to believe that the difference exists, but your example is
too basic to demonstrate it.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-11 08:41 +0000 |
| Message-ID | <20240711012852.856@kylheku.com> |
| In reply to | #387039 |
On 2024-07-11, Michael S <already5chosen@yahoo.com> wrote:
> On Wed, 10 Jul 2024 21:28:15 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 10/07/2024 19:14, Michael S wrote:
>> > On Wed, 10 Jul 2024 08:48:05 -0700
>> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> >
>> >> bart <bc@freeuk.com> writes:
>> >>
>> >>> I earlier asked this:
>> >>>
>> >>> "So if arrays aren't passed by value in C, and they aren't passed
>> >>> by reference, then how the hell ARE they passed?!"
>> >>
>> >> They aren't. C allows lots of things to be passed as an argument
>> >> to a function: several varieties of numeric values, structs,
>> >> unions, and pointers, including both pointers to object types and
>> >> pointers to function types. C does not have a way for a function
>> >> to take an argument that is either an array or a function. There
>> >> is a way to take pointers to those things, but not the things
>> >> themselves. Arrays and functions are second-class values in C.
>> >>
>> >
>> > I'd like to see an example of the language that permits
>> > ahead-of-time compilation and has functions as first-class values.
>> >
>>
>> Haskell is the first the comes to mind for me, but you could pick any
>> compiled functional programming language.
>>
>> I am by no means a Haskell expert, and I am not at all familiar with
>> the way the language is compiled. But it is quite clear that it is
>> an example of a language that has functions as first-class objects,
>> and which is ahead-of-time compiled. The example below defines an
>> int-to-int function "doubler", and also a function-to-function
>> function "doTwice", and a function quadrupler that is defined as the
>> result of applying the higher-order function doTwice to doubler.
>> These are all compiled to assembly.
>>
>> <https://godbolt.org/z/Tb7hGYsdv>
>>
>>
>> module Example where
>>
>> doubler :: Int -> Int
>> doubler x = 2 * x
>>
>> doTwice :: (Int -> Int) -> (Int -> Int)
>> doTwice f x = f (f x)
>>
>> quadrupler = doTwice doubler
>>
>> shouldBeEighty = quadrupler 20
>>
>>
>>
>> You can write much the same in C++ using lambdas (which are objects
>> and can be passed around and returned as such) and templates (which
>> are needed because the type of lambdas is hidden). Unfortunately,
>> this also means that the functions don't get individually generated
>> functions in assembly:
>>
>> <https://godbolt.org/z/KvPWz3n8z>
>>
>> auto doubler = [](int x) -> int { return 2 * x; };
>>
>> auto doTwice = [](auto f) -> auto
>> {
>> return [f](int x) -> int { return f(f(x)); };
>> };
>>
>> auto quadrupler = doTwice(doubler);
>>
>> auto shouldBeEiqhty = quadrupler(20);
>>
>
> I fail to see a material difference between first class function values
> in Haskell and C++ and first class function pointer values in C:
>
> int doubler(int x) {
> return x*2;
> }
> int doTwice(int (*foo)(int), int x) {
> return foo(foo(x));
> }
> int quadrupler(int x) {
> return doTwice(doubler, x);
> }
>
> I am willing to believe that the difference exists, but your example is
> too basic to demonstrate it.
First class functions could do something like this:
// multiplier takes a coefficient and returns a pointer to
// function
int (*multiplier(int coefficient))(int) {
// fantasy lambda syntax. Return type int is written after
// parameter list.
return lambda(int x) int {
return coefficient * x;
}
}
int (*doubler)(int) = multiplier(2);
int x = doubler(42); // x becomes 84
Even though the lambda is returned out of multiplier, whose execution
terminates, when the returned function is invoked, it can refer to the
coefficient, which is captured in a lexical closure.
With a C-like typedef, we can declutter the definition of mutiplier:
typedef int (*int_int_fn)(int);
int_int_fn multiplier(int coefficient) {
return lambda(int x) int {
return coefficient * x;
}
}
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-11 12:15 +0300 |
| Message-ID | <20240711121502.0000614e@yahoo.com> |
| In reply to | #387041 |
On Thu, 11 Jul 2024 08:41:14 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2024-07-11, Michael S <already5chosen@yahoo.com> wrote:
> > On Wed, 10 Jul 2024 21:28:15 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 10/07/2024 19:14, Michael S wrote:
> >> > On Wed, 10 Jul 2024 08:48:05 -0700
> >> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >> >
> >> >> bart <bc@freeuk.com> writes:
> >> >>
> >> >>> I earlier asked this:
> >> >>>
> >> >>> "So if arrays aren't passed by value in C, and they aren't
> >> >>> passed by reference, then how the hell ARE they passed?!"
> >> >>
> >> >> They aren't. C allows lots of things to be passed as an
> >> >> argument to a function: several varieties of numeric values,
> >> >> structs, unions, and pointers, including both pointers to
> >> >> object types and pointers to function types. C does not have a
> >> >> way for a function to take an argument that is either an array
> >> >> or a function. There is a way to take pointers to those
> >> >> things, but not the things themselves. Arrays and functions
> >> >> are second-class values in C.
> >> >
> >> > I'd like to see an example of the language that permits
> >> > ahead-of-time compilation and has functions as first-class
> >> > values.
> >>
> >> Haskell is the first the comes to mind for me, but you could pick
> >> any compiled functional programming language.
> >>
> >> I am by no means a Haskell expert, and I am not at all familiar
> >> with the way the language is compiled. But it is quite clear that
> >> it is an example of a language that has functions as first-class
> >> objects, and which is ahead-of-time compiled. The example below
> >> defines an int-to-int function "doubler", and also a
> >> function-to-function function "doTwice", and a function quadrupler
> >> that is defined as the result of applying the higher-order
> >> function doTwice to doubler. These are all compiled to assembly.
> >>
> >> <https://godbolt.org/z/Tb7hGYsdv>
> >>
> >>
> >> module Example where
> >>
> >> doubler :: Int -> Int
> >> doubler x = 2 * x
> >>
> >> doTwice :: (Int -> Int) -> (Int -> Int)
> >> doTwice f x = f (f x)
> >>
> >> quadrupler = doTwice doubler
> >>
> >> shouldBeEighty = quadrupler 20
> >>
> >>
> >>
> >> You can write much the same in C++ using lambdas (which are objects
> >> and can be passed around and returned as such) and templates (which
> >> are needed because the type of lambdas is hidden). Unfortunately,
> >> this also means that the functions don't get individually generated
> >> functions in assembly:
> >>
> >> <https://godbolt.org/z/KvPWz3n8z>
> >>
> >> auto doubler = [](int x) -> int { return 2 * x; };
> >>
> >> auto doTwice = [](auto f) -> auto
> >> {
> >> return [f](int x) -> int { return f(f(x)); };
> >> };
> >>
> >> auto quadrupler = doTwice(doubler);
> >>
> >> auto shouldBeEiqhty = quadrupler(20);
> >>
> >
> > I fail to see a material difference between first class function
> > values in Haskell and C++ and first class function pointer values
> > in C:
> >
> > int doubler(int x) {
> > return x*2;
> > }
> > int doTwice(int (*foo)(int), int x) {
> > return foo(foo(x));
> > }
> > int quadrupler(int x) {
> > return doTwice(doubler, x);
> > }
> >
> > I am willing to believe that the difference exists, but your
> > example is too basic to demonstrate it.
>
> First class functions could do something like this:
>
> // multiplier takes a coefficient and returns a pointer to
> // function
>
> int (*multiplier(int coefficient))(int) {
> // fantasy lambda syntax. Return type int is written after
> // parameter list.
> return lambda(int x) int {
> return coefficient * x;
> }
> }
>
> int (*doubler)(int) = multiplier(2);
>
> int x = doubler(42); // x becomes 84
>
> Even though the lambda is returned out of multiplier, whose execution
> terminates, when the returned function is invoked, it can refer to the
> coefficient, which is captured in a lexical closure.
>
> With a C-like typedef, we can declutter the definition of mutiplier:
>
> typedef int (*int_int_fn)(int);
>
> int_int_fn multiplier(int coefficient) {
> return lambda(int x) int {
> return coefficient * x;
> }
> }
>
Thank you.
Your example confirms my suspicion that the difference between first
and second class of functions doesn't become material until language
supports closures.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-11 10:02 +0000 |
| Message-ID | <20240711030106.779@kylheku.com> |
| In reply to | #387043 |
On 2024-07-11, Michael S <already5chosen@yahoo.com> wrote:
>
>> With a C-like typedef, we can declutter the definition of mutiplier:
>>
>> typedef int (*int_int_fn)(int);
>>
>> int_int_fn multiplier(int coefficient) {
>> return lambda(int x) int {
>> return coefficient * x;
>> }
>> }
>>
>
> Thank you.
> Your example confirms my suspicion that the difference between first
> and second class of functions doesn't become material until language
> supports closures.
It sort of becomes half-material when the language supports
downward-funarg-only closures, like Pascal and GNU C,
where our lambda is good as long as multiplier doesn't exit.
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-11 11:17 +0100 |
| Message-ID | <v6obf0$2d8nn$2@dont-email.me> |
| In reply to | #387043 |
On 11/07/2024 10:15, Michael S wrote:
> On Thu, 11 Jul 2024 08:41:14 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> On 2024-07-11, Michael S <already5chosen@yahoo.com> wrote:
>>> I fail to see a material difference between first class function
>>> values in Haskell and C++ and first class function pointer values
>>> in C:
>>>
>>> int doubler(int x) {
>>> return x*2;
>>> }
>>> int doTwice(int (*foo)(int), int x) {
>>> return foo(foo(x));
>>> }
>>> int quadrupler(int x) {
>>> return doTwice(doubler, x);
>>> }
>>>
>>> I am willing to believe that the difference exists, but your
>>> example is too basic to demonstrate it.
>>
>> First class functions could do something like this:
>>
>> // multiplier takes a coefficient and returns a pointer to
>> // function
>>
>> int (*multiplier(int coefficient))(int) {
>> // fantasy lambda syntax. Return type int is written after
>> // parameter list.
>> return lambda(int x) int {
>> return coefficient * x;
>> }
>> }
>>
>> int (*doubler)(int) = multiplier(2);
>>
>> int x = doubler(42); // x becomes 84
>>
>> Even though the lambda is returned out of multiplier, whose execution
>> terminates, when the returned function is invoked, it can refer to the
>> coefficient, which is captured in a lexical closure.
>>
>> With a C-like typedef, we can declutter the definition of mutiplier:
>>
>> typedef int (*int_int_fn)(int);
>>
>> int_int_fn multiplier(int coefficient) {
>> return lambda(int x) int {
>> return coefficient * x;
>> }
>> }
>>
>
> Thank you.
> Your example confirms my suspicion that the difference between first
> and second class of functions doesn't become material until language
> supports closures.
>
There are multiple classes of functions. Closures are part of it but
there are several versions of closures too:
Reference Closure
Normal functions - -
Function pointers Y -
Anonymous functions Y -
Anonymous functions Y 1
Anonymous functions Y 2
Anonymous functions Y ...
C supports the first two, as does my static language. My dynamic
language supports the first 3 (and can emulate the next couple of levels)
With closures, they can have different capabilities (as you discover
when you manage to implement something that runs the simpler Wikipedia
examples, then move on to the next which fails).
For example, in managing to still work after the containing function in
the above example returns. Or in being able to update that 'coefficient'
variable in a still-active enclosing function.
Whatever you do, there will exist a more elaborate, subtler example that
will fail. But it will also be one that few can understand or predict
anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-07-11 12:20 +0200 |
| Message-ID | <v6obln$2djgq$1@dont-email.me> |
| In reply to | #387043 |
On 11/07/2024 11:15, Michael S wrote: > On Thu, 11 Jul 2024 08:41:14 -0000 (UTC) > Kaz Kylheku <643-408-1753@kylheku.com> wrote: > >> On 2024-07-11, Michael S <already5chosen@yahoo.com> wrote: >>> On Wed, 10 Jul 2024 21:28:15 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 10/07/2024 19:14, Michael S wrote: >>>>> >>>>> I'd like to see an example of the language that permits >>>>> ahead-of-time compilation and has functions as first-class >>>>> values. >>>> >>>> Haskell is the first the comes to mind for me, but you could pick >>>> any compiled functional programming language. >>>> >>> >>> I fail to see a material difference between first class function >>> values in Haskell and C++ and first class function pointer values >>> in C: >>> > Thank you. > Your example confirms my suspicion that the difference between first > and second class of functions doesn't become material until language > supports closures. > I think that is fair to say, yes. The real power comes when there are captures - not "doTwice", but "doNTimes". Again, this can be done in compiled Haskell, and surely in any compiled functional programming language or compiled language that supports functional programming paradigms. (OCaml is another popular choice.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-11 11:56 +0100 |
| Message-ID | <874j8wkxie.fsf@bsb.me.uk> |
| In reply to | #387043 |
Michael S <already5chosen@yahoo.com> writes:
> On Thu, 11 Jul 2024 08:41:14 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
...
>> First class functions could do something like this:
>>
>> // multiplier takes a coefficient and returns a pointer to
>> // function
>>
>> int (*multiplier(int coefficient))(int) {
>> // fantasy lambda syntax. Return type int is written after
>> // parameter list.
>> return lambda(int x) int {
>> return coefficient * x;
>> }
>> }
>>
>> int (*doubler)(int) = multiplier(2);
>>
>> int x = doubler(42); // x becomes 84
>>
>> Even though the lambda is returned out of multiplier, whose execution
>> terminates, when the returned function is invoked, it can refer to the
>> coefficient, which is captured in a lexical closure.
>>
>> With a C-like typedef, we can declutter the definition of mutiplier:
>>
>> typedef int (*int_int_fn)(int);
>>
>> int_int_fn multiplier(int coefficient) {
>> return lambda(int x) int {
>> return coefficient * x;
>> }
>> }
>>
>
> Thank you.
> Your example confirms my suspicion that the difference between first
> and second class of functions doesn't become material until language
> supports closures.
That's half true, but it concentrates on something that is partly
syntactic -- the lexical binding of names. It possible to do the same
things with no names in sight so the term "closure" would seem rather
odd. For example, Kaz's example could be written like this is Haskell:
$ ghci
GHCi, version 9.4.7: https://www.haskell.org/ghc/ :? for help
ghci> multiplier = (*)
ghci> doubler = multiplier 2
ghci> doubler 42
84
and, indeed, one way to implement Haskell is is to tranform the code
into combinators. Combinators were first studied by logicians like
Haskell Curry as a way to re-write formal logics that use quantifiers
(which bind names) into nameless forms.
Of course, "something" is mysteriously doing the same work as the
closures in Kaz's examples, but it not using lexical binding to it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-10 22:49 +0000 |
| Message-ID | <20240710154825.594@kylheku.com> |
| In reply to | #387007 |
On 2024-07-10, Michael S <already5chosen@yahoo.com> wrote: > I'd like to see an example of the language that permits ahead-of-time > compilation and has functions as first-class values. Common Lisp. -- 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-07-11 07:02 -0700 |
| Message-ID | <86wmls6n7n.fsf@linuxsc.com> |
| In reply to | #387007 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 10 Jul 2024 08:48:05 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> I earlier asked this:
>>>
>>> "So if arrays aren't passed by value in C, and they aren't passed
>>> by reference, then how the hell ARE they passed?!"
>>
>> They aren't. C allows lots of things to be passed as an argument
>> to a function: several varieties of numeric values, structs,
>> unions, and pointers, including both pointers to object types and
>> pointers to function types. C does not have a way for a function
>> to take an argument that is either an array or a function. There
>> is a way to take pointers to those things, but not the things
>> themselves. Arrays and functions are second-class values in C.
>
> I'd like to see an example of the language that permits ahead-of-time
> compilation and has functions as first-class values.
C is almost that language. Pointers to functions are first class
in C. If for every C function definition a pattern like this:
static int
foo_implementation( int x ){
return x > 0 ? -x : x;
}
int (*foo)( int ) = foo_implementation;
is used, and there are no other references to the _implementation
names, then "functions" like foo() are essentially first-class
functions. The "function" foo can be assigned into. It can be
called just like an actual C function. The type of a "function"
is not like an actual function type, and so for example how the
address-of operator works is different for "functions" than it is
for actual C functions. Also pre-declarations for "functions"
obviously need to be different than they would be for actual C
functions. If the necessary adjustments are made, we would have
a language with first-class "functions".
Incidentally, whether a language has closures is orthogonal to
the question of whether functions are first class. Closures
might or might not be interoperable with functions (they are
in some languages, and not in others). But that needn't have
any bearing on whether functions (or closures) are first class.
Note: strictly speaking a closure is a run-time value, not a
compile-time definition. I trust my readers are able to make
the needed linguistic accommodations.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-11 15:19 -0500 |
| Message-ID | <v6peol$2jtj4$1@dont-email.me> |
| In reply to | #387060 |
On 7/11/2024 9:02 AM, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Wed, 10 Jul 2024 08:48:05 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>> I earlier asked this:
>>>>
>>>> "So if arrays aren't passed by value in C, and they aren't passed
>>>> by reference, then how the hell ARE they passed?!"
>>>
>>> They aren't. C allows lots of things to be passed as an argument
>>> to a function: several varieties of numeric values, structs,
>>> unions, and pointers, including both pointers to object types and
>>> pointers to function types. C does not have a way for a function
>>> to take an argument that is either an array or a function. There
>>> is a way to take pointers to those things, but not the things
>>> themselves. Arrays and functions are second-class values in C.
>>
>> I'd like to see an example of the language that permits ahead-of-time
>> compilation and has functions as first-class values.
>
> C is almost that language. Pointers to functions are first class
> in C. If for every C function definition a pattern like this:
>
> static int
> foo_implementation( int x ){
> return x > 0 ? -x : x;
> }
>
> int (*foo)( int ) = foo_implementation;
>
> is used, and there are no other references to the _implementation
> names, then "functions" like foo() are essentially first-class
> functions. The "function" foo can be assigned into. It can be
> called just like an actual C function. The type of a "function"
> is not like an actual function type, and so for example how the
> address-of operator works is different for "functions" than it is
> for actual C functions. Also pre-declarations for "functions"
> obviously need to be different than they would be for actual C
> functions. If the necessary adjustments are made, we would have
> a language with first-class "functions".
>
> Incidentally, whether a language has closures is orthogonal to
> the question of whether functions are first class. Closures
> might or might not be interoperable with functions (they are
> in some languages, and not in others). But that needn't have
> any bearing on whether functions (or closures) are first class.
>
> Note: strictly speaking a closure is a run-time value, not a
> compile-time definition. I trust my readers are able to make
> the needed linguistic accommodations.
FWIW, there was a proposal to add C++ style lambdas to C23, but
apparently didn't get in.
I had added them though because my compiler had already had support for
lambdas, albeit with a different syntax (and initially mostly for the
other languages my compiler supports).
The variant I added had re-added some features slightly closer to the
C++ version though, being able to capture both by value and by
reference, although with slightly different behaviors depending on these
cases:
No capture, behaves like an anonymous function, unbounded lifetime;
Capture by reference, automatic lifetime only;
Capture by value, unbounded lifetime, heap allocated.
Mixed usage will behave as the by-reference case.
In the latter cases, the lambda still results in an otherwise normal
seeming function pointer; in the latter cases as a thunk located in a
RWX (Read/Write/Execute) memory allocation (which loads its own address
into a register and branches to the entry point of the function proper).
The by-value capture case may be freed using "free()", but otherwise
creating lambdas and not freeing them will result in a memory leak (the
former two cases may not be manually freed).
...
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-11 14:29 -0700 |
| Message-ID | <86sewf7h2y.fsf@linuxsc.com> |
| In reply to | #387069 |
BGB <cr88192@gmail.com> writes:
> On 7/11/2024 9:02 AM, Tim Rentsch wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Wed, 10 Jul 2024 08:48:05 -0700
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> I earlier asked this:
>>>>>
>>>>> "So if arrays aren't passed by value in C, and they aren't passed
>>>>> by reference, then how the hell ARE they passed?!"
>>>>
>>>> They aren't. C allows lots of things to be passed as an argument
>>>> to a function: several varieties of numeric values, structs,
>>>> unions, and pointers, including both pointers to object types and
>>>> pointers to function types. C does not have a way for a function
>>>> to take an argument that is either an array or a function. There
>>>> is a way to take pointers to those things, but not the things
>>>> themselves. Arrays and functions are second-class values in C.
>>>
>>> I'd like to see an example of the language that permits ahead-of-time
>>> compilation and has functions as first-class values.
>>
>> C is almost that language. Pointers to functions are first class
>> in C. If for every C function definition a pattern like this:
>>
>> static int
>> foo_implementation( int x ){
>> return x > 0 ? -x : x;
>> }
>>
>> int (*foo)( int ) = foo_implementation;
>>
>> is used, and there are no other references to the _implementation
>> names, then "functions" like foo() are essentially first-class
>> functions. The "function" foo can be assigned into. It can be
>> called just like an actual C function. The type of a "function"
>> is not like an actual function type, and so for example how the
>> address-of operator works is different for "functions" than it is
>> for actual C functions. Also pre-declarations for "functions"
>> obviously need to be different than they would be for actual C
>> functions. If the necessary adjustments are made, we would have
>> a language with first-class "functions".
>>
>> Incidentally, whether a language has closures is orthogonal to
>> the question of whether functions are first class. Closures
>> might or might not be interoperable with functions (they are
>> in some languages, and not in others). But that needn't have
>> any bearing on whether functions (or closures) are first class.
>>
>> Note: strictly speaking a closure is a run-time value, not a
>> compile-time definition. I trust my readers are able to make
>> the needed linguistic accommodations.
>
> FWIW, there was a proposal to add C++ style lambdas to C23, but
> apparently didn't get in. [...]
IMO the more C ignores or moves away from C++ the better.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-11 16:42 -0500 |
| Message-ID | <v6pjjr$2kvtn$1@dont-email.me> |
| In reply to | #387074 |
On 7/11/2024 4:29 PM, Tim Rentsch wrote:
> BGB <cr88192@gmail.com> writes:
>
>> On 7/11/2024 9:02 AM, Tim Rentsch wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Wed, 10 Jul 2024 08:48:05 -0700
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>
>>>>> bart <bc@freeuk.com> writes:
>>>>>
>>>>>> I earlier asked this:
>>>>>>
>>>>>> "So if arrays aren't passed by value in C, and they aren't passed
>>>>>> by reference, then how the hell ARE they passed?!"
>>>>>
>>>>> They aren't. C allows lots of things to be passed as an argument
>>>>> to a function: several varieties of numeric values, structs,
>>>>> unions, and pointers, including both pointers to object types and
>>>>> pointers to function types. C does not have a way for a function
>>>>> to take an argument that is either an array or a function. There
>>>>> is a way to take pointers to those things, but not the things
>>>>> themselves. Arrays and functions are second-class values in C.
>>>>
>>>> I'd like to see an example of the language that permits ahead-of-time
>>>> compilation and has functions as first-class values.
>>>
>>> C is almost that language. Pointers to functions are first class
>>> in C. If for every C function definition a pattern like this:
>>>
>>> static int
>>> foo_implementation( int x ){
>>> return x > 0 ? -x : x;
>>> }
>>>
>>> int (*foo)( int ) = foo_implementation;
>>>
>>> is used, and there are no other references to the _implementation
>>> names, then "functions" like foo() are essentially first-class
>>> functions. The "function" foo can be assigned into. It can be
>>> called just like an actual C function. The type of a "function"
>>> is not like an actual function type, and so for example how the
>>> address-of operator works is different for "functions" than it is
>>> for actual C functions. Also pre-declarations for "functions"
>>> obviously need to be different than they would be for actual C
>>> functions. If the necessary adjustments are made, we would have
>>> a language with first-class "functions".
>>>
>>> Incidentally, whether a language has closures is orthogonal to
>>> the question of whether functions are first class. Closures
>>> might or might not be interoperable with functions (they are
>>> in some languages, and not in others). But that needn't have
>>> any bearing on whether functions (or closures) are first class.
>>>
>>> Note: strictly speaking a closure is a run-time value, not a
>>> compile-time definition. I trust my readers are able to make
>>> the needed linguistic accommodations.
>>
>> FWIW, there was a proposal to add C++ style lambdas to C23, but
>> apparently didn't get in. [...]
>
> IMO the more C ignores or moves away from C++ the better.
Possibly, though some amount of the features they did add to C23 were
"C++ flavored".
Though, the proposal did differ on one major point:
The C++ version was some sort of opaque type;
The C version was a function pointer.
Though, any option other than function pointers is likely non-workable
though...
My own previous syntax was more like:
__var(args):type { body } //by-value
__var!(args):type { body } //by-ref
Rather than:
[capture](args)->type { body }
But, wasn't that hard to add support for the latter notation in the
parser (and allows specify capture type per variable).
But, yeah...
Lambdas are still not seeing a whole lot of use either way...
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-10 18:30 +0100 |
| Message-ID | <v6mggd$20g3f$1@dont-email.me> |
| In reply to | #387004 |
On 10/07/2024 16:48, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> I earlier asked this: >> >> "So if arrays aren't passed by value in C, and they aren't passed >> by reference, then how the hell ARE they passed?!" > > They aren't. C allows lots of things to be passed as an argument > to a function: several varieties of numeric values, structs, > unions, and pointers, including both pointers to object types and > pointers to function types. C does not have a way for a function > to take an argument that is either an array or a function. There > is a way to take pointers to those things, but not the things > themselves. Arrays and functions are second-class values in C. That's a good point. It's not just arrays that can't be passed by value (because the language says so) but also functions (because its not meaningful). Yet, although pointers to arrays and function can be passed (without even doing anything special like using &), you are not allowed to say that anything is passed by reference in C! The automatic conversion to a pointer, which is also a feature of true pass-by-reference, doesn't count. Not needing an explicit deref inside the callee (another characteristic of pass-by-reference) doesn't count either.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-10 21:39 +0300 |
| Message-ID | <20240710213910.00000afd@yahoo.com> |
| In reply to | #387008 |
On Wed, 10 Jul 2024 18:30:54 +0100 bart <bc@freeuk.com> wrote: > On 10/07/2024 16:48, Tim Rentsch wrote: > > bart <bc@freeuk.com> writes: > > > >> I earlier asked this: > >> > >> "So if arrays aren't passed by value in C, and they aren't passed > >> by reference, then how the hell ARE they passed?!" > > > > They aren't. C allows lots of things to be passed as an argument > > to a function: several varieties of numeric values, structs, > > unions, and pointers, including both pointers to object types and > > pointers to function types. C does not have a way for a function > > to take an argument that is either an array or a function. There > > is a way to take pointers to those things, but not the things > > themselves. Arrays and functions are second-class values in C. > > That's a good point. It's not just arrays that can't be passed by > value (because the language says so) but also functions (because its > not meaningful). > > Yet, although pointers to arrays and function can be passed (without > even doing anything special like using &), you are not allowed to say > that anything is passed by reference in C! > > The automatic conversion to a pointer, which is also a feature of > true pass-by-reference, doesn't count. > > Not needing an explicit deref inside the callee (another > characteristic of pass-by-reference) doesn't count either. It does not count, because automatic conversion to a pointer is not something that happens only during parameter passing. For arrays, it happens in all contexts except sizeof(). For functions, it happens in all contexts except function call. Or, may be, including function call, in this case (but not in case of arrays) it depends on point of view.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-10 20:04 +0100 |
| Message-ID | <v6mm02$21cpb$1@dont-email.me> |
| In reply to | #387010 |
On 10/07/2024 19:39, Michael S wrote: > On Wed, 10 Jul 2024 18:30:54 +0100 > bart <bc@freeuk.com> wrote: > >> On 10/07/2024 16:48, Tim Rentsch wrote: >>> bart <bc@freeuk.com> writes: >>> >>>> I earlier asked this: >>>> >>>> "So if arrays aren't passed by value in C, and they aren't passed >>>> by reference, then how the hell ARE they passed?!" >>> >>> They aren't. C allows lots of things to be passed as an argument >>> to a function: several varieties of numeric values, structs, >>> unions, and pointers, including both pointers to object types and >>> pointers to function types. C does not have a way for a function >>> to take an argument that is either an array or a function. There >>> is a way to take pointers to those things, but not the things >>> themselves. Arrays and functions are second-class values in C. >> >> That's a good point. It's not just arrays that can't be passed by >> value (because the language says so) but also functions (because its >> not meaningful). >> >> Yet, although pointers to arrays and function can be passed (without >> even doing anything special like using &), you are not allowed to say >> that anything is passed by reference in C! >> >> The automatic conversion to a pointer, which is also a feature of >> true pass-by-reference, doesn't count. >> >> Not needing an explicit deref inside the callee (another >> characteristic of pass-by-reference) doesn't count either. > > It does not count, because automatic conversion to a pointer is not > something that happens only during parameter passing. For arrays, it > happens in all contexts except sizeof(). For functions, it happens in > all contexts except function call. Or, may be, including function call, > in this case (but not in case of arrays) it depends on point of view. > Suppose that was to happen in all contexts, not just for arrays and functions, but for all types. That means that if A, B, C were numbers, then any call such as F(A, B, C) would pass the addresses of the numbers rather than their values. According to what people have said, C would STILL be a language that passed thing by value, and never by automatic reference. Yet in my scenario that now sounds ludicrous.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-11 11:31 +0300 |
| Message-ID | <20240711113132.000015a4@yahoo.com> |
| In reply to | #387011 |
On Wed, 10 Jul 2024 20:04:35 +0100 bart <bc@freeuk.com> wrote: > On 10/07/2024 19:39, Michael S wrote: > > On Wed, 10 Jul 2024 18:30:54 +0100 > > bart <bc@freeuk.com> wrote: > > > >> On 10/07/2024 16:48, Tim Rentsch wrote: > >>> bart <bc@freeuk.com> writes: > >>> > >>>> I earlier asked this: > >>>> > >>>> "So if arrays aren't passed by value in C, and they aren't passed > >>>> by reference, then how the hell ARE they passed?!" > >>> > >>> They aren't. C allows lots of things to be passed as an argument > >>> to a function: several varieties of numeric values, structs, > >>> unions, and pointers, including both pointers to object types and > >>> pointers to function types. C does not have a way for a function > >>> to take an argument that is either an array or a function. There > >>> is a way to take pointers to those things, but not the things > >>> themselves. Arrays and functions are second-class values in C. > >> > >> That's a good point. It's not just arrays that can't be passed by > >> value (because the language says so) but also functions (because > >> its not meaningful). > >> > >> Yet, although pointers to arrays and function can be passed > >> (without even doing anything special like using &), you are not > >> allowed to say that anything is passed by reference in C! > >> > >> The automatic conversion to a pointer, which is also a feature of > >> true pass-by-reference, doesn't count. > >> > >> Not needing an explicit deref inside the callee (another > >> characteristic of pass-by-reference) doesn't count either. > > > > It does not count, because automatic conversion to a pointer is not > > something that happens only during parameter passing. For arrays, it > > happens in all contexts except sizeof(). For functions, it happens > > in all contexts except function call. Or, may be, including > > function call, in this case (but not in case of arrays) it depends > > on point of view. > > Suppose that was to happen in all contexts, not just for arrays and > functions, but for all types. > > That means that if A, B, C were numbers, then any call such as F(A, > B, C) would pass the addresses of the numbers rather than their > values. > > According to what people have said, C would STILL be a language that > passed thing by value, and never by automatic reference. > > Yet in my scenario that now sounds ludicrous. > No, if dereference operator would be required consistently in nearly all contexts then it would not be ludicrous at all.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-11 04:49 -0700 |
| Message-ID | <865xtc87yo.fsf@linuxsc.com> |
| In reply to | #387011 |
bart <bc@freeuk.com> writes: > On 10/07/2024 19:39, Michael S wrote: > >> On Wed, 10 Jul 2024 18:30:54 +0100 >> bart <bc@freeuk.com> wrote: >> >>> On 10/07/2024 16:48, Tim Rentsch wrote: >>> >>>> bart <bc@freeuk.com> writes: >>>> >>>> I earlier asked this: >>>> >>>>> "So if arrays aren't passed by value in C, and they aren't passed >>>>> by reference, then how the hell ARE they passed?!" >>>> >>>> They aren't. C allows lots of things to be passed as an argument >>>> to a function: several varieties of numeric values, structs, >>>> unions, and pointers, including both pointers to object types and >>>> pointers to function types. C does not have a way for a function >>>> to take an argument that is either an array or a function. There >>>> is a way to take pointers to those things, but not the things >>>> themselves. Arrays and functions are second-class values in C. >>> >>> That's a good point. It's not just arrays that can't be passed by >>> value (because the language says so) but also functions (because its >>> not meaningful). >>> >>> Yet, although pointers to arrays and function can be passed (without >>> even doing anything special like using &), you are not allowed to say >>> that anything is passed by reference in C! >>> >>> The automatic conversion to a pointer, which is also a feature of >>> true pass-by-reference, doesn't count. >>> >>> Not needing an explicit deref inside the callee (another >>> characteristic of pass-by-reference) doesn't count either. >> >> It does not count, because automatic conversion to a pointer is not >> something that happens only during parameter passing. For arrays, it >> happens in all contexts except sizeof(). For functions, it happens in >> all contexts except function call. Or, may be, including function call, >> in this case (but not in case of arrays) it depends on point of view. > > Suppose that was to happen in all contexts, not just for arrays and > functions, but for all types. > > That means that if A, B, C were numbers, then any call such as F(A, B, > C) would pass the addresses of the numbers rather than their values. > > According to what people have said, C would STILL be a language that > passed thing by value, and never by automatic reference. First, the scheme that you outline is either dumb or disingenuous (or perhaps both). Second, the argument you're making is purely ad hominem: it isn't about what is true but about what it is people will say, or at least what you think they would say. Third, none of this changes the underlying reality. Whatever people might say about your hypothetical scenario, or whatever it is you think they would say, it doesn't alter the fact that in C all function arguments are passed by value, and not by reference.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-11 14:00 +0100 |
| Message-ID | <v6ol14$2fdrj$1@dont-email.me> |
| In reply to | #387055 |
On 11/07/2024 12:49, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> According to what people have said, C would STILL be a language that >> passed thing by value, and never by automatic reference. > > First, the scheme that you outline is either dumb or disingenuous > (or perhaps both). > > Second, the argument you're making is purely ad hominem: it > isn't about what is true but about what it is people will say, or > at least what you think they would say. > > Third, none of this changes the underlying reality. Whatever > people might say about your hypothetical scenario, or whatever it > is you think they would say, it doesn't alter the fact that in C > all function arguments are passed by value, and not by reference. People don't write software based on the the precise, pedantic details of what a language reference says, which are always to use the same carefully selected set of terms. They want to write programs that do useful tasks. If that task calls for a function that manipulates arrays as though they were passed by reference, then, guess what, they will use a C function that the standard says always passes things by value. For that purpose, in the mind of the user, it does the same job as 'by by reference'. That it does so by some other quirks (array decay, and the ability to index pointers as thought they were arrays), is by the by. I understand that in this newsgroup, most posters are only interested in what the Standard says and little else, and will pounce upon any turns of phrase, any nomenclature, that deviate even slightly from what it says in that document. I also understand that this is not comp.std.c Meanwhile, the internet abounds with quotes like this about C: "When we pass the address of an array while calling a function then this is called function call by reference." "Basically, in C, function parameters that are arrays are passed by reference, by default." Yes, I get that such lax informality would annoy the people here.
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web