Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #150040 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2020-02-16 02:25 -0800 |
| Last post | 2020-04-09 07:38 -0700 |
| Articles | 20 on this page of 148 — 20 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 02:25 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-16 14:24 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:13 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-22 09:05 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:58 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-27 23:26 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 09:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 09:54 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 11:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 13:12 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 13:28 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:17 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 09:47 +0200
Re: C String terminator already5chosen@yahoo.com - 2020-04-03 08:03 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 17:34 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 12:39 -0400
Re: C String terminator Bart <bc@freeuk.com> - 2020-04-03 18:05 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 10:18 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:13 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 14:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 16:18 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 01:43 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:23 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 11:18 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:02 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-05 21:54 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 13:59 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-06 09:07 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 02:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 11:43 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:56 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 16:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 10:30 -0700
Re: C String terminator richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-04-06 17:50 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 11:31 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 12:04 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 21:51 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:34 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 14:39 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:52 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 15:31 -0700
Re: C String terminator jameskuyper@stellarscience.com - 2020-04-06 16:05 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 03:08 +0100
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-06 21:12 -0600
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 16:55 +0000
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 11:05 -0600
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-07 20:39 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:48 -0700
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 21:21 -0600
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 20:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 01:41 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 07:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 08:16 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 09:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 09:46 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 10:37 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 10:48 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-08 14:07 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 11:29 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 16:46 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 01:57 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 08:56 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 12:42 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 10:12 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 15:51 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 13:02 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 13:06 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 14:49 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 19:05 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 02:25 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 04:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 05:21 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 07:13 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 11:38 -0700
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-11 17:38 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:04 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-11 15:16 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-11 21:45 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 04:39 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-12 21:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 14:38 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-13 11:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-13 08:24 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:08 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 09:53 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:35 -0400
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-06 21:04 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 01:16 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 02:08 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 02:19 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 10:39 -0700
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 17:45 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:40 -0400
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 11:03 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 12:19 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:02 +0100
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 06:27 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 07:44 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 08:30 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 00:27 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:50 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 05:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 23:52 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 03:15 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 21:28 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 15:40 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-09 00:31 +0100
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-07 21:40 +0000
Re: C String terminator luser droog <luser.droog@gmail.com> - 2020-04-06 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 12:46 -0700
Re: C String terminator Guillaume <message@bottle.org> - 2020-04-07 17:17 +0200
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:23 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-04 22:32 +0100
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 21:59 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:48 -0400
Jared Kushner would be proud... (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-04 09:00 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 02:45 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-04 10:24 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 03:55 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:27 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 13:52 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:03 -0700
Re: Jared Kushner would be proud... Richard Damon <Richard@Damon-Family.org> - 2020-04-04 18:46 -0400
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 01:53 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 02:33 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 06:43 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 19:48 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 06:37 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:36 +0200
Re: C String terminator dave_thompson_2@comcast.net - 2020-05-02 15:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 10:33 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 11:34 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:48 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 12:10 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 13:24 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:59 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:05 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 20:34 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 02:05 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:35 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 07:38 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-03 16:18 -0700 |
| Message-ID | <877dywqhtv.fsf@nosuchdomain.example.com> |
| In reply to | #151000 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> > ... I was accused of inventing "Malcolm functions" (a "Malcolm
>> > function" is a mapping of input bits to output bits,
>>
>> Is it? I thought a key feature of Malcolm-functions is that they don't
>> do input or output. Or do you mean Malcolm-input and Malcolm-output?
>>
> Really the key feature is that they are not specified to do IO in
> the interface description. So you can always eliminate the IO whilst
> maintaining correct behaviour for a compliant caller. That's not just a
> quibble, often you want to add white box diagnostics to a Malcolm function
> to debug it.
> So yes, Malcolm-input and Malcolm-output. The key reason for defining
> the Malcolm function is not to teach people what the word "function"
> normally means outside of C, but to separate the portions of the program
> which are inherently portable and (except for running out of memory)
> failure free, from those which are inherently hardware bound and can
> fail if the device they are attached to fails.
*sigh*
I believe the point Ben was making is that you used the terms
"input" and "output" (which are used in the C standard to refer
to operations like those done by functions declared in <stdio.h>)
to refer to the values given to and returned by a function call.
There are already perfectly good terms for those: argument values
and return values. I presume Ben knew what you *meant* by "input"
and "output", but was unwilling to accept your use of those terms.
What we seem to be calling a "Malcolm-function" is, I believe,
what is often called a "pure function" -- basically a function
without side effects, which includes not performing any I/O.
The C standard doesn't define the term "pure function", and it
has a commonly accepted meaning. gcc even lets you use a compiler
extension to assert that a function is "pure".
Calling a pure function a "Malcolm-function" is only slightly
better than calling it a "function" and assuming everyone knows
what you mean.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 01:43 -0700 |
| Message-ID | <13e81aac-375b-45ba-9261-8153c406368c@googlegroups.com> |
| In reply to | #151001 |
On Saturday, 4 April 2020 00:18:30 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> > >> > ... I was accused of inventing "Malcolm functions" (a "Malcolm > >> > function" is a mapping of input bits to output bits, > >> > >> Is it? I thought a key feature of Malcolm-functions is that they don't > >> do input or output. Or do you mean Malcolm-input and Malcolm-output? > >> > > Really the key feature is that they are not specified to do IO in > > the interface description. So you can always eliminate the IO whilst > > maintaining correct behaviour for a compliant caller. That's not just a > > quibble, often you want to add white box diagnostics to a Malcolm function > > to debug it. > > So yes, Malcolm-input and Malcolm-output. The key reason for defining > > the Malcolm function is not to teach people what the word "function" > > normally means outside of C, but to separate the portions of the program > > which are inherently portable and (except for running out of memory) > > failure free, from those which are inherently hardware bound and can > > fail if the device they are attached to fails. > > *sigh* > > I believe the point Ben was making is that you used the terms > "input" and "output" (which are used in the C standard to refer > to operations like those done by functions declared in <stdio.h>) > to refer to the values given to and returned by a function call. > There are already perfectly good terms for those: argument values > and return values. I presume Ben knew what you *meant* by "input" > and "output", but was unwilling to accept your use of those terms. > No. I don't think this was the case at all. But don't you see the problem here? Now we can't use the word "input" except as defined by the C standard. Too many words are hijacked and given privileged meanings. The terms "function" and "procedure" are the best terms used to describe "Malcolm functions" and "Malcolm procedures". I could of course try to invent my own terms, and actually there is a case for "bit shuffling functions", but that actually implies a level of invention that I can't own. However in many languages, a function returns a value, whilst a procedure doesn't. That's important for the grammar of the language, because you can write if (function() == x) but not if (procedure() == x) However, in C, that difference isn't capturing anything very important. That's because C subroutines can take pointers. so we might have double getx(); or void getx(double *retval); it doesn't really matter which we use from a software engineering persepctive. > > What we seem to be calling a "Malcolm-function" is, I believe, > what is often called a "pure function" -- basically a function > without side effects, which includes not performing any I/O. > The C standard doesn't define the term "pure function", and it > has a commonly accepted meaning. gcc even lets you use a compiler > extension to assert that a function is "pure". > > Calling a pure function a "Malcolm-function" is only slightly > better than calling it a "function" and assuming everyone knows > what you mean. > rand() isn't a "pure function", but it is a "Malcolm function". It keeps state, but it doesn't do IO. Therefore it can be written portably, with no dependencies, and it can't fail unless there is an internal bug or it runs out of memory - the last can only happen if the program reaches the end of its stack because in fact it won't allocate any memory.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-04 18:23 +0200 |
| Message-ID | <r6ac9d$5vi$1@dont-email.me> |
| In reply to | #151005 |
On 04/04/2020 10:43, Malcolm McLean wrote: > On Saturday, 4 April 2020 00:18:30 UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> ... I was accused of inventing "Malcolm functions" (a "Malcolm >>>>> function" is a mapping of input bits to output bits, >>>> >>>> Is it? I thought a key feature of Malcolm-functions is that they don't >>>> do input or output. Or do you mean Malcolm-input and Malcolm-output? >>>> >>> Really the key feature is that they are not specified to do IO in >>> the interface description. So you can always eliminate the IO whilst >>> maintaining correct behaviour for a compliant caller. That's not just a >>> quibble, often you want to add white box diagnostics to a Malcolm function >>> to debug it. >>> So yes, Malcolm-input and Malcolm-output. The key reason for defining >>> the Malcolm function is not to teach people what the word "function" >>> normally means outside of C, but to separate the portions of the program >>> which are inherently portable and (except for running out of memory) >>> failure free, from those which are inherently hardware bound and can >>> fail if the device they are attached to fails. >> >> *sigh* >> >> I believe the point Ben was making is that you used the terms >> "input" and "output" (which are used in the C standard to refer >> to operations like those done by functions declared in <stdio.h>) >> to refer to the values given to and returned by a function call. >> There are already perfectly good terms for those: argument values >> and return values. I presume Ben knew what you *meant* by "input" >> and "output", but was unwilling to accept your use of those terms. >> > No. I don't think this was the case at all. I interpreted Ben's post in the same way Keith did. But only Ben can say if that was how he intended it. > But don't you see the problem > here? Now we can't use the word "input" except as defined by the C > standard. Too many words are hijacked and given privileged meanings. The English language is limited. Nothing new here - and nothing C specific. Words are /always/ context sensitive. This is a C newsgroup - if there is not context in a post or thread that overrides the meaning of a word, then any word defined in the C standards will be assumed to have that meaning. On its own, "function" therefore means "C function" in this group. The problem here is that you want to have your own private meanings for a lot of words that are different from the C standards, and not at all obvious from the posts or threads. You combine that with a determination to avoid alternatives that /are/ clearly defined in the context of C (such as "return values" and "function arguments" in this case). It is not the C standards that are the problem - it is your sloppy writing. > > The terms "function" and "procedure" are the best terms used to describe > "Malcolm functions" and "Malcolm procedures". I could of course try to > invent my own terms, and actually there is a case for "bit shuffling > functions", but that actually implies a level of invention that I > can't own. Please - don't invent new terms, and don't abuse existing terms. Use the appropriate terms for a C discussion, or elaborate on them to make them clear. "Pure function" seems a reasonable choice for "a function with no observable side-effects and whose return value depends solely on its arguments". Even that, however, is not entirely precise as there are various additional considerations. Can such a function depend on unchanging data from the environment (such as data declared "const")? A gcc "const" function may do so. Can such a function depend on reading changeable data (i.e., it depends on the observable state of the program, but can't change it)? A gcc "pure" function may do so. Can such a function depend on implementation-dependent behaviour? That has important ramifications for portability. As you can see, dividing functions into different categories is not as simple as you would like to think. > However in many languages, a function returns a value, whilst a procedure > doesn't. That's important for the grammar of the language, because you can > write > > if (function() == x) > > but not > > if (procedure() == x) > This is different from the distinction you usually make between Malcolm-functions and Malcolm-procedures. In Pascal, for example, a "function" is directly equivalent to a C function with non-void return type, while a "procedure" is directly equivalent to a C function with void return type. Both Pascal functions and Pascal procedures can have side-effects. A function could, for example, send data from its arguments out to the screen and return the number of characters written. > However, in C, that difference isn't capturing anything very important. > That's because C subroutines can take pointers. /Why/ would you feel the need to introduce another invented term here? Let's pretend you wrote "That's because C functions can take pointers" instead. You are wrong, of course. The distinction between : T foo1(args...) and void foo2(T* returnval, args...) is a matter of user convenience and ABI optimisation rather than anything fundamental. (Indeed, for types that are too large to fit in the ABI's choice of return register, the compiler will turn "foo1" into the form of "foo2" automatically.) This applies to all imperative programming languages that support pointers or some alternative form of output parameters. It is not only for C. > so we might have > > double getx(); > > or > > void getx(double *retval); > > it doesn't really matter which we use from a software engineering > persepctive. >> >> What we seem to be calling a "Malcolm-function" is, I believe, >> what is often called a "pure function" -- basically a function >> without side effects, which includes not performing any I/O. >> The C standard doesn't define the term "pure function", and it >> has a commonly accepted meaning. gcc even lets you use a compiler >> extension to assert that a function is "pure". >> >> Calling a pure function a "Malcolm-function" is only slightly >> better than calling it a "function" and assuming everyone knows >> what you mean. >> > rand() isn't a "pure function", but it is a "Malcolm function". It > keeps state, but it doesn't do IO. That is another nonsensical distinction that is private to your own imagination. To make this clear, let's work with a function "random()" that will return a random number, without being as tied-down as the standard library function rand(). A call to "random()" might involve reading a file "/dev/random", in which case it is certainly doing IO. Or it might be a pseudo-random algorithm and keep an internal state. Or it might use a processor-specific assembly instruction giving a "true" random number result. Or it might self-seed based on the time on the machine. Some of these implementations you might classify as "Malcolm-functions", others not - but the distinction is totally useless to both the programmer and the compiler. > Therefore it can be written > portably, Not necessarily true - the implementation may depend on things like the size of "int" or "long". > with no dependencies, Not necessarily, depending on the requirements of the function. > and it can't fail unless there is > an internal bug or it runs out of memory - the last can only happen > if the program reaches the end of its stack because in fact it > won't allocate any memory. > No function can fail if it is specified properly, implemented correctly, used within the specifications, and run on a system that supports the semantics for the language. (This last one is somewhat hypothetical - the C abstract machine requires the equivalent of an unlimited stack.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 11:18 -0700 |
| Message-ID | <09e137e8-7bf0-4b5b-b098-52f31bfdfe64@googlegroups.com> |
| In reply to | #151012 |
On Saturday, 4 April 2020 17:23:18 UTC+1, David Brown wrote:
> On 04/04/2020 10:43, Malcolm McLean wrote:
>
> The English language is limited. Nothing new here - and nothing C
> specific. Words are /always/ context sensitive. This is a C newsgroup
> - if there is not context in a post or thread that overrides the meaning
> of a word, then any word defined in the C standards will be assumed to
> have that meaning. On its own, "function" therefore means "C function"
> in this group.
>
> The problem here is that you want to have your own private meanings for
> a lot of words that are different from the C standards, and not at all
> obvious from the posts or threads. You combine that with a
> determination to avoid alternatives that /are/ clearly defined in the
> context of C (such as "return values" and "function arguments" in this
> case). It is not the C standards that are the problem - it is your
> sloppy writing.
>
No, because C doesn't insist that all the variable data that a function
reads be passed in through its arguments, and that all the results that
it calculates be passed out through its return value. Arguably it would
be a better language if it did insist on this, but it doesn't.
My writing isn't sloppy. I'm generally understood. People sometimes
pretend not to understand, for reasons which aren't entirely clear
to me but doubtless deep in human psychology.
> >
> > The terms "function" and "procedure" are the best terms used to describe
> > "Malcolm functions" and "Malcolm procedures". I could of course try to
> > invent my own terms, and actually there is a case for "bit shuffling
> > functions", but that actually implies a level of invention that I
> > can't own.
>
> Please - don't invent new terms, and don't abuse existing terms. Use
> the appropriate terms for a C discussion, or elaborate on them to make
> them clear.
>
> "Pure function" seems a reasonable choice for "a function with no
> observable side-effects and whose return value depends solely on its
> arguments". Even that, however, is not entirely precise as there are
> various additional considerations.
>
rand() is not a pure function, because pure functions cannot store
state. We could re-use the term "pure function" to mean a "Malcolm
function", but that really would cause confusion. Better to use
the term "function" and make it clear from context that it means
a [piece of code which calculates] a relationship between two sets [of
bits] in which each part of the first set is connected with just one
member of the second set in number pairs [Cambridge dictionary]
That's an accepted definition of the term "function" in normal
English usage. The C standard misuses the term "function", which is
unfortunate, but we should be able to live with that.
>
> Can such a function depend on unchanging data from the environment (such
> as data declared "const")? A gcc "const" function may do so.
>
Yes.
>
> Can such a function depend on reading changeable data (i.e., it depends
> on the observable state of the program, but can't change it)? A gcc
> "pure" function may do so.
>
> Can such a function depend on implementation-dependent behaviour? That
> has important ramifications for portability.
>
> As you can see, dividing functions into different categories is not as
> simple as you would like to think.
>
It is crashingly simple. Either it does IO or not. If you do IO, you
are doing something, you are not (just) calculating something. So
you are a "procedure".
a set of actions that is the official or accepted way of doing something
[Cambridge dictionary]
Now if you perform outut, you are clealry "doing something". It's maybe
less obvious that input is "doing something", but as an embedded person
you should have little difficulty in accept that it is also "doing
something".
You will see that I am simply using the existing terms "function"
and "procedure" in their accepted senses. Not the only senses in which
they are used. But not idiosyncratic or eccentric senses.
>
> > However in many languages, a function returns a value, whilst a procedure
> > doesn't. That's important for the grammar of the language, because you can
> > write
> >
> > if (function() == x)
> >
> > but not
> >
> > if (procedure() == x)
> >
>
> This is different from the distinction you usually make between
> Malcolm-functions and Malcolm-procedures.
>
Exactly. This is another sense in which the terms are used. It's
legitimate, but in C, it doesn't capture anything very important,
except if you are writing a grammar for the language.
> > However, in C, that difference isn't capturing anything very important.
> > That's because C subroutines can take pointers.
>
> /Why/ would you feel the need to introduce another invented term here?
> Let's pretend you wrote "That's because C functions can take pointers"
> instead.
>
I did not invent the term "subroutine".
>
> You are wrong, of course.
>
> The distinction between :
>
> T foo1(args...)
>
> and
>
> void foo2(T* returnval, args...)
>
> is a matter of user convenience and ABI optimisation rather than
> anything fundamental. (Indeed, for types that are too large to fit in
> the ABI's choice of return register, the compiler will turn "foo1" into
> the form of "foo2" automatically.)
>
That's exactly what I said and I am right. To be fair, you seldommisread like that.
>
> > rand() isn't a "pure function", but it is a "Malcolm function". It
> > keeps state, but it doesn't do IO.
>
> That is another nonsensical distinction that is private to your own
> imagination.
>
A subroutine either does IO or it doesn't. It's not a nonsensical
distinction. You might think it's not an important distinction.
>
> To make this clear, let's work with a function "random()" that will
> return a random number, without being as tied-down as the standard
> library function rand().
>
> A call to "random()" might involve reading a file "/dev/random", in
> which case it is certainly doing IO. Or it might be a pseudo-random
> algorithm and keep an internal state. Or it might use a
> processor-specific assembly instruction giving a "true" random number
> result. Or it might self-seed based on the time on the machine.
>
> Some of these implementations you might classify as "Malcolm-functions",
> others not - but the distinction is totally useless to both the
> programmer and the compiler.
>
Ok let's make this clear.
static unsigned long int next = 1;
int malcolm_random(void) // RAND_MAX assumed to be 32767
{
next = next * 1103515245 + 12345;
return (unsigned int)(next/65536) % 32768;
}
int david_random(void)
{
FILE *fp = fopen("/dev/random", "r");
int answer;
if(!fp)
/* what do we do now ?*/
answer = fgetc(fp);
if(answer == EOF)
/* what do we do now ? */
fclose(fp);
return answer;
}
david_random() can fail, if the device can't be opened, or if there is
some problem reading the random digit. Also, it won't compile at all
if the platform doesn't suply fopen() and fgetc(), and essentially
it's impossible to supply these subroutines yourself, they are not eliminable.
So it's not failure free, it's not portable, and its subroutines are
not eliminaable, it's not dependency free. it's not a "Malcolm
function".
>
> > Therefore it can be written
> > portably,
>
> Not necessarily true - the implementation may depend on things like the
> size of "int" or "long".
>
Can be written portably. There are some subtle problems here. For example
the function strchr is basically a "Malcom function". Except that the
character argument is taken in as an int then narrowed to a char before
the comparison is applied.
so
char *ptr = strchr("Fred", 'd' | 0x100);
will return a pointer to the "d" if CHAR_BIT is 8, a null if CHAR_BIT
is 9. But it's a little problem, unlikely to be of practical significance,
caused by the fact that the interface specification is written in terms
of a C type.
>
> No function can fail if it is specified properly, implemented correctly,
> used within the specifications, and run on a system that supports the
> semantics for the language. (This last one is somewhat hypothetical -
> the C abstract machine requires the equivalent of an unlimited stack.)
>
There is a kind of nitpick here.
The function
/* duplicate a string */
char *strdup(const char *str);
can fail if the machine runs out of memory.
the function
/* duplicate a string or return NULL on out of memory condition */
char *strdup(const char *str);
can't fail. Generally however we say the first. Malcolm functions
only ever fail if they contain internal bugs, or if they encounter
out of memory conditions. Malcolm procedures can fail for multiple
reasons, such as data not being ready or output devices being
disconnnected.
You can implement functions that basically require dynamic memory
by clever use of recursion and the stack, but again that's a
theoretical nitpick.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-04 13:02 -0700 |
| Message-ID | <87v9mfow7j.fsf@nosuchdomain.example.com> |
| In reply to | #151015 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> rand() is not a pure function, because pure functions cannot store
> state. We could re-use the term "pure function" to mean a "Malcolm
> function", but that really would cause confusion. Better to use
> the term "function" and make it clear from context that it means
No, it is not better to use the word "function", which has an
unambiguous meaning in C, with a meaning different from the way the
C standard defines it, when posting in a newsgroup that discusses
the language defined by that standard. And you typically *don't*
make it clear from context. You just use words with your own
meanings and don't even mention any possible ambiguity.
You're not going to change your mind. My tentative plan from now on
is not to argue with you, but merely to point out when you misuse
technical terms -- and not respond to anything else you say in a
post where you do so.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-05 21:54 +0200 |
| Message-ID | <r6dd1a$a1n$1@dont-email.me> |
| In reply to | #151015 |
On 04/04/2020 20:18, Malcolm McLean wrote:
> On Saturday, 4 April 2020 17:23:18 UTC+1, David Brown wrote:
>> On 04/04/2020 10:43, Malcolm McLean wrote:
>>
>> The English language is limited. Nothing new here - and nothing C
>> specific. Words are /always/ context sensitive. This is a C newsgroup
>> - if there is not context in a post or thread that overrides the meaning
>> of a word, then any word defined in the C standards will be assumed to
>> have that meaning. On its own, "function" therefore means "C function"
>> in this group.
>>
>> The problem here is that you want to have your own private meanings for
>> a lot of words that are different from the C standards, and not at all
>> obvious from the posts or threads. You combine that with a
>> determination to avoid alternatives that /are/ clearly defined in the
>> context of C (such as "return values" and "function arguments" in this
>> case). It is not the C standards that are the problem - it is your
>> sloppy writing.
>>
> No, because C doesn't insist that all the variable data that a function
> reads be passed in through its arguments, and that all the results that
> it calculates be passed out through its return value. Arguably it would
> be a better language if it did insist on this, but it doesn't.
Any language that supports some kind of "global variables" or
environment lets you pass data into functions, and get results out of
functions, other than via the arguments and return values. Basically,
any language other than a very pure functional programming language can
read and write some data outside of function arguments and return values.
> My writing isn't sloppy. I'm generally understood. People sometimes
> pretend not to understand, for reasons which aren't entirely clear
> to me but doubtless deep in human psychology.
You are mostly understood, I think - that is despite the sloppiness of
your wording. People find it annoying that you regularly use terms
incorrectly, even if they can guess what you mean.
>>>
>>> The terms "function" and "procedure" are the best terms used to describe
>>> "Malcolm functions" and "Malcolm procedures". I could of course try to
>>> invent my own terms, and actually there is a case for "bit shuffling
>>> functions", but that actually implies a level of invention that I
>>> can't own.
>>
>> Please - don't invent new terms, and don't abuse existing terms. Use
>> the appropriate terms for a C discussion, or elaborate on them to make
>> them clear.
>>
>> "Pure function" seems a reasonable choice for "a function with no
>> observable side-effects and whose return value depends solely on its
>> arguments". Even that, however, is not entirely precise as there are
>> various additional considerations.
>>
> rand() is not a pure function, because pure functions cannot store
> state. We could re-use the term "pure function" to mean a "Malcolm
> function", but that really would cause confusion. Better to use
> the term "function" and make it clear from context that it means
>
Correct - "rand()" as defined by the C standards cannot be a pure
function, as it holds state. But "pure function" remains a reasonable,
though not perfect, term for a function whose result is solely dependent
on its input arguments.
Only you can really say what you mean by "Malcolm-function", and I'm not
convinced your definition has been consistent every time it comes up.
But by your current definition, pure functions are a subset of Malcolm
functions.
> a [piece of code which calculates] a relationship between two sets [of
> bits] in which each part of the first set is connected with just one
> member of the second set in number pairs [Cambridge dictionary]
>
Why would you think an English language dictionary definition would be
relevant here? (That's a rhetorical question - we all know that it is
not relevant.)
> That's an accepted definition of the term "function" in normal
> English usage. The C standard misuses the term "function", which is
> unfortunate, but we should be able to live with that.
The C standard provides a definition of what is meant by the term
"function" in the context of C. That is not abuse - and it is common
practice. Standards documents regularly define what they mean by
various terms within the context they cover. That way, when people are
talking about C or reading the standards, they know exactly what the
word "function" means - and they know it does not refer to a wedding, or
someone's job.
>>
>> Can such a function depend on unchanging data from the environment (such
>> as data declared "const")? A gcc "const" function may do so.
>>
> Yes.
>>
>> Can such a function depend on reading changeable data (i.e., it depends
>> on the observable state of the program, but can't change it)? A gcc
>> "pure" function may do so.
>>
>> Can such a function depend on implementation-dependent behaviour? That
>> has important ramifications for portability.
>>
>> As you can see, dividing functions into different categories is not as
>> simple as you would like to think.
>>
> It is crashingly simple. Either it does IO or not. If you do IO, you
> are doing something, you are not (just) calculating something. So
> you are a "procedure".
>
You can't make such a distinction, because there is no clear separation
of whether code performs IO or does not. A piece of code may sometimes
perform an external IO operation and sometimes not, depending its
arguments - does it then change between being a Malcolm-function and a
Malcolm-procedure? A piece of code may change a variable in memory that
is not displayed in normal use, but is logged in debug mode - does the
mode of compilation or execution change the nature of the code? What if
the function can be compiled with or without logging enabled? You are
making an artificial distinction where none exists, and claiming it to
be a distinguishing factor in dividing types of code where there is no
benefit.
> a set of actions that is the official or accepted way of doing something
> [Cambridge dictionary]
>
> Now if you perform outut, you are clealry "doing something". It's maybe
> less obvious that input is "doing something", but as an embedded person
> you should have little difficulty in accept that it is also "doing
> something".
>
> You will see that I am simply using the existing terms "function"
> and "procedure" in their accepted senses. Not the only senses in which
> they are used. But not idiosyncratic or eccentric senses.
>
No, these are not "their accepted senses". In the context of C,
"function" has a very specific accepted sense, as defined by the C
standard. In other contexts, it has different accepted senses.
>>
>>> However in many languages, a function returns a value, whilst a procedure
>>> doesn't. That's important for the grammar of the language, because you can
>>> write
>>>
>>> if (function() == x)
>>>
>>> but not
>>>
>>> if (procedure() == x)
>>>
>>
>> This is different from the distinction you usually make between
>> Malcolm-functions and Malcolm-procedures.
>>
> Exactly. This is another sense in which the terms are used. It's
> legitimate, but in C, it doesn't capture anything very important,
> except if you are writing a grammar for the language.
>
>
>>> However, in C, that difference isn't capturing anything very important.
>>> That's because C subroutines can take pointers.
>>
>> /Why/ would you feel the need to introduce another invented term here?
>> Let's pretend you wrote "That's because C functions can take pointers"
>> instead.
>>
> I did not invent the term "subroutine".
In the context of C, you did - C does not have "subroutines". It has
"functions", with the term defined by the standard. These correlate
roughly with the common computing science term "subtroutine". But we
can only make guesses as to what /you/ might mean by the term here.
>>
>> You are wrong, of course.
>>
>> The distinction between :
>>
>> T foo1(args...)
>>
>> and
>>
>> void foo2(T* returnval, args...)
>>
>> is a matter of user convenience and ABI optimisation rather than
>> anything fundamental. (Indeed, for types that are too large to fit in
>> the ABI's choice of return register, the compiler will turn "foo1" into
>> the form of "foo2" automatically.)
>>
> That's exactly what I said and I am right. To be fair, you seldommisread like that.
>
No, you are wrong. There is no major distinction in C between functions
that have void return type, and functions with non-void return type.
But it is /not/ because "C functions can take pointers". In languages
which /do/ make a distinction between functions which return values and
functions that do not, you also (generally) can have pointers as
parameters, or other mechanisms for "output parameters".
>>
>>> rand() isn't a "pure function", but it is a "Malcolm function". It
>>> keeps state, but it doesn't do IO.
>>
>> That is another nonsensical distinction that is private to your own
>> imagination.
>>
> A subroutine either does IO or it doesn't. It's not a nonsensical
> distinction. You might think it's not an important distinction.
See above. It is nonsensical. It is perhaps fair to say that you
/usually/ can decide whether or not a function performs IO. But it is
most certainly not always the case. (And very notably, you cannot tell
from a function's declaration.)
>>
>> To make this clear, let's work with a function "random()" that will
>> return a random number, without being as tied-down as the standard
>> library function rand().
>>
>> A call to "random()" might involve reading a file "/dev/random", in
>> which case it is certainly doing IO. Or it might be a pseudo-random
>> algorithm and keep an internal state. Or it might use a
>> processor-specific assembly instruction giving a "true" random number
>> result. Or it might self-seed based on the time on the machine.
>>
>> Some of these implementations you might classify as "Malcolm-functions",
>> others not - but the distinction is totally useless to both the
>> programmer and the compiler.
>>
> Ok let's make this clear.
>
> static unsigned long int next = 1;
>
> int malcolm_random(void) // RAND_MAX assumed to be 32767
> {
> next = next * 1103515245 + 12345;
> return (unsigned int)(next/65536) % 32768;
> }
>
>
> int david_random(void)
> {
> FILE *fp = fopen("/dev/random", "r");
> int answer;
>
> if(!fp)
> /* what do we do now ?*/
> answer = fgetc(fp);
> if(answer == EOF)
> /* what do we do now ? */
> fclose(fp);
>
> return answer;
> }
>
> david_random() can fail, if the device can't be opened, or if there is
> some problem reading the random digit.
The function "david_random()" is not well-specified, and it is not
complete. If the function is specified as only being defined when the
device is readable with the expected format on a platform that provides
the required library functions, then it is failure-free and portable
(once the unnecessary checks are removed).
> Also, it won't compile at all
> if the platform doesn't suply fopen() and fgetc(), and essentially
> it's impossible to supply these subroutines yourself, they are not eliminable.
>
> So it's not failure free, it's not portable, and its subroutines are
> not eliminaable, it's not dependency free. it's not a "Malcolm
> function".
But presumably your idea of "Malcolm-function" includes "malcolm_random"
defined here? It's a clear enough distinction in this case, but that
misses the point completely.
This is like you trying to tell us the world can be cleanly divided into
red things, yellow things and green things, and justifying it by showing
a traffic light. What about oranges? Or a bowl of water? Or a
programmable RGB lamp?
>>
>>> Therefore it can be written
>>> portably,
>>
>> Not necessarily true - the implementation may depend on things like the
>> size of "int" or "long".
>>
> Can be written portably. There are some subtle problems here. For example
> the function strchr is basically a "Malcom function". Except that the
> character argument is taken in as an int then narrowed to a char before
> the comparison is applied.
>
> so
>
> char *ptr = strchr("Fred", 'd' | 0x100);
>
> will return a pointer to the "d" if CHAR_BIT is 8, a null if CHAR_BIT
> is 9. But it's a little problem, unlikely to be of practical significance,
> caused by the fact that the interface specification is written in terms
> of a C type.
>>
>> No function can fail if it is specified properly, implemented correctly,
>> used within the specifications, and run on a system that supports the
>> semantics for the language. (This last one is somewhat hypothetical -
>> the C abstract machine requires the equivalent of an unlimited stack.)
>>
> There is a kind of nitpick here.
>
> The function
>
> /* duplicate a string */
> char *strdup(const char *str);
>
> can fail if the machine runs out of memory.
If that is the case, then either it is poorly specified, being used
outside its specifications, or being used on a machine that does not
guarantee everything needed by the language.
>
> the function
>
> /* duplicate a string or return NULL on out of memory condition */
> char *strdup(const char *str);
>
> can't fail.
That looks fine.
> Generally however we say the first. Malcolm functions
> only ever fail if they contain internal bugs, or if they encounter
> out of memory conditions. Malcolm procedures can fail for multiple
> reasons, such as data not being ready or output devices being
> disconnnected.
So you would say that the above strdup() function is a "Malcolm
procedure" because it can fail (by giving a clear result with no risk to
the running of the program), while you would call this a "Malcolm
function" because it will crash the program with a stack fault on most
inputs:
inf ack(int m, int n) {
if (m == 0) return n + 1;
if (n == 0) return ack(m, 1);
return ack(m - 1, ack(m, n - 1));
}
And you think this artificial and poorly defined distinction is useful
to anyone?
>
> You can implement functions that basically require dynamic memory
> by clever use of recursion and the stack, but again that's a
> theoretical nitpick.
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-05 13:59 -0700 |
| Message-ID | <bb8f76d2-f69e-480e-9625-f31bcf8f1f3c@googlegroups.com> |
| In reply to | #151095 |
On Sunday, 5 April 2020 20:54:35 UTC+1, David Brown wrote:
> On 04/04/2020 20:18, Malcolm McLean wrote:
>
> Correct - "rand()" as defined by the C standards cannot be a pure
> function, as it holds state. But "pure function" remains a reasonable,
> though not perfect, term for a function whose result is solely dependent
> on its input arguments.
>
> Only you can really say what you mean by "Malcolm-function", and I'm not
> convinced your definition has been consistent every time it comes up.
> But by your current definition, pure functions are a subset of Malcolm
> functions.
>
I didn't invent the term "Malcolm function". I used the term "function"
in one of its accepted meanings. A mapping of sets, of bits since we
are talkng about digital computers. If you don't allow globals and you
don't allow writes through pointers, so every function call is of the
form
returnbits = functioncall(argumentbits)
then this becomes obvious. But C isn't that language.
> > a [piece of code which calculates] a relationship between two sets [of
> > bits] in which each part of the first set is connected with just one
> > member of the second set in number pairs [Cambridge dictionary]
> >
>
> Why would you think an English language dictionary definition would be
> relevant here? (That's a rhetorical question - we all know that it is
> not relevant.)
>
The concept of a function as a mapping of a first set to a second
set is important.
>
> > It is crashingly simple. Either it does IO or not. If you do IO, you
> > are doing something, you are not (just) calculating something. So
> > you are a "procedure".
> >
>
> You can't make such a distinction, because there is no clear separation
> of whether code performs IO or does not. A piece of code may sometimes
> perform an external IO operation and sometimes not, depending its
> arguments - does it then change between being a Malcolm-function and a
> Malcolm-procedure? A piece of code may change a variable in memory that
> is not displayed in normal use, but is logged in debug mode - does the
> mode of compilation or execution change the nature of the code? What if
> the function can be compiled with or without logging enabled? You are
> making an artificial distinction where none exists, and claiming it to
> be a distinguishing factor in dividing types of code where there is no
> benefit.
>
OK, so genrally there is no problem. The "function" printf() is
desinged to send characters to a device attached to standard output.
The function sqrt() makes a one to one mapping between its argument
and return value (and errno, which is why we can't use the term "pure
fucntion"). Go through the standard library, and everyone will
probably agree which are the IO procedures and which are the non
IO functions.
But what if code is instrumented for debug. What if stdout is reattached
to a memory buffer? What if a fucntion is passed a buffer which happens
to be memory mapped to a disply device? We can make things more complicated.
But let's not distract ouselves from the central idea. If you do IO,
you are dependent on the machinery being attached to the computer.
If you do bit shuffling, you are not.
>
> See above. It is nonsensical. It is perhaps fair to say that you
> /usually/ can decide whether or not a function performs IO. But it is
> most certainly not always the case. (And very notably, you cannot tell
> from a function's declaration.)
>
So run with that. You can usually, and unproblematically determine
whether a function performs IO or not. So how can we use this
information? Now what are the marginal cases, do they matter, and
can we handle them without destroying what we are trying to capture
by making the distinction?
>
> The function "david_random()" is not well-specified, and it is not
> complete. If the function is specified as only being defined when the
> device is readable with the expected format on a platform that provides
> the required library functions, then it is failure-free and portable
> (once the unnecessary checks are removed).
>
So david_random is attached to an external device which supplies
an infinite numer of random numbers. And the device can never fail.
How is that achieved? Now what you could say is "surely the computer's
memory or processor coudl break as well" and that is true. Generally,
however, IO systems report when devices fail. In this case it appears
that we open a file called "dev/random" to access the device. Try that
on a comuter where dev/random doesn't exist, and fopen() will return
NULL. So david_random() will compile, but it won't work.
On the other hnad, malcolm_random() will work on any machine with
a conforming C compiler. It is of course far inferior to
david_random() as a random number generator, I'm not saying that IO
is bad or we should never use david_random() at all. But we need to
separate it out. Instead of calling david_random() directly, we should
maybe consider making our routines that need random numbers pass
in a random number from david_random(), called at a high level.
Then if we lose dev/random, it becomes easier to replace it with
another source of random numbers.
>
> This is like you trying to tell us the world can be cleanly divided into
> red things, yellow things and green things, and justifying it by showing
> a traffic light. What about oranges? Or a bowl of water? Or a
> programmable RGB lamp?
>
It's like saying that images can be divided into black and white images
and coloured images. Of course coloured images can contain black and
white, even be wholly black and white (so you've a marginal case there),
and you've got other marginal cases where your black or white is off
true, or the null image of zero width and height. But generally the
distinction holds and is unproblematic and useful.
>
> > The function
> >
> > /* duplicate a string */
> > char *strdup(const char *str);
> >
> > can fail if the machine runs out of memory.
>
> If that is the case, then either it is poorly specified, being used
> outside its specifications, or being used on a machine that does not
> guarantee everything needed by the language.
>
> >
> > the function
> >
> > /* duplicate a string or return NULL on out of memory condition */
> > char *strdup(const char *str);
> >
> > can't fail.
>
> That looks fine.
>
No, it's not fine, because we seldom want a function whose purpose is
to either duplicate a string or tell us that the machine is out of
memory. If we call strdup, 99 times out of a hundred, we need that
duplicated string to proceed with the calculation. So if it returns
null, it has failed.
>
> So you would say that the above strdup() function is a "Malcolm
> procedure" because it can fail (by giving a clear result with no risk to
> the running of the program), while you would call this a "Malcolm
> function" because it will crash the program with a stack fault on most
> inputs:
>
> inf ack(int m, int n) {
> if (m == 0) return n + 1;
> if (n == 0) return ack(m, 1);
> return ack(m - 1, ack(m, n - 1));
> }
>
> And you think this artificial and poorly defined distinction is useful
> to anyone?
>
It would be nice to say that the comuter has an infinite amount of
memory. Then you could compute any computable function. But that cannot
be provided in the real world. It would also be nice to say that
the computer is so fast that any results will be returned in human-
meaningful time. Again, that cannot be provided in the real world.
So "Malcolm functions" can fail if they run out of memory, and
they won't return at all if they are pathological.
Incidentally, a better objection would be a minimum-searching
algorithm or a root finder. These are clearly "Malcolm functions"
in that they don't do IO. But generally they rely on a mathematical
series converging, and sometimes you don't get convergence. So
the function fails. So maybe it's not so true that a "Malcolm
fucntion" cannot fail.
But on modern computers, these things are nearly true. It's usually
more likely that the computer will break than that it will run out
of memory for a real allocation request. And the vast majority of
sensible calculations will complete in time for the user to receive
the results.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-06 09:07 +0200 |
| Message-ID | <r6ekep$sbj$1@dont-email.me> |
| In reply to | #151101 |
On 05/04/2020 22:59, Malcolm McLean wrote: > On Sunday, 5 April 2020 20:54:35 UTC+1, David Brown wrote: >> On 04/04/2020 20:18, Malcolm McLean wrote: >> >> Correct - "rand()" as defined by the C standards cannot be a pure >> function, as it holds state. But "pure function" remains a reasonable, >> though not perfect, term for a function whose result is solely dependent >> on its input arguments. >> >> Only you can really say what you mean by "Malcolm-function", and I'm not >> convinced your definition has been consistent every time it comes up. >> But by your current definition, pure functions are a subset of Malcolm >> functions. >> > I didn't invent the term "Malcolm function". I used the term "function" > in one of its accepted meanings. A meaning accepted by /you/, but not by others in this group. Quite possibly you use it in a way that is accepted in some other specific context, but different from its use in C. > A mapping of sets, of bits since we > are talkng about digital computers. If you don't allow globals and you > don't allow writes through pointers, so every function call is of the > form > > returnbits = functioncall(argumentbits) > > then this becomes obvious. But C isn't that language. I would say that this does not match your last Malcolm-function definition, because it does not allow something like "rand()" with static data. What you are talking about here is nothing more than a mathematical function with a particular type of domain. The word "function" has an accepted meaning in mathematics, but this is C programming, not mathematics. > >>> a [piece of code which calculates] a relationship between two sets [of >>> bits] in which each part of the first set is connected with just one >>> member of the second set in number pairs [Cambridge dictionary] >>> >> >> Why would you think an English language dictionary definition would be >> relevant here? (That's a rhetorical question - we all know that it is >> not relevant.) >> > The concept of a function as a mapping of a first set to a second > set is important. It is important - in mathematics. This is not a mathematics group. (And mathematicians would be unlikely to look at a language dictionary for a meaning of their terms.) >> >>> It is crashingly simple. Either it does IO or not. If you do IO, you >>> are doing something, you are not (just) calculating something. So >>> you are a "procedure". >>> >> >> You can't make such a distinction, because there is no clear separation >> of whether code performs IO or does not. A piece of code may sometimes >> perform an external IO operation and sometimes not, depending its >> arguments - does it then change between being a Malcolm-function and a >> Malcolm-procedure? A piece of code may change a variable in memory that >> is not displayed in normal use, but is logged in debug mode - does the >> mode of compilation or execution change the nature of the code? What if >> the function can be compiled with or without logging enabled? You are >> making an artificial distinction where none exists, and claiming it to >> be a distinguishing factor in dividing types of code where there is no >> benefit. >> > OK, so genrally there is no problem. The "function" printf() is > desinged to send characters to a device attached to standard output. > The function sqrt() makes a one to one mapping between its argument > and return value (and errno, which is why we can't use the term "pure > fucntion"). Go through the standard library, and everyone will > probably agree which are the IO procedures and which are the non > IO functions. > > But what if code is instrumented for debug. What if stdout is reattached > to a memory buffer? What if a fucntion is passed a buffer which happens > to be memory mapped to a disply device? We can make things more complicated. > > But let's not distract ouselves from the central idea. If you do IO, > you are dependent on the machinery being attached to the computer. > If you do bit shuffling, you are not. It is not a matter of "distracting ourselves". You apparently agree there is no clear distinction between functions that perform IO and functions that do not. It doesn't matter if 90% of functions can be clearly categorised, or 99.9%, or 99.9999%. Attention to corner cases is how you do correct programming (and mathematics, for that matter) - it's the difference between a program that "works okay when I tested it" and "is known to be correct". Given a C function "foo", you can't be sure it can is a Malcolm-function or a Malcolm-procedure, and you can't be sure if its status is constant in different circumstances of compilation or running. You certainly have no idea based only on its declaration. It is therefore a pointless distinction (at least in C). Surely that can be the end of this pointless discussion, and hopefully the last time we see the terms "Malcolm-function" or "Malcolm-procedure"? <snip>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 02:25 -0700 |
| Message-ID | <0838cd07-3924-4e2f-b706-52f54ad60ba2@googlegroups.com> |
| In reply to | #151112 |
On Monday, 6 April 2020 08:07:13 UTC+1, David Brown wrote: > > > A mapping of sets, of bits since we > > are talkng about digital computers. If you don't allow globals and you > > don't allow writes through pointers, so every function call is of the > > form > > > > returnbits = functioncall(argumentbits) > > > > then this becomes obvious. But C isn't that language. > > I would say that this does not match your last Malcolm-function > definition, because it does not allow something like "rand()" with > static data. What you are talking about here is nothing more than a > mathematical function with a particular type of domain. The word > "function" has an accepted meaning in mathematics, but this is C > programming, not mathematics. > The hypothetical language would make it impossible to write rand() with the C interface, so it would be obvious what I am talking about. Globals muddy the water, make it more difficult for people to grasp what is going on, prevent us from using the term "pure function" which I think even Keith wouldn't object to. > > > The concept of a function as a mapping of a first set to a second > > set is important. > > It is important - in mathematics. This is not a mathematics group. > (And mathematicians would be unlikely to look at a language dictionary > for a meaning of their terms.) > But maths is intimately tied to programming. > > But let's not distract ouselves from the central idea. If you do IO, > > you are dependent on the machinery being attached to the computer. > > If you do bit shuffling, you are not. > > It is not a matter of "distracting ourselves". You apparently agree > there is no clear distinction between functions that perform IO and > functions that do not. It doesn't matter if 90% of functions can be > clearly categorised, or 99.9%, or 99.9999%. Attention to corner cases > is how you do correct programming (and mathematics, for that matter) - > it's the difference between a program that "works okay when I tested it" > and "is known to be correct". > This is a common fallacy, if we can present a marginal case, a category disappears. > > Given a C function "foo", you can't be sure it can is a Malcolm-function > or a Malcolm-procedure, and you can't be sure if its status is constant > in different circumstances of compilation or running. You certainly > have no idea based only on its declaration. It is therefore a pointless > distinction (at least in C). > Of course in the vast majority of cases it is totally unproblematic, either it does IO or not. You can't be sure from the prototype, in C, not necesarily in another langues, but we are talking about C. If it is problematic a) does it write to any absolute addresses b) are subroutines eliminable, c) if it passed a function pointer, can that function be written without IO ? The real test however is, if you take the Io away and replace it with a completely different system, does the code still work? I think that covers it. > Surely that can be the end of this pointless discussion, and hopefully > the last time we see the terms "Malcolm-function" or "Malcolm-procedure"? > The terms "Malcolm function" and "Malcolm procedure" are, I agree ridiculous. The proper terms are "function" and "procedure" and it should be clear that I am using them in senses accepted by the English language, but not exactly as they are used in some other computer contexts. People ought to be able to cope with this, but they can't. They object. I can only do my best.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-06 11:43 +0100 |
| Message-ID | <87pnckc2sb.fsf@bsb.me.uk> |
| In reply to | #151119 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: <cut> > The terms "Malcolm function" and "Malcolm procedure" are, I agree > ridiculous. The proper terms are "function" and "procedure" and it > should be clear that I am using them in senses accepted by the > English language, but not exactly as they are used in some other > computer contexts. People ought to be able to cope with this, but > they can't. They object. I can only do my best. You are re-writing history. You once put it very clearly: "There are two sorts of functions, function that do IO, and functions that shuffle bits about in the computer memory." You went on to say that "In normal English usage, the first are 'procedures', the second 'functions'". I don't have a dictionary for normal English, so I can't check that. But I do /speak/ English, and the distinction between doing IO and everything else is not one I recognise. I also have a reasonable education in mathematics and computer science, and the distinction you make is not one that I associate with the words "function" and "procedure" from those fields either. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 03:56 -0700 |
| Message-ID | <56fbdc1a-62fe-4b91-af72-1f65a78e7128@googlegroups.com> |
| In reply to | #151124 |
On Monday, 6 April 2020 11:43:57 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > <cut> > > The terms "Malcolm function" and "Malcolm procedure" are, I agree > > ridiculous. The proper terms are "function" and "procedure" and it > > should be clear that I am using them in senses accepted by the > > English language, but not exactly as they are used in some other > > computer contexts. People ought to be able to cope with this, but > > they can't. They object. I can only do my best. > > You are re-writing history. You once put it very clearly: > > "There are two sorts of functions, function that do IO, and functions > that shuffle bits about in the computer memory." > > You went on to say that > > "In normal English usage, the first are 'procedures', the second > 'functions'". > > I don't have a dictionary for normal English, so I can't check that. > But I do /speak/ English, and the distinction between doing IO and > everything else is not one I recognise. I also have a reasonable > education in mathematics and computer science, and the distinction you > make is not one that I associate with the words "function" and > "procedure" from those fields either. > I'm really surprisd at that. A C function either calculates something e.g. sqrt, does something, e.g. fopen(), or of course does both. So a normal word for something that does something is "procedure". A set of rules or instructions for carrying out an action. That seems to match very closely something like printf. Now if a function calculates something, what is it doing? It's taking one set of bits in the computer's memory, moving them about according to some rules, to produce a different arrangement of bits in the computer's memory. "Function" is a perfectly good term for that, except that in the context of C, the word has been used in a broader sense. Then what I've said is that if a function does both - it both takes an action and calculates something, it's a "procedure". That's maybe an original step. As for the idea that the distinction isn't useful, or doesn't make sense, that can be debated. I'd say it obviously makes sense and should be fairly unproblematic to anyone with an interest in engaging constructively rather than sniping. As for how useful it is, that remains to be seen. it might be that this system doesn't actually help very much in software engineering. But I haven't yet seen anyone seriously make that point.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-06 16:34 +0100 |
| Message-ID | <87eet0bpbs.fsf@bsb.me.uk> |
| In reply to | #151127 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 6 April 2020 11:43:57 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> <cut>
>> > The terms "Malcolm function" and "Malcolm procedure" are, I agree
>> > ridiculous. The proper terms are "function" and "procedure" and it
>> > should be clear that I am using them in senses accepted by the
>> > English language, but not exactly as they are used in some other
>> > computer contexts. People ought to be able to cope with this, but
>> > they can't. They object. I can only do my best.
>>
>> You are re-writing history. You once put it very clearly:
>>
>> "There are two sorts of functions, function that do IO, and functions
>> that shuffle bits about in the computer memory."
>>
>> You went on to say that
>>
>> "In normal English usage, the first are 'procedures', the second
>> 'functions'".
>>
>> I don't have a dictionary for normal English, so I can't check that.
>> But I do /speak/ English, and the distinction between doing IO and
>> everything else is not one I recognise. I also have a reasonable
>> education in mathematics and computer science, and the distinction you
>> make is not one that I associate with the words "function" and
>> "procedure" from those fields either.
>>
> I'm really surprisd at that. A C function either calculates something
> e.g. sqrt, does something, e.g. fopen(), or of course does both.
That's disingenuous and, I am having a hard to believing you are
discussing this in good faith. Was your original remark deliberately
misleading? Are there (in Malcolm-speak) functions, procedures and
something else you have declined to name? If not, doing or not doing IO
is the defining characteristic and the rest, shuffling bits, is just
what's left over -- anything other the IO must be what you call
shuffling bits. So this
static unsigned long long number_of_function_calls;
void count_a_call(void) { number_of_function_calls++; }
is a Malcolm-function, yes? As, I presume, is this:
void swap(T *a, T *b) { T t = *a; *a = *b; *b = t; }
You defended these being called functions by quoting the mathematical
definition -- a certain kind of mapping between two sets. I don't see
it here. These are classic examples of procedures as the terms is
commonly used in computing.
Of course, we still have the problem of what constitutes "doing IO".
For example:
a) accessing a volatile object?
b) calling exit?
c) calling abort?
d) calling clock, time, asctime etc.?
e) calling setlocale?
f) calling thrd_create (and similar)?
> So a normal word for something that does something is "procedure".
> A set of rules or instructions for carrying out an action. That
> seems to match very closely something like printf.
Yes, and for my two above examples above. What's more, for most people
using "normal words", it also describes the code that calculates square
roots. It matches the definitions for that word that I could find in
dictionaries. For example Collins says it's just nother name for a
subroutine:
"a section of a computer program that is stored only once but can be
used when required at several different points in the program, thus
saving space"
Not a great definition, but which dictionary says it means "code that
does IO"?
Maybe Collins agrees that a function is just code that excludes IO.
Nope:
"A function is a series of operations that a computer performs, for
example when a single key or a combination of keys is pressed."
And if you intend the "normal English" word to be the mathematical
definition:
"a relation between two sets that associates a unique element (the
value) of the second (the range) with each element (the argument) of
the first (the domain): a many-one relation."
Then my two examples above don't fit. That is unless you are taking the
view that the entire state of the program store is some sort of implied
parameter to every function, and that is also forms part of the result.
If that is your view, then your more recent statements about calculating
a valued based on "inputs" are disingenuous to the point of being
deceptions.
> Now if a function calculates something, what is it doing? It's taking
> one set of bits in the computer's memory, moving them about according
> to some rules, to produce a different arrangement of bits in the
> computer's memory. "Function" is a perfectly good term for that,
> except that in the context of C, the word has been used in a broader
> sense.
Does this very general wording mean that you do include all the store as
some sort of implied parameter, and that you also include it as part of
the result?
> Then what I've said is that if a function does both - it both takes
> an action and calculates something, it's a "procedure". That's maybe
> an original step.
The original step is to say that doing IO makes code a procedure and not
doing IO makes it a function. That all you, as far as I can tell.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 10:30 -0700 |
| Message-ID | <ca19cb62-da71-4bcc-bf84-2242466a15ae@googlegroups.com> |
| In reply to | #151140 |
On Monday, 6 April 2020 16:34:40 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:> > Then my two examples above don't fit. That is unless you are taking the > view that the entire state of the program store is some sort of implied > parameter to every function, and that is also forms part of the result. > If that is your view, then your more recent statements about calculating > a valued based on "inputs" are disingenuous to the point of being > deceptions. > I think the penny has finally dropped. The commonsense and useful defintion of a "function" is "code that doesn't do IO". But if you want a slightly more abstruse defintion, it's "code that maps one ste of the program store on entry to another state on exit, with exit state being defined by entry state, and does nothing else". A "procedure" is any code that isn't a function, which usually means "code which does something as opposed to calculating something". malloc() and the pointer it returns is a special case. > > > Then what I've said is that if a function does both - it both takes > > an action and calculates something, it's a "procedure". That's maybe > > an original step. > > The original step is to say that doing IO makes code a procedure and not > doing IO makes it a function. That all you, as far as I can tell. > That's step one. Step two is to say, "separate your procedures from your functions".
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2020-04-06 17:50 +0000 |
| Message-ID | <r6fq4l$1a1h$1@macpro.inf.ed.ac.uk> |
| In reply to | #151146 |
In article <ca19cb62-da71-4bcc-bf84-2242466a15ae@googlegroups.com>, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >I think the penny has finally dropped. The commonsense and useful >defintion of a "function" is "code that doesn't do IO". A more natural distinction is "a procedure that doesn't have any side effects", which fits with the term "functional programming". -- Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-06 11:31 -0700 |
| Message-ID | <87imico48l.fsf@nosuchdomain.example.com> |
| In reply to | #151146 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> I think the penny has finally dropped. The commonsense and useful
> defintion of a "function" is "code that doesn't do IO".
[...]
No, that's not what "function" means in C, the language which is
the topic of this newsgroup.
Please don't assume that we don't understand what you're saying.
We simply think you're wrong, and we choose not to accept your
deliberate abuse of well defined terminology.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 12:04 -0700 |
| Message-ID | <5b8f4237-a6a4-425a-b737-518682d33d5f@googlegroups.com> |
| In reply to | #151150 |
On Monday, 6 April 2020 19:31:47 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > I think the penny has finally dropped. The commonsense and useful > > defintion of a "function" is "code that doesn't do IO". > [...] > > No, that's not what "function" means in C, the language which is > the topic of this newsgroup. > > Please don't assume that we don't understand what you're saying. > We simply think you're wrong, and we choose not to accept your > deliberate abuse of well defined terminology. > I know. Hopefully we can move on from this.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-06 21:51 +0100 |
| Message-ID | <87mu7o9w2m.fsf@bsb.me.uk> |
| In reply to | #151146 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Monday, 6 April 2020 16:34:40 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:> > >> Then my two examples above don't fit. That is unless you are taking the >> view that the entire state of the program store is some sort of implied >> parameter to every function, and that is also forms part of the result. >> If that is your view, then your more recent statements about calculating >> a valued based on "inputs" are disingenuous to the point of being >> deceptions. >> > I think the penny has finally dropped. For whom? Are you saying you now see how you have been misleading people with examples like sqrt, and quoting the definition of a mathematical function? Unless you make it clear that the whole store (well, any part this is directly or indirectly accessible) is an implicit parameter, saying that rand() and swap() are Malcolm functions (and thus like a mathematical functions) is highly misleading. > The commonsense and useful > defintion of a "function" is "code that doesn't do IO". I don't find it useful, and it does not square with my common sense, but that does not matter. Can you back up the claim that in "normal English" a procedure is code that does IO? If not, let's keep the Malcolm prefix to avoid confusion. Anyway, it seems you are trying to be somewhat clear now -- a Malcolm procedure does IO and everything else is a Malcolm function. Got it. <cut> > malloc() and the pointer it returns is a special case. And then, in a flash, I don't have it! I don't see the point of this if you won't address these marginal cases. You did not even answer my questions about what constitutes IO, and you already have special cases without saying anything more than they are special... Even the notion of "doing" is up for grabs. Does a Malcolm function become a Malcolm procedure when a function (C sense) that it calls is changed to do some IO? What happens when the IO is done (or not done) in a function passed to a Malcolm function as a pointer? >> > Then what I've said is that if a function does both - it both takes >> > an action and calculates something, it's a "procedure". That's maybe >> > an original step. >> >> The original step is to say that doing IO makes code a procedure and not >> doing IO makes it a function. That all you, as far as I can tell. >> > That's step one. Step two is to say, "separate your procedures from > your functions". Until you can show otherwise, they are clearly Malcolm procedures, and just to be clear, they are all functions as far as C in concerned. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 14:34 -0700 |
| Message-ID | <e16038e0-6fdf-4013-9cd5-a26c0f2e72e5@googlegroups.com> |
| In reply to | #151157 |
On Monday, 6 April 2020 21:51:56 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > > malloc() and the pointer it returns is a special case. > > And then, in a flash, I don't have it! > OK, so basically we have a state of bits when we call the function, and a state of bits when the function returns. We don't do any IO, we don't read any volatiles, we don't do anything like that. So the state of the program when the function returns must be totally determined by the state on entry. There's a mapping of every possible arrangement of bits in the program's store on entry to another one arrangement of exit. The English word for that relationship is "function". That's the right term to use. However if we call malloc(), then we are altering the store itself. Unless we insist that malloc be implemented as a static arena within the program itself, the pointer we get back isn't determined by the state of the bits on program entry. So you could say "so that means that malloc is IO and memory is adevice". And there would be some advantages to doing that. But in fact I don't, I make an exception for malloc. > > I don't see the point of this if you won't address these marginal cases. > You did not even answer my questions about what constitutes IO, and you > already have special cases without saying anything more than they are > special... > You seem to think that it's so important to address marginal cases. But the vast majority of cases are unproblematic, and if I develop the idea (ideally with the help of people here, but I don't see any real willingness to do that) then these can be sorted out. Once the main idea is clarified. "A function doesn't do IO, a procedure does" is a first shot at defining the difference, and basically it works. Normally there's not much problem in distinguishing the two. But what is IO? Firstly, its anything that prevents bits on exit being defined by bits on entry, so, basically, that's input. Secondly, it's any action or manipulation of the world outside the program and its data store. A function can't bleep, unless its a C function. So that's output. Now one of the characteristics of functions is that they can be written without subroutines, except malloc. If a function is doing IO, that doesn't hold. So that's a test. Can we rewrite this function to eliminate all subroutines except malloc, and still fulfil its interface requirements? If we can't, it's a procedure. Ok, so what about indirect subroutines? Clearly qsort is a function and not a procedure. But what if someone slips a printf into the comparison function? Doesn't that break our rules? More about that later.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-06 14:39 -0700 |
| Message-ID | <87pnckmgzv.fsf@nosuchdomain.example.com> |
| In reply to | #151160 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The English word for that relationship is "function". That's the right
> term to use.
[...]
No, that's not what "function" means in C, which is the topic of this
newsgroup.
(Don't worry, I'm not planning to do this indefinitely.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-06 14:52 -0700 |
| Message-ID | <14b1a243-bf6e-4b3c-ab65-2d97f4b76eb2@googlegroups.com> |
| In reply to | #151161 |
On Monday, 6 April 2020 22:39:08 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > The English word for that relationship is "function". That's the right > > term to use. > [...] > > No, that's not what "function" means in C, which is the topic of this > newsgroup. > > (Don't worry, I'm not planning to do this indefinitely.) > OK, so sugest another term for "a relationship bewteen an first set of bits and a second set of bits, such that there is a mapping of every member of the first set to one and only one member of the second set".
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web