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 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-15 23:56 -0700 |
| Message-ID | <8634m0ccjc.fsf@linuxsc.com> |
| In reply to | #388090 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>> >>>>> On 2024-07-12, bart <bc@freeuk.com> wrote: >>>>> >>>>>> It's clearly not by value. It's apparently not by reference. You >>>>>> can't get away with saying they are not passed, as clearly >>>>>> functions *can* access array data via parameters. >>>>> >>>>> Actually, you probably can get away with saying that it is "passed >>>>> by reference". >>>>> >>>>> The formal term that doesn't apply is "call by reference"; that's >>>>> what C doesn't have. >>>>> >>>>> "call by reference" emphasizes that the function call mechanism >>>>> provides the reference semantics for a formal parameter, not that >>>>> some arbitrary means of passage of the data has reference >>>>> semantics. >>>> >>>> [...] >>>> >>>> I know that "call by reference" is the usual formal term, but I >>>> personally prefer "pass by reference". >>>> >>>> The terms "call by reference" and "call by value" emphasize the >>>> call, implying that all arguments in a given call are passed with >>>> the same mechanism. In some languages that's true (C argument >>>> passing is purely by value, and Fortran, as I understand it, is >>>> purely by reference), but in others (C++, Pascal, Ada) you can >>>> select by-value or by-reference for each parameter. "Pass by >>>> (reference|value)" feels more precise. >>>> >>>> I haven't checked, but I suspect the terms "call by (reference|value)" >>>> predate languages that allowed the mechanism to be specified for each >>>> parameter. >>> >>> I suspect that your guess here is influenced more by what you would >>> like to be true than what is likely to be true. >> >> I was influenced by what I thought made the most sense. >> >>> What is likely to be true is that these terms entered the language >>> at essentially the same time as the original Algol. Algol 60 has >>> both call by name and call by value, referred to by those names in >>> the Algol 60 Report, and selectable on a per-parameter basis. >>> >>> By contrast the precursor to Algol 60, the International Algebraic >>> Language or IAL for short (and referred to after the fact as Algol >>> 58) did not use either term, and described the coupling between >>> arguments and parameters only in somewhat vague English prose that >>> left unclear exactly what the binding mechanism(s) were to be. >>> (There was a description for functions and a separate description >>> for procedures, not quite the same, and both not completely clear >>> exactly what the mechanism was meant to be.) >>> >>> Thus it seems likely that the terms call by name, call by value, >>> and perhaps other similar terms, first arose during the discussions >>> of the Algol 60 working group in the late 1950s, and entered the >>> general lexicon with or perhaps slightly before the publication of >>> the Algol 60 Report, which describes and allows both call by name >>> and call by value, selectable on a per-parameter base, and referred >>> to by those names in the published Algol 60 Report. >> >> Yes, that does seem likely. >> >> I'm mildly disappointed. Since arguments are *passed* and >> functions/procedures are *called*, surely it would have made more sense >> to use "pass by value" rather than "call by value", especially in a >> language where the mechanism can vary per parameter. > > All that is, I think, due to subsequent changes in (English) language > use. In Algol 60, procedures were invoked and /parameters/ were called > by value or name. Maybe the term was intended to reflect the idea that > the code in the body "called for the value" of the parameter. > > The word "call" now refers, almost universally, to invoking a function > or procedure. As a result, the idea of "calling a parameter" reads > oddly, but at the time I'm sure it seemed perfectly reasonable. This view simply doesn't match the language and phrasing used during the time Algol was being developed. Both the Algol 60 report and the preliminary IAL report (aka Algol 58) routinely use the word call in connection with outside use of a procedure. Algol 60 uses the word "invoke" exactly twice: once in relation to procedures (where "call" is also used), and once in relation to functions. Algol 58 uses the word call pretty much the same way that Algol 60 does, but doesn't use the word "invoke" at all; the verb "initiate" a procedure in Algol 58 turned into "invoke" a procedure in Algol 60. Clearly using "call" was already well established in the late 1950s, and "invoke" came later. Algol 58 (loosely) defined the semantics of procedure call by textual expansion of the procedure body at the call site, substituting the text of actual parameters for each occurrence of the corresponding formal parameter in the procedure body. The actual rules are more complicated, due to there being different "styles" (my word) of parameters, and because there were output parameters as well as input parameters. Basically though the meaning was what would later be termed "call by name", with some restrictions on what forms of actual parameters were allowed. Algol 60 simplified the rules by reducing the number of cases to just two: either the actual parameter was textually substituted for the formal parameter in the expansion (call by name), or the value of the actual parameter expression was in effect assigned to a local variable corresponding to the formal parameter (call by value), which did not have a corresponding case in Algol 58. The "call by" in "call by name" and "call by value" refers to how the expansion is done in elaborating the procedure call. The "call by" is not what sort of thing is passed, but what action is taken in doing the substitution/expansion. >> (Yes, this is my opinion.) >> >> If there's some reason why "call by value" actually made more sense >> than "pass by value", I'm not aware of it. >> >> Since the phrase "pass by value" is now in common use, I'll >> continue to use that term in preference to "call by value" >> (likewise "by reference"). > > I use those terms too. It would be confusing these days to talk > about calling a parameter, and the phrase "call by value" suggests > (as it never did at the time) something so do with the function > calling mechanism in general. Yes it did. It is only now that we have a different idea about how functions and procedures are called that it seems like it doesn't. But in Algol 60 it certainly did have something to do with how a function reference was elaborated (aka called). > This is compounded by the fact that modern programming languages > has almost universally settled on calling all parameters by value > (to the use the old phrase) so, usually, the terms can, in fact, > be used to talk about the function calling mechanism. The rationale here seems circular to me, and also not an accurate picture of the programming language landscape. Passing a pointer by value is not the same as a call be reference. Passing a lambda by value is not the same as a call by name. Shortly after Algol 60, FORTRAN adopted call by value/result, also called call by copy in/copy out. Ada has INOUT, does it not? Logic programming languages have call by unification. All of these cases show why "pass by" is not a good universal fit. At their lowest level, computers are simply slinging bits around. In some sense everything is done in terms of "values". Thinking in terms of what "value" is "passed" serves to reinforce an imperative mind set, and there is already too much of that. For these reasons and more I disdain the hoi polloi phrasing of "pass by" for distinguishing different parameter modalities.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-16 03:37 -0700 |
| Message-ID | <87zfo7rija.fsf@nosuchdomain.example.com> |
| In reply to | #388406 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben@bsb.me.uk> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>>> On 2024-07-12, bart <bc@freeuk.com> wrote:
>>>>>>> It's clearly not by value. It's apparently not by reference. You
>>>>>>> can't get away with saying they are not passed, as clearly
>>>>>>> functions *can* access array data via parameters.
>>>>>>
>>>>>> Actually, you probably can get away with saying that it is "passed
>>>>>> by reference".
>>>>>>
>>>>>> The formal term that doesn't apply is "call by reference"; that's
>>>>>> what C doesn't have.
>>>>>>
>>>>>> "call by reference" emphasizes that the function call mechanism
>>>>>> provides the reference semantics for a formal parameter, not that
>>>>>> some arbitrary means of passage of the data has reference
>>>>>> semantics.
>>>>>
>>>>> [...]
>>>>>
>>>>> I know that "call by reference" is the usual formal term, but I
>>>>> personally prefer "pass by reference".
>>>>>
>>>>> The terms "call by reference" and "call by value" emphasize the
>>>>> call, implying that all arguments in a given call are passed with
>>>>> the same mechanism. In some languages that's true (C argument
>>>>> passing is purely by value, and Fortran, as I understand it, is
>>>>> purely by reference), but in others (C++, Pascal, Ada) you can
>>>>> select by-value or by-reference for each parameter. "Pass by
>>>>> (reference|value)" feels more precise.
>>>>>
>>>>> I haven't checked, but I suspect the terms "call by (reference|value)"
>>>>> predate languages that allowed the mechanism to be specified for each
>>>>> parameter.
>>>>
>>>> I suspect that your guess here is influenced more by what you would
>>>> like to be true than what is likely to be true.
>>>
>>> I was influenced by what I thought made the most sense.
>>>
>>>> What is likely to be true is that these terms entered the language
>>>> at essentially the same time as the original Algol. Algol 60 has
>>>> both call by name and call by value, referred to by those names in
>>>> the Algol 60 Report, and selectable on a per-parameter basis.
>>>>
>>>> By contrast the precursor to Algol 60, the International Algebraic
>>>> Language or IAL for short (and referred to after the fact as Algol
>>>> 58) did not use either term, and described the coupling between
>>>> arguments and parameters only in somewhat vague English prose that
>>>> left unclear exactly what the binding mechanism(s) were to be.
>>>> (There was a description for functions and a separate description
>>>> for procedures, not quite the same, and both not completely clear
>>>> exactly what the mechanism was meant to be.)
>>>>
>>>> Thus it seems likely that the terms call by name, call by value,
>>>> and perhaps other similar terms, first arose during the discussions
>>>> of the Algol 60 working group in the late 1950s, and entered the
>>>> general lexicon with or perhaps slightly before the publication of
>>>> the Algol 60 Report, which describes and allows both call by name
>>>> and call by value, selectable on a per-parameter base, and referred
>>>> to by those names in the published Algol 60 Report.
>>>
>>> Yes, that does seem likely.
>>>
>>> I'm mildly disappointed. Since arguments are *passed* and
>>> functions/procedures are *called*, surely it would have made more sense
>>> to use "pass by value" rather than "call by value", especially in a
>>> language where the mechanism can vary per parameter.
>>
>> All that is, I think, due to subsequent changes in (English) language
>> use. In Algol 60, procedures were invoked and /parameters/ were called
>> by value or name. Maybe the term was intended to reflect the idea that
>> the code in the body "called for the value" of the parameter.
>>
>> The word "call" now refers, almost universally, to invoking a function
>> or procedure. As a result, the idea of "calling a parameter" reads
>> oddly, but at the time I'm sure it seemed perfectly reasonable.
>
> This view simply doesn't match the language and phrasing used
> during the time Algol was being developed. Both the Algol 60
> report and the preliminary IAL report (aka Algol 58) routinely
> use the word call in connection with outside use of a procedure.
> Algol 60 uses the word "invoke" exactly twice: once in relation
> to procedures (where "call" is also used), and once in relation
> to functions. Algol 58 uses the word call pretty much the same
> way that Algol 60 does, but doesn't use the word "invoke" at all;
> the verb "initiate" a procedure in Algol 58 turned into "invoke"
> a procedure in Algol 60. Clearly using "call" was already well
> established in the late 1950s, and "invoke" came later.
>
> Algol 58 (loosely) defined the semantics of procedure call by
> textual expansion of the procedure body at the call site,
> substituting the text of actual parameters for each occurrence of
> the corresponding formal parameter in the procedure body. The
> actual rules are more complicated, due to there being different
> "styles" (my word) of parameters, and because there were output
> parameters as well as input parameters. Basically though the
> meaning was what would later be termed "call by name", with some
> restrictions on what forms of actual parameters were allowed.
>
> Algol 60 simplified the rules by reducing the number of cases to
> just two: either the actual parameter was textually substituted
> for the formal parameter in the expansion (call by name), or the
> value of the actual parameter expression was in effect assigned
> to a local variable corresponding to the formal parameter (call
> by value), which did not have a corresponding case in Algol 58.
> The "call by" in "call by name" and "call by value" refers to how
> the expansion is done in elaborating the procedure call. The
> "call by" is not what sort of thing is passed, but what action is
> taken in doing the substitution/expansion.
>
>>> (Yes, this is my opinion.)
>>>
>>> If there's some reason why "call by value" actually made more sense
>>> than "pass by value", I'm not aware of it.
>>>
>>> Since the phrase "pass by value" is now in common use, I'll
>>> continue to use that term in preference to "call by value"
>>> (likewise "by reference").
>>
>> I use those terms too. It would be confusing these days to talk
>> about calling a parameter, and the phrase "call by value" suggests
>> (as it never did at the time) something so do with the function
>> calling mechanism in general.
>
> Yes it did. It is only now that we have a different idea about
> how functions and procedures are called that it seems like it
> doesn't. But in Algol 60 it certainly did have something to do
> with how a function reference was elaborated (aka called).
>
>> This is compounded by the fact that modern programming languages
>> has almost universally settled on calling all parameters by value
>> (to the use the old phrase) so, usually, the terms can, in fact,
>> be used to talk about the function calling mechanism.
>
> The rationale here seems circular to me, and also not an accurate
> picture of the programming language landscape.
>
> Passing a pointer by value is not the same as a call be reference.
>
> Passing a lambda by value is not the same as a call by name.
>
> Shortly after Algol 60, FORTRAN adopted call by value/result,
> also called call by copy in/copy out. Ada has INOUT, does
> it not?
>
> Logic programming languages have call by unification.
>
> All of these cases show why "pass by" is not a good universal
> fit.
How? All I see is that you've used the word "call" rather than "pass"
in each instance -- and in each instance, I find "pass" clearer (except
perhaps in the case of "call by name", for reasons I won't go into for
the moment).
> At their lowest level, computers are simply slinging bits around.
> In some sense everything is done in terms of "values". Thinking
> in terms of what "value" is "passed" serves to reinforce an
> imperative mind set, and there is already too much of that. For
> these reasons and more I disdain the hoi polloi phrasing of "pass
> by" for distinguishing different parameter modalities.
I honestly do not understand the argument you're making in favor of
"call by" over "pass by". ("Hoi polloi"? Seriously?)
Procedures and functions are "called", yes? They're not "passed",
except perhaps as an argument to another procedure or function.
Arguments to procedures and functions are "passed", yes? Would it make
sense to say that an argument is "called"? (I note that the Algol 60
report never refers to parameters being "called" other than in the
phrases "call by value" and "call by name".)
If you think that "calling an argument" or "calling a parameter" makes
sense, perhaps that's the root of the disagreement. Do you?
In most languages that supports by both by-value and by-reference
mechanisms, a single call can have one by-value argument and one
by-reference argument, or any other combination. Using C++ as a
convenient example:
void func(int by_value, int& by_reference) { /* ... */ }
int x, y;
func(x, y);
In the third line, there is just one call, but two arguments,
corresponding to two parameters. It's not the call that's by-value or
by-reference, it's each argument that's *passed* (using the mechanism
specified on the parameter).
Other than historical precedent from Algol and friends, why do you think
it's better to use "call by value" and "call by reference" rather than
"pass by value" and "pass by reference", when the mechanism applies
individually to each argument, not to the call as a whole?
Do you object to using the word "pass" (without "by ...") to refer to
the arguments to a function? If not, why do you object to "pass by ..."
to refer to the mechanism?
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-09-16 18:15 +0200 |
| Message-ID | <vc9lia$2uha1$1@dont-email.me> |
| In reply to | #388410 |
On 16.09.2024 12:37, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>> [ snip nice write-up ]
>
> I honestly do not understand the argument you're making in favor of
> "call by" over "pass by". ("Hoi polloi"? Seriously?)
>
> Procedures and functions are "called", yes? They're not "passed",
> except perhaps as an argument to another procedure or function.
>
> Arguments to procedures and functions are "passed", yes? Would it make
> sense to say that an argument is "called"? (I note that the Algol 60
> report never refers to parameters being "called" other than in the
> phrases "call by value" and "call by name".)
>
> If you think that "calling an argument" or "calling a parameter" makes
> sense, perhaps that's the root of the disagreement. Do you?
>
> [ snip example and associated explanation ]
>
> Other than historical precedent from Algol and friends, why do you think
> it's better to use "call by value" and "call by reference" rather than
> "pass by value" and "pass by reference", when the mechanism applies
> individually to each argument, not to the call as a whole?
>
> Do you object to using the word "pass" (without "by ...") to refer to
> the arguments to a function? If not, why do you object to "pass by ..."
> to refer to the mechanism?
Maybe it's useful to take a textbook (or memories from lectures) to
see how in these past days parameter handling was expressed/explained.
In the domain of German speaking countries - isn't Tim located there?
(I somehow got the impression) - we've heard about "Parameterübergabe";
"Übergabe" means passing, transferring, handing over, transmitting, etc.
Because of that - and because I could not follow the thoughts of Tim's
last paragraph with his conclusion; I didn't find it convincing - I'd
think that "passing" would fit better, also in the light of historic
usage [hereabouts], even though I've often heared (and also used) the
phrase "call by" in the English CS domain in the past (and probably
still used to it).
Janis
PS: And a smile on your comment: ("Hoi polloi"? Seriously?) :-)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-17 06:15 -0700 |
| Message-ID | <86wmjaa0al.fsf@linuxsc.com> |
| In reply to | #388416 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: [excerpted for brevity] > In the domain of German speaking countries - isn't Tim located there? > (I somehow got the impression) - we've heard about "Parameterubergabe"; > [..] means passing, transferring, handing over, transmitting, etc. > > Because of that - and because I could not follow the thoughts of Tim's > last paragraph with his conclusion; I didn't find it convincing - I'd > think that "passing" would fit better, also in the light of historic > usage [hereabouts], even though I've often heared (and also used) the > phrase "call by" in the English CS domain in the past (and probably > still used to it). If you have something to say to me please respond to my posting directly.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-09-17 19:07 +0200 |
| Message-ID | <vccd1a$3k74f$1@dont-email.me> |
| In reply to | #388425 |
On 17.09.2024 15:15, Tim Rentsch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > > [excerpted for brevity] > >> In the domain of German speaking countries - isn't Tim located there? >> (I somehow got the impression) - we've heard about "Parameterubergabe"; >> [..] means passing, transferring, handing over, transmitting, etc. >> >> Because of that - and because I could not follow the thoughts of Tim's >> last paragraph with his conclusion; I didn't find it convincing - I'd >> think that "passing" would fit better, also in the light of historic >> usage [hereabouts], even though I've often heared (and also used) the >> phrase "call by" in the English CS domain in the past (and probably >> still used to it). > > If you have something to say to me please respond to my posting > directly. I respond at the place that appears most appropriate for what I want to say in the context I want to reply to. I'm not here to serve your, umm, "standards" (to avoid the word "idee fixe"); and you just have to accept that[*], I fear. I'm sure others here have no problem to go upward the thread hierarchy one more level to find your text that I deliberately didn't quote for the reason (still quoted above) I mentioned; I don't think they're worth quoting, they provide no argument, they were fuzzy. (Of course all only IMO.) Janis [*] I'm not here to suggest (as you do) anything to you, but you should probably ignore my posts if you have problems with the style or content.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-17 12:52 -0700 |
| Message-ID | <86jzfa9hxn.fsf@linuxsc.com> |
| In reply to | #388429 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 17.09.2024 15:15, Tim Rentsch wrote: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >> [excerpted for brevity] >> >>> In the domain of German speaking countries - isn't Tim located there? >>> (I somehow got the impression) - we've heard about "Parameterubergabe"; >>> [..] means passing, transferring, handing over, transmitting, etc. >>> >>> Because of that - and because I could not follow the thoughts of Tim's >>> last paragraph with his conclusion; I didn't find it convincing - I'd >>> think that "passing" would fit better, also in the light of historic >>> usage [hereabouts], even though I've often heared (and also used) the >>> phrase "call by" in the English CS domain in the past (and probably >>> still used to it). >> >> If you have something to say to me please respond to my posting >> directly. > > I respond at the place that appears most appropriate for what > I want to say in the context I want to reply to. I'm not here > to serve your, umm, "standards" (to avoid the word "idee fixe"); > and you just have to accept that[*], I fear. > > I'm sure others here have no problem to go upward the thread > hierarchy one more level to find your text that I deliberately > didn't quote for the reason (still quoted above) I mentioned; > I don't think they're worth quoting, they provide no argument, > they were fuzzy. (Of course all only IMO.) My statement was meant as a request, not a demand. I asked because I wasn't sure if you had something in particular to say to me or if you were just talking more or less aimlessly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-26 09:37 -0700 |
| Message-ID | <867cay74m4.fsf@linuxsc.com> |
| In reply to | #388410 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>>>>> I know that "call by reference" is the usual formal term, but
>>>>>> I personally prefer "pass by reference".
>>>>>>
>>>>>> The terms "call by reference" and "call by value" emphasize
>>>>>> the call, implying that all arguments in a given call are
>>>>>> passed with the same mechanism. In some languages that's
>>>>>> true (C argument passing is purely by value, and Fortran, as
>>>>>> I understand it, is purely by reference), but in others (C++,
>>>>>> Pascal, Ada) you can select by-value or by-reference for each
>>>>>> parameter. "Pass by (reference|value)" feels more precise.
>>>>>>
>>>>>> I haven't checked, but I suspect the terms "call by
>>>>>> (reference|value)" predate languages that allowed the
>>>>>> mechanism to be specified for each parameter.
>>>>>
>>>>> I suspect that your guess here is influenced more by what
>>>>> you would like to be true than what is likely to be true.
>>>>
>>>> I was influenced by what I thought made the most sense.
>>>>
>>>>> What is likely to be true is that these terms entered the
>>>>> language at essentially the same time as the original Algol.
>>>>> Algol 60 has both call by name and call by value, referred to
>>>>> by those names in the Algol 60 Report, and selectable on a
>>>>> per-parameter basis.
>>>>>
>>>>> By contrast the precursor to Algol 60, the International
>>>>> Algebraic Language or IAL for short (and referred to after the
>>>>> fact as Algol 58) did not use either term, and described the
>>>>> coupling between arguments and parameters only in somewhat
>>>>> vague English prose that left unclear exactly what the binding
>>>>> mechanism(s) were to be. (There was a description for
>>>>> functions and a separate description for procedures, not quite
>>>>> the same, and both not completely clear exactly what the
>>>>> mechanism was meant to be.)
>>>>>
>>>>> Thus it seems likely that the terms call by name, call by
>>>>> value, and perhaps other similar terms, first arose during the
>>>>> discussions of the Algol 60 working group in the late 1950s,
>>>>> and entered the general lexicon with or perhaps slightly before
>>>>> the publication of the Algol 60 Report, which describes and
>>>>> allows both call by name and call by value, selectable on a
>>>>> per-parameter base, and referred to by those names in the
>>>>> published Algol 60 Report.
>>>>
>>>> Yes, that does seem likely.
>>>>
>>>> I'm mildly disappointed. Since arguments are *passed* and
>>>> functions/procedures are *called*, surely it would have made
>>>> more sense to use "pass by value" rather than "call by value",
>>>> especially in a language where the mechanism can vary per
>>>> parameter.
>>>
>>> All that is, I think, due to subsequent changes in (English)
>>> language use. In Algol 60, procedures were invoked and
>>> /parameters/ were called by value or name. Maybe the term was
>>> intended to reflect the idea that the code in the body "called
>>> for the value" of the parameter.
>>>
>>> The word "call" now refers, almost universally, to invoking a
>>> function or procedure. As a result, the idea of "calling a
>>> parameter" reads oddly, but at the time I'm sure it seemed
>>> perfectly reasonable.
>>
>> This view simply doesn't match the language and phrasing used
>> during the time Algol was being developed. Both the Algol 60
>> report and the preliminary IAL report (aka Algol 58) routinely
>> use the word call in connection with outside use of a procedure.
>> Algol 60 uses the word "invoke" exactly twice: once in relation
>> to procedures (where "call" is also used), and once in relation
>> to functions. Algol 58 uses the word call pretty much the same
>> way that Algol 60 does, but doesn't use the word "invoke" at all;
>> the verb "initiate" a procedure in Algol 58 turned into "invoke"
>> a procedure in Algol 60. Clearly using "call" was already well
>> established in the late 1950s, and "invoke" came later.
>>
>> Algol 58 (loosely) defined the semantics of procedure call by
>> textual expansion of the procedure body at the call site,
>> substituting the text of actual parameters for each occurrence of
>> the corresponding formal parameter in the procedure body. The
>> actual rules are more complicated, due to there being different
>> "styles" (my word) of parameters, and because there were output
>> parameters as well as input parameters. Basically though the
>> meaning was what would later be termed "call by name", with some
>> restrictions on what forms of actual parameters were allowed.
>>
>> Algol 60 simplified the rules by reducing the number of cases to
>> just two: either the actual parameter was textually substituted
>> for the formal parameter in the expansion (call by name), or the
>> value of the actual parameter expression was in effect assigned
>> to a local variable corresponding to the formal parameter (call
>> by value), which did not have a corresponding case in Algol 58.
>> The "call by" in "call by name" and "call by value" refers to how
>> the expansion is done in elaborating the procedure call. The
>> "call by" is not what sort of thing is passed, but what action is
>> taken in doing the substitution/expansion.
>>
>>>> (Yes, this is my opinion.)
>>>>
>>>> If there's some reason why "call by value" actually made more
>>>> sense than "pass by value", I'm not aware of it.
>>>>
>>>> Since the phrase "pass by value" is now in common use, I'll
>>>> continue to use that term in preference to "call by value"
>>>> (likewise "by reference").
>>>
>>> I use those terms too. It would be confusing these days to talk
>>> about calling a parameter, and the phrase "call by value" suggests
>>> (as it never did at the time) something so do with the function
>>> calling mechanism in general.
>>
>> Yes it did. It is only now that we have a different idea about
>> how functions and procedures are called that it seems like it
>> doesn't. But in Algol 60 it certainly did have something to do
>> with how a function reference was elaborated (aka called).
>>
>>> This is compounded by the fact that modern programming languages
>>> has almost universally settled on calling all parameters by value
>>> (to the use the old phrase) so, usually, the terms can, in fact,
>>> be used to talk about the function calling mechanism.
>>
>> The rationale here seems circular to me, and also not an accurate
>> picture of the programming language landscape.
>>
>> Passing a pointer by value is not the same as a call be reference.
>>
>> Passing a lambda by value is not the same as a call by name.
>>
>> Shortly after Algol 60, FORTRAN adopted call by value/result,
>> also called call by copy in/copy out. Ada has INOUT, does
>> it not?
>>
>> Logic programming languages have call by unification.
>>
>> All of these cases show why "pass by" is not a good universal
>> fit.
>
> How? All I see is that you've used the word "call" rather than
> "pass" in each instance -- and in each instance, I find "pass"
> clearer (except perhaps in the case of "call by name", for reasons
> I won't go into for the moment).
>
>> At their lowest level, computers are simply slinging bits around.
>> In some sense everything is done in terms of "values". Thinking
>> in terms of what "value" is "passed" serves to reinforce an
>> imperative mind set, and there is already too much of that. For
>> these reasons and more I disdain the hoi polloi phrasing of "pass
>> by" for distinguishing different parameter modalities.
>
> I honestly do not understand the argument you're making in favor of
> "call by" over "pass by". ("Hoi polloi"? Seriously?)
>
> Procedures and functions are "called", yes? They're not "passed",
> except perhaps as an argument to another procedure or function.
>
> Arguments to procedures and functions are "passed", yes? Would it
> make sense to say that an argument is "called"? (I note that the
> Algol 60 report never refers to parameters being "called" other than
> in the phrases "call by value" and "call by name".)
>
> If you think that "calling an argument" or "calling a parameter"
> makes sense, perhaps that's the root of the disagreement. Do you?
>
> In most languages that supports by both by-value and by-reference
> mechanisms, a single call can have one by-value argument and one
> by-reference argument, or any other combination. Using C++ as a
> convenient example:
>
> void func(int by_value, int& by_reference) { /* ... */ }
> int x, y;
> func(x, y);
>
> In the third line, there is just one call, but two arguments,
> corresponding to two parameters. It's not the call that's by-value
> or by-reference, it's each argument that's *passed* (using the
> mechanism specified on the parameter).
>
> Other than historical precedent from Algol and friends, why do you
> think it's better to use "call by value" and "call by reference"
> rather than "pass by value" and "pass by reference", when the
> mechanism applies individually to each argument, not to the call as
> a whole?
>
> Do you object to using the word "pass" (without "by ...") to refer
> to the arguments to a function? If not, why do you object to "pass
> by ..." to refer to the mechanism?
After reading your message I spent several hours thinking about how
to answer before starting to write a reply. I ask that you take a
commensurate amount of time considering my comments before composing
any followup.
I think it's fair to say we are looking at this question from
different perspectives. I see where you're coming from; I get
why you're saying what you say. For the other direction my guess
is that my perspective either isn't apparent or isn't one that
makes sense to you. Let me see if I can shed some light on that.
The "call by" in Algol 60 is used to characterize /parameters/ of
a function definition. It's important that "call" is used in the
active voice; parameters are not "called". The word "call" has
changed in meaning since its use in the Algol 60 report, so let's
consider some plausible alternatives (always in the active voice):
associate by
elaborate by
expand by
instantiate by
substitute by
For an example, let's suppose we have a by-name parameter (and for
now let's use the "associate by" phrasing). Writing in a made-up
C-like language that allows different parameter modalities, we
could write
void
by_name_example( unsigned by_name i, double by_name v ){
for( i = 0; i < 100; i++ ) v = 1. / ((i+1)*(i+1));
}
and a call
unsigned foo;
double terms[100];
by_name_example( foo, terms[foo] );
In calling by_name_example(), we associate argument 'foo' with
parameter 'i', and associate argument 'terms[foo]' with 'v'.
The associations are done by-name of course, because of how
the two parameters are declared.
Some history could be helpful here. In the Algol 60 report,
function calls were explained, or defined, as a kind of textual
substitution. In effect the body of a function definition would
be substituted for the call. (The original description uses a
different phrasing but the effect is the same.) Because of that
the phrasing "call by" makes sense: arguments for different kinds
of parameters are expanded or substituted differently. The
meanings of the different parameter modes were explained in terms
of the abstract semantics, and not in terms of how they might be
implemented. Indeed, when the Algol 60 report was first published
it wasn't yet understood how to implement call by name. (Or
perhaps it was discovered just slightly before publication, I'm
not sure of the exact timing.)
Here is an example function with a call by reference parameter:
void
accumulate( unsigned v, unsigned by_reference total ){
total += v;
}
Now let's consider some calls:
unsigned long foo = 0;
accumulate( 3, 0 );
accumulate( 5, foo );
Are these calls legal or not legal? (Either answer is possible.)
This illustrates the point that it isn't so important /what/ is
conveyed as it is /how/ the call is done. Saying these are "pass
by reference" emphasizes /what kind of information/ is conveyed
but downplays the more important aspect of /how an argument is
associated with the parameter/.
A different example, with a FORTRAN-style parameter mode (which is
call by value-result, aka call by copy in/copy out):
int
exchange( unsigned by_in_out x, unsigned by_in_out y ){
unsigned a = x, b = y;
x = b, y = a;
/* ... some other stuff ... */
}
This function exchanges its arguments, and also does some other
stuff. However, it's important that updating of the arguments
happens only when the function returns; if "other stuff" makes
use of the arguments (not by way of the parameters x and y but via
some other path), it will see the original values of those
arguments, not the values assigned on the second line of the
function. Any call by value-result parameters changes not only
what happens at the call but also what happens at the return;
using "pass by" is not evocative of that meaning.
Suppose we modify the exchange function slightly:
int
exchange_two( unsigned by_in_out x, unsigned by_in_out y ){
unsigned a = x, b = y;
x = b, y = a;
if( something ) longjmp( some_jmp_buff, 23 );
}
If the longjmp() is done, are the arguments corresponding to the
parameters x and y updated or not? (Either answer is possible.)
Here again "pass by" emphasizes what kind of information is
conveyed, now how the call (and return, and possibly the longjump)
is done. A by value-result parameter affects the semantics of
/calling/ a function, and so "call by value-result" is more
suggestive of what is going on than "pass by value-result".
Not all programming languages are procedural. "Pass by" tacitly
assumes a procedural semantics for function calls: it's passive
rather than active, and suggests only conveying of data (and not
doing anything else). Programs written in Prolog do something
very different when they call a "function" (Prolog calls them
something else but operationally it resembles a function call).
In Prolog the semantics of how arguments are associated with
parameters is referred to as "call by unification"; how arguments
interact with the function definition is deeply intertwined with
how "function" calls work in Prolog. "Pass by" doesn't begin to
capture what is going on with how arguments interact with the
bodies of "functions" in Prolog; among other things, parameters
are not necessarily independent, and arguments can't always be
considered only individually (which is not the case for call by
value, call by reference, and call by name).
Saying "pass by" sort of works okay for parameters that are
by-value or by-reference. It doesn't work as well for "by name"
parameters (certainly it is not a name that is being passed), and
really falls down for call by value-result, let alone what happens
with call by unification. Parameters are call-by because they can
affect how the function is called, both going in and going out.
Call-by shows an abstract semantics perspective rather than an
implementation perspective, and because of that applies more
universally than pass-by, which doesn't make sense outside of
a certain limited procedural context.
I guess I'll stop here. I've made a fairly substantial effort to
convey my perspective, but I'm not sure the effort will succeed.
So let me ask this: how would you describe my perspective, and
how would you say it's different from yours? Or has reading my
explanation allowed you to view the question from a different
perspective?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-26 21:28 -0700 |
| Message-ID | <87r095sosv.fsf@nosuchdomain.example.com> |
| In reply to | #388527 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I honestly do not understand the argument you're making in favor of
>> "call by" over "pass by". ("Hoi polloi"? Seriously?)
>>
>> Procedures and functions are "called", yes? They're not "passed",
>> except perhaps as an argument to another procedure or function.
>>
>> Arguments to procedures and functions are "passed", yes? Would it
>> make sense to say that an argument is "called"? (I note that the
>> Algol 60 report never refers to parameters being "called" other than
>> in the phrases "call by value" and "call by name".)
>>
>> If you think that "calling an argument" or "calling a parameter"
>> makes sense, perhaps that's the root of the disagreement. Do you?
>>
>> In most languages that supports by both by-value and by-reference
>> mechanisms, a single call can have one by-value argument and one
>> by-reference argument, or any other combination. Using C++ as a
>> convenient example:
>>
>> void func(int by_value, int& by_reference) { /* ... */ }
>> int x, y;
>> func(x, y);
>>
>> In the third line, there is just one call, but two arguments,
>> corresponding to two parameters. It's not the call that's by-value
>> or by-reference, it's each argument that's *passed* (using the
>> mechanism specified on the parameter).
>>
>> Other than historical precedent from Algol and friends, why do you
>> think it's better to use "call by value" and "call by reference"
>> rather than "pass by value" and "pass by reference", when the
>> mechanism applies individually to each argument, not to the call as
>> a whole?
>>
>> Do you object to using the word "pass" (without "by ...") to refer
>> to the arguments to a function? If not, why do you object to "pass
>> by ..." to refer to the mechanism?
>
> After reading your message I spent several hours thinking about how
> to answer before starting to write a reply. I ask that you take a
> commensurate amount of time considering my comments before composing
> any followup.
I'm not sure what would qualify as "commensurate". I've read your
message at least twice. I will not spend several hours on it,
because I do not think that would be worthwhile.
> I think it's fair to say we are looking at this question from
> different perspectives. I see where you're coming from; I get
> why you're saying what you say. For the other direction my guess
> is that my perspective either isn't apparent or isn't one that
> makes sense to you. Let me see if I can shed some light on that.
I'm glad that you can see where I'm coming from. I regret that I
cannot say the same.
> The "call by" in Algol 60 is used to characterize /parameters/ of
> a function definition. It's important that "call" is used in the
> active voice; parameters are not "called".
https://dl.acm.org/doi/pdf/10.1145/367236.367262
4.7.5.4. A formal parameter which is called by value cannot in
general correspond to [...]
Apparently the author of that section did think that parameters (at
least formal parameters) are "called", or did not clearly express what
he actually meant.
It's a minor point.
I certainly understand that Algol 60's "call by" terminology refers to
parameters.
[...]
> Saying "pass by" sort of works okay for parameters that are
> by-value or by-reference. It doesn't work as well for "by name"
> parameters (certainly it is not a name that is being passed), and
> really falls down for call by value-result, let alone what happens
> with call by unification. Parameters are call-by because they can
> affect how the function is called, both going in and going out.
> Call-by shows an abstract semantics perspective rather than an
> implementation perspective, and because of that applies more
> universally than pass-by, which doesn't make sense outside of
> a certain limited procedural context.
The mode (by value, by reference, by name) refers to *each individual
parameter" in a function (or procedure, or subprogram) call.
> I guess I'll stop here. I've made a fairly substantial effort to
> convey my perspective, but I'm not sure the effort will succeed.
> So let me ask this: how would you describe my perspective, and
> how would you say it's different from yours? Or has reading my
> explanation allowed you to view the question from a different
> perspective?
After reading your message more than once, I still don't understand
why you think that "call by" is clearer than "pass by". I can
see that "pass by" might not completely and correctly describe the
mechanism in the case of some mechanisms other than by-value, but
I don't see how "call by" is better. Again, arguments are passed,
not calls; saying that a parameter is "call by foo" just doesn't
make sense to me.
"Pass by" certainly (in my opinion) makes more sense for C, which
only has by-value.
In K&R (both editions), the header for section 1.8 is "Arguments --
Call by Value", but in the first paragraph of that section we see
"In C, all function arguments are passed “by value.”" My
speculation is that Kernighan used "Call By Value" in the header
because that was the conventional term at the time, but "passed by
value" in the text because it makes more sense.
I won't ask you to reply to this. I think it's unlikely that further
discussion is going to be productive. *If* you can explain *in one
short paragraph" why you think "call by" is better than "pass by",
that might be useful, but I'm not optimistic. Since you and I
have a tendency to talk past each other, perhaps someone else can
summarize the issue, but again, I'm not asking anyone to spend the
time to do that.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-09-27 14:21 +0200 |
| Subject | Wording discussion (was Re: technology discussion) |
| Message-ID | <vd680f$np3c$1@dont-email.me> |
| In reply to | #388528 |
On 27.09.2024 06:28, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> [ pondering about "call by ..." vs. "pass by ..." ] > > I won't ask you to reply to this. I think it's unlikely that further > discussion is going to be productive. *If* you can explain *in one > short paragraph" why you think "call by" is better than "pass by", > that might be useful, but I'm not optimistic. Since you and I > have a tendency to talk past each other, perhaps someone else can > summarize the issue, but again, I'm not asking anyone to spend the > time to do that. (First, I agree with your interpretation of the use of "call" and "pass" in K&R's book; to me that explanation makes sense.) As a non-native speaker - and since I don't mind either of the two wordings used, or choose it depending on context[*] - I'm just asking that out of curiosity... It just occurred to me that there's a lexically similar "call for sth." (in the sense of "require", or maybe "ask for sth"). This is less technical - which might be one problem of the discussion here: technical vs. semantical interpretations. Could that be the reason for historic use of "call-by"? (I'm not sure whether "call for a parameter value" makes sense in a debate that is technically oriented or whether "call by value" could be sort of an abbreviation at all, in the first place. As said; non-native speaker here. Here I'm only interested in the non-technical English language view to better understand where that "call-by" might come from [from an English language perspective].) Janis [*] E.g., I pass the parameter using a call-by-value mechanism, or simplified, I pass the parameter by value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-27 14:09 -0700 |
| Subject | Re: Wording discussion (was Re: technology discussion) |
| Message-ID | <87ed54st14.fsf@nosuchdomain.example.com> |
| In reply to | #388531 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 27.09.2024 06:28, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [ pondering about "call by ..." vs. "pass by ..." ]
>>
>> I won't ask you to reply to this. I think it's unlikely that further
>> discussion is going to be productive. *If* you can explain *in one
>> short paragraph" why you think "call by" is better than "pass by",
>> that might be useful, but I'm not optimistic. Since you and I
>> have a tendency to talk past each other, perhaps someone else can
>> summarize the issue, but again, I'm not asking anyone to spend the
>> time to do that.
>
> (First, I agree with your interpretation of the use of "call"
> and "pass" in K&R's book; to me that explanation makes sense.)
>
> As a non-native speaker - and since I don't mind either of the
> two wordings used, or choose it depending on context[*] - I'm
> just asking that out of curiosity...
>
> It just occurred to me that there's a lexically similar "call
> for sth." (in the sense of "require", or maybe "ask for sth").
> This is less technical - which might be one problem of the
> discussion here: technical vs. semantical interpretations.
> Could that be the reason for historic use of "call-by"? (I'm
> not sure whether "call for a parameter value" makes sense in a
> debate that is technically oriented or whether "call by value"
> could be sort of an abbreviation at all, in the first place.
> As said; non-native speaker here.
> Here I'm only interested in the non-technical English language
> view to better understand where that "call-by" might come from
> [from an English language perspective].)
>
> Janis
>
> [*] E.g., I pass the parameter using a call-by-value mechanism,
> or simplified, I pass the parameter by value.
I think I covered most of this in the long followup I just posted.
In modern usage, functions are "called", and arguments are "passed".
Phrases like "call-by-value" are, I think, a relic of earlier usage,
particularly in the Algol 60 Report, in which functions/procedure
and parameters were both "called". I don't know whether the Algol
60 Report was the origin of this usage, or whether it was already
common usage at the time.
(And I probably could have replaced my entire post with the above
paragraph.)
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-27 14:03 -0700 |
| Message-ID | <87ikugsta9.fsf@nosuchdomain.example.com> |
| In reply to | #388528 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>> The "call by" in Algol 60 is used to characterize /parameters/ of
>> a function definition. It's important that "call" is used in the
>> active voice; parameters are not "called".
>
> https://dl.acm.org/doi/pdf/10.1145/367236.367262
>
> 4.7.5.4. A formal parameter which is called by value cannot in
> general correspond to [...]
>
> Apparently the author of that section did think that parameters (at
> least formal parameters) are "called", or did not clearly express what
> he actually meant.
>
> It's a minor point.
After some further thought and re-reading of the Algol 60 Report, I
no longer think this is a minor point.
I had said, and you agreed, that parameters are not "called".
I've searched the Algol 60 Report for occurences of "call". It uses
that word both to refer to calling procedures *and* to "calling"
parameters.
And my tentative conclusion is that this whole controversy ("call-by"
vs. "pass-by") is simpler than I had thought, and likely than you
had thought. The phrase "call by value" made sense when the Algol 60
Report was written, because it was understood at the time that
parameters are *called*. It no longer makes as much sense, because
that usage of the word "call" has almost entirely died out, and we say
that arguments are *passed*.
Gory details follow.
Some terminology for those who might not be familiar with Algol 60:
Algol 60 has "procedures", which may or may not return a value.
These correspond to C "functions". Other languages might use terms
like "subprogram" or "subroutine".
Procedures may have parameters. Procedure calls may include
arguments, which are associated with the parameters of the called
procedure. C uses the same terminology (but does not have by-name
semantics). Some languages refer to parameters and arguments as
formal parameters and actual parameters, respectively.
What C calls a "function call", Algol 60 calls a "procedure statement".
The following is partial list of uses of "call" in the Report.
The word "pass" does not appear anywhere in the Report.
4.7.3. Semantics
A procedure statement serves to invoke (call for) the execution of a
procedure body (cf. section 5.4. Procedure Declarations).
4.7.3.1. Value assignment (call by value)
4.7.3.2. Name replacement (call by name)
4.7.5.1. Strings cannot occur as actual parameters in procedure
statements calling procedure declarations having ALGOL 60
statements as their bodies (cf. section 4.7.8).
4.7.5.2. A formal parameter which occurs as a left part variable
in an assignment statement within the procedure body and which
is not called by value can only correspond to an actual parameter
which is a variable (special case of expression].
4.7.5.3. A formal parameter which is used within the procedure
body as an array identifier can only corre- spond to an actual
parameter which is an array identifier of an array of the same
dimensions. In addition if the formal parameter is called by
value the local array created during the call will have the
same subscript bounds as the actual array.
4.7.5.4. A formal parameter which is called by value cannot in
general [...]
5.4.5. Specifications
[...] In this part no formal parameter may occur more than
once and formal parameters called by name (cf. section 4.7.3.2)
may be omitted altogether.
From these examples, it's clear (to me) that the Report uses the word
"call" in its modern sense of calling a function -- but it *also* uses
the word "call" in reference to formal parameters.
Consider this C code:
void func(int param1, int param2) { /* ... */ }
...
func(10, 20);
In C terms, the last line *calls* the function; this includes
*passing* the arguments 10 and 20, which results in assigning those
values to the parameters param1 and param2.
In Algol 60 terms, the last line *calls* the function (procedure); this
includes *calling* the formal parameters param1 and param2. If the
parameters are called by value, the argument values are copied as in C.
If the parameters are called by name, each occurrence of a parameter
name in the body of func() is logically replaced by the argument
expression. (I'm not sure I've described the semantics entirely
correctly.)
Consider this C++ code:
void func(int by_value, int& by_reference) { /* ... */ }
...
int n;
func(42, n);
In the function call, there are two different argument passing
mechanisms, but only one *call*. The call itself is not by
value or by reference. The call includes passing two arguments,
one by value and one by reference. This is one reason I don't
think it makes sense to use "call by" rather than "pass by"
for arguments/parameters. (In Algol 60 terms, parameters were
"called", so that terminology made sense.)
The "call by name" semantics turned out to be more complicated
than expected, and as far as I can tell was never adopted by any
language other than Algol 60.
And in modern usage, the word "call" is used to refer to invoking
a function/procedure/subprogram, and is virtually *never*
applied to associating an argument to a parameter as part of a
function/procedure/subprogram call, other than in the legacy "call
by ..." phrasing. That mechanism is almost always referred to as
*passing* the argument.
In C, function arguments are always passed by value. In C++,
arguments may be passed by value or by reference. In some languages,
some arguments may be passed by copy-in/copy-out. I've never
found the word "pass" to cause any confusion in the latter case.
I might say informally that the argument is passed in on the call,
and then passed out, back to the caller, when the function returns.
My conclusion is that the only reason the term "call by <mechanism>"
is used is because of its use in the very influential Algol
60 Report, which was written at a time when the word "call" was
applied to parameters. Now that that meaning of "call" has almost
completely fallen into disuse, I suggest that "call by <mechanism>"
is of historical interest, but "pass by <mechanism>" is much clearer.
Still, it's important to recognize the "call by" phrasing, which
still appears in the index of K&R2 and the C and C++ standards.
I'd still use the phrase "call by name" rather than "pass by name"
because it's well known by that phrase. For mechanisms that are
still in use in modern languages, I see no point in using the
older terminology.
I don't know whether the idea of "calling" parameters originated in
the Algol 60 report, or whether it was just common usage at the time.
Studying the early documentation for languages like Fortran, Cobol,
and perhaps PL/I might be illuminating, but I have not (yet) done so.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-09-28 00:26 +0200 |
| Message-ID | <vd7bfd$t3v2$1@dont-email.me> |
| In reply to | #388532 |
On 27.09.2024 23:03, Keith Thompson wrote: > [...] > > In the function call, there are two different argument passing > mechanisms, but only one *call*. The call itself is not by > value or by reference. The call includes passing two arguments, > one by value and one by reference. This is one reason I don't > think it makes sense to use "call by" rather than "pass by" > for arguments/parameters. (In Algol 60 terms, parameters were > "called", so that terminology made sense.) Just note that in Simula - which has Algol 60 as [small] subset - the couple books I have also speak about "passing" parameters, or speak about associating actual parameters to the formal ones; depending on what abstraction level they formulate. > > The "call by name" semantics turned out to be more complicated > than expected, It's also inefficient (and it shows some IMO undesired effects). > and as far as I can tell was never adopted by any > language other than Algol 60. Yes; Simula inherited that mechanism; it has 'value', 'name' (and also, for objects of class T types, 'ref(T)'). Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-09-28 06:43 +0200 |
| Message-ID | <vd81if$14bbc$1@dont-email.me> |
| In reply to | #388532 |
On 27.09.2024 23:03, Keith Thompson wrote:
> [...]
>
> I don't know whether the idea of "calling" parameters originated in
> the Algol 60 report, or whether it was just common usage at the time.
> Studying the early documentation for languages like Fortran, Cobol,
> and perhaps PL/I might be illuminating, but I have not (yet) done so.
Concerning this I stumbled across an (a bit vague) comment in a
book from F.L.Bauer (CS pioneer and member of the Algol committee)
and H.Wössner (from 1984)...
"[...] Insbesondere die Nichtunterscheidung von Eingabe- und
Resultatparametern, einer der schädlichen Ausflüsse von FORTRAN,
machte als Ersatz die eigenartigen Parameterübergabemechanismen
('call by value', 'call by name', 'call by reference') erforderlich.
[...]"
"[...] In particular, the failure to distinguish between input
and result parameters, one of the harmful effects[*] of FORTRAN,
made as replacement the strange parameter passing mechanisms
('call by value', 'call by name', 'call by reference') necessary.
[...]"
Unfortunately it doesn't say what exactly it was (in FORTRAN) that
lead to the decisions for the parameter passing mechanisms and its
naming. Non-existing mechanisms [in FORTRAN] wouldn't quite explain
why they haven't done a better job in Algol 60. (Details are still
unclear to me.)
Janis
[*] Not sure about the best word for "Ausflüsse"; maybe effluences
fits better?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-29 08:07 -0700 |
| Message-ID | <868qu7uevo.fsf@linuxsc.com> |
| In reply to | #388528 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > I won't ask you to reply to this. I didn't ask you to reply to my posting.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-09-16 22:41 +0100 |
| Message-ID | <877cbbgttl.fsf@bsb.me.uk> |
| In reply to | #388406 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> >>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>>> >>>>>> On 2024-07-12, bart <bc@freeuk.com> wrote: >>>>>> >>>>>>> It's clearly not by value. It's apparently not by reference. You >>>>>>> can't get away with saying they are not passed, as clearly >>>>>>> functions *can* access array data via parameters. >>>>>> >>>>>> Actually, you probably can get away with saying that it is "passed >>>>>> by reference". >>>>>> >>>>>> The formal term that doesn't apply is "call by reference"; that's >>>>>> what C doesn't have. >>>>>> >>>>>> "call by reference" emphasizes that the function call mechanism >>>>>> provides the reference semantics for a formal parameter, not that >>>>>> some arbitrary means of passage of the data has reference >>>>>> semantics. >>>>> >>>>> [...] >>>>> >>>>> I know that "call by reference" is the usual formal term, but I >>>>> personally prefer "pass by reference". >>>>> >>>>> The terms "call by reference" and "call by value" emphasize the >>>>> call, implying that all arguments in a given call are passed with >>>>> the same mechanism. In some languages that's true (C argument >>>>> passing is purely by value, and Fortran, as I understand it, is >>>>> purely by reference), but in others (C++, Pascal, Ada) you can >>>>> select by-value or by-reference for each parameter. "Pass by >>>>> (reference|value)" feels more precise. >>>>> >>>>> I haven't checked, but I suspect the terms "call by (reference|value)" >>>>> predate languages that allowed the mechanism to be specified for each >>>>> parameter. >>>> >>>> I suspect that your guess here is influenced more by what you would >>>> like to be true than what is likely to be true. >>> >>> I was influenced by what I thought made the most sense. >>> >>>> What is likely to be true is that these terms entered the language >>>> at essentially the same time as the original Algol. Algol 60 has >>>> both call by name and call by value, referred to by those names in >>>> the Algol 60 Report, and selectable on a per-parameter basis. >>>> >>>> By contrast the precursor to Algol 60, the International Algebraic >>>> Language or IAL for short (and referred to after the fact as Algol >>>> 58) did not use either term, and described the coupling between >>>> arguments and parameters only in somewhat vague English prose that >>>> left unclear exactly what the binding mechanism(s) were to be. >>>> (There was a description for functions and a separate description >>>> for procedures, not quite the same, and both not completely clear >>>> exactly what the mechanism was meant to be.) >>>> >>>> Thus it seems likely that the terms call by name, call by value, >>>> and perhaps other similar terms, first arose during the discussions >>>> of the Algol 60 working group in the late 1950s, and entered the >>>> general lexicon with or perhaps slightly before the publication of >>>> the Algol 60 Report, which describes and allows both call by name >>>> and call by value, selectable on a per-parameter base, and referred >>>> to by those names in the published Algol 60 Report. >>> >>> Yes, that does seem likely. >>> >>> I'm mildly disappointed. Since arguments are *passed* and >>> functions/procedures are *called*, surely it would have made more sense >>> to use "pass by value" rather than "call by value", especially in a >>> language where the mechanism can vary per parameter. >> >> All that is, I think, due to subsequent changes in (English) language >> use. In Algol 60, procedures were invoked and /parameters/ were called >> by value or name. Maybe the term was intended to reflect the idea that >> the code in the body "called for the value" of the parameter. >> >> The word "call" now refers, almost universally, to invoking a function >> or procedure. As a result, the idea of "calling a parameter" reads >> oddly, but at the time I'm sure it seemed perfectly reasonable. > > This view simply doesn't match the language and phrasing used > during the time Algol was being developed. Both the Algol 60 > report and the preliminary IAL report (aka Algol 58) routinely > use the word call in connection with outside use of a procedure. > Algol 60 uses the word "invoke" exactly twice: once in relation > to procedures (where "call" is also used), and once in relation > to functions. Algol 58 uses the word call pretty much the same > way that Algol 60 does, but doesn't use the word "invoke" at all; > the verb "initiate" a procedure in Algol 58 turned into "invoke" > a procedure in Algol 60. Clearly using "call" was already well > established in the late 1950s, and "invoke" came later. > > Algol 58 (loosely) defined the semantics of procedure call by > textual expansion of the procedure body at the call site, > substituting the text of actual parameters for each occurrence of > the corresponding formal parameter in the procedure body. The > actual rules are more complicated, due to there being different > "styles" (my word) of parameters, and because there were output > parameters as well as input parameters. Basically though the > meaning was what would later be termed "call by name", with some > restrictions on what forms of actual parameters were allowed. > > Algol 60 simplified the rules by reducing the number of cases to > just two: either the actual parameter was textually substituted > for the formal parameter in the expansion (call by name), or the > value of the actual parameter expression was in effect assigned > to a local variable corresponding to the formal parameter (call > by value), which did not have a corresponding case in Algol 58. > The "call by" in "call by name" and "call by value" refers to how > the expansion is done in elaborating the procedure call. The > "call by" is not what sort of thing is passed, but what action is > taken in doing the substitution/expansion. > >>> (Yes, this is my opinion.) >>> >>> If there's some reason why "call by value" actually made more sense >>> than "pass by value", I'm not aware of it. >>> >>> Since the phrase "pass by value" is now in common use, I'll >>> continue to use that term in preference to "call by value" >>> (likewise "by reference"). >> >> I use those terms too. It would be confusing these days to talk >> about calling a parameter, and the phrase "call by value" suggests >> (as it never did at the time) something so do with the function >> calling mechanism in general. > > Yes it did. It is only now that we have a different idea about > how functions and procedures are called that it seems like it > doesn't. But in Algol 60 it certainly did have something to do > with how a function reference was elaborated (aka called). > >> This is compounded by the fact that modern programming languages >> has almost universally settled on calling all parameters by value >> (to the use the old phrase) so, usually, the terms can, in fact, >> be used to talk about the function calling mechanism. > > The rationale here seems circular to me, and also not an accurate > picture of the programming language landscape. > > Passing a pointer by value is not the same as a call be reference. > > Passing a lambda by value is not the same as a call by name. > > Shortly after Algol 60, FORTRAN adopted call by value/result, > also called call by copy in/copy out. Ada has INOUT, does > it not? > > Logic programming languages have call by unification. > > All of these cases show why "pass by" is not a good universal > fit. > > At their lowest level, computers are simply slinging bits around. > In some sense everything is done in terms of "values". Thinking > in terms of what "value" is "passed" serves to reinforce an > imperative mind set, and there is already too much of that. For > these reasons and more I disdain the hoi polloi phrasing of "pass > by" for distinguishing different parameter modalities. Your disdain is noted, so I see no point in my making any technical points. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-12 15:22 +0200 |
| Message-ID | <v6ramn$31q88$1@dont-email.me> |
| In reply to | #387081 |
On 12.07.2024 13:21, bart wrote: > On 12/07/2024 12:12, Janis Papanagnou wrote: >> On 12.07.2024 08:00, David Brown wrote: >>> [...] >>> >>> I can understand when someone new to C gets mixed up about how arrays >>> work. >> >> I can't understand that if I presume that the person has read any >> basic textbook about "C". >> >>> I don't understand how someone can remain so stubbornly confused >>> when they have been told how C /actually/ works. >> >> Especially if the one has said to have written an own language that >> is close enough to "C" where I'd expect the knowledge to be there >> already before that person is designing and implementing his project. >> >> I wonder why he refuses to look up things if he thinks that all the >> experts here are wrong about a well documented fact. > > If you had to describe to someone how a function accesses array data in > its caller, what would you say? I would explain it as it is, in a way similar to what was already written in this thread. (It had been formulated repeatedly and I will not repeat it again.) Someone here (don't recall who it was) already had provided a good post about how difficult it gets if you build your argument around an inappropriate model. > > It's clearly not by value. It's apparently not by reference. You can't > get away with saying they are not passed, as clearly functions *can* > access array data via parameters. To explain it to newbies I'd abstain from using parameter-passing terms at all; and especially in "C" that's simple because you have just one mechanism, so you don't need to mention it to distinguish it from any other mechanisms [that exist in other languages]. I'd just explain what happens if you write f(int a[]) and - since the pointers are so basic a concept in "C" - I'd likely explain it in terms of f(int * p) . > > Or would you merely refer to the relevant section in the language > reference? If you mean the standards' documents; no. I don't think that such documents are good for learning or explaining a language. But they help to get formal certainty about facts; useful for experts like the ones here in this group (and certainly not excluding you). > Just curious. Fair enough. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-12 08:58 -0700 |
| Message-ID | <87wmlqsitc.fsf@nosuchdomain.example.com> |
| In reply to | #387081 |
bart <bc@freeuk.com> writes:
[...]
> If you had to describe to someone how a function accesses array data
> in its caller, what would you say?
The same thing I've written to you many times over the last several
years in this newsgroup.
> It's clearly not by value. It's apparently not by reference. You can't
> get away with saying they are not passed, as clearly functions *can*
> access array data via parameters.
Yes, function can access array data by means other than passing arrays
as parameters.
> Or would you merely refer to the relevant section in the language reference?
That, and to section 6 of the comp.lang.c FAQ, which is an excellent
description of C's treatment of arrays and pointers. You've repeatedly
declined to say whether you've read it. I encourage you to do so.
> Just curious.
Sure you are.
--
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-07-12 19:33 +0100 |
| Message-ID | <v6rste$34t3j$3@dont-email.me> |
| In reply to | #387102 |
On 12/07/2024 16:58, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> If you had to describe to someone how a function accesses array data >> in its caller, what would you say? > > The same thing I've written to you many times over the last several > years in this newsgroup. > >> It's clearly not by value. It's apparently not by reference. You can't >> get away with saying they are not passed, as clearly functions *can* >> access array data via parameters. > > Yes, function can access array data by means other than passing arrays > as parameters. > >> Or would you merely refer to the relevant section in the language reference? > > That, and to section 6 of the comp.lang.c FAQ, which is an excellent > description of C's treatment of arrays and pointers. You've repeatedly > declined to say whether you've read it. I encourage you to do so. > >> Just curious. > > Sure you are. Actually, I /was/ genuinely curious as to how a function's access to its caller's array elements are described without using 'pointer' or 'reference'. Because as AFAIK this whole subthread seems to about people trying to catch me out on some pedantry. All it needed was for someone to agree that yes, arrays are /effectively/ passed by reference, even if it's not true by-reference and not a general purpose feature of the language. People can't seem to help throwing insults.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-12 13:38 -0700 |
| Message-ID | <87o772s5vj.fsf@nosuchdomain.example.com> |
| In reply to | #387107 |
bart <bc@freeuk.com> writes:
> On 12/07/2024 16:58, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> If you had to describe to someone how a function accesses array data
>>> in its caller, what would you say?
>> The same thing I've written to you many times over the last several
>> years in this newsgroup.
>>
>>> It's clearly not by value. It's apparently not by reference. You can't
>>> get away with saying they are not passed, as clearly functions *can*
>>> access array data via parameters.
>> Yes, function can access array data by means other than passing
>> arrays
>> as parameters.
>>
>>> Or would you merely refer to the relevant section in the language reference?
>> That, and to section 6 of the comp.lang.c FAQ, which is an excellent
>> description of C's treatment of arrays and pointers. You've repeatedly
>> declined to say whether you've read it. I encourage you to do so.
>>
>>> Just curious.
>> Sure you are.
>
> Actually, I /was/ genuinely curious as to how a function's access to
> its caller's array elements are described without using 'pointer' or
> 'reference'.
So now you're restricting the words that can be used in the explanation.
You didn't mention that restriction before. You're moving the
goalposts.
Any accurate explanation of how a function accesses elements of what
looks like an array parameter depends on pointers. I believe you
understand that perfectly well, but if you want to ask about some
specific code I might consider explaining it yet again.
"Reference" is an informal term that describes what pointers are. The
problem is that it's also a formal term that refers to features that C
doesn't have (C++-style references and function arguments passed by
reference).
> Because as AFAIK this whole subthread seems to about people trying to
> catch me out on some pedantry.
>
> All it needed was for someone to agree that yes, arrays are
> /effectively/ passed by reference, even if it's not true by-reference
> and not a general purpose feature of the language.
If I'm not mistaken, I don't believe you've ever acknowledged
the underlying mechanism of how arrays are "passed" to functions.
Will you do so now?
Given:
void func(int param[10]) {
... param[5] ...
}
...
int argument[10] = ...;
func(argument);
can *you* explain the semantics in terms consistent with the way
the C standard describes them? (This is of course an incomplete
code fragment. I can provide a complete program if you think
it's necessary.)
[...]
Your acknowledgement that you've read section 6 of the comp.lang.c
FAQ is a prerequisite to any further substantive response from me.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-17 16:42 -0700 |
| Message-ID | <86cynb60w6.fsf@linuxsc.com> |
| In reply to | #387107 |
bart <bc@freeuk.com> writes: [...] > Because as AFAIK this whole subthread seems to about people trying > to catch me out on some pedantry. > > All it needed was for someone to agree that yes, arrays are > /effectively/ passed by reference, [...] To recap, the discussion concerns function parameters declared using an array-style declarator. I'm perfectly willing to agree that you think of such parameters as being effectively call-by-reference arrays. My objection is to your insistence that other people must agree with that view. You can think of it any way you like, but that doesn't make it true, nor does it imply that other people have to hold the same point of view. So all you have to do is stop insisting that your point of view is the only reasonable one.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web