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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-12 21:34 +0100 |
| Message-ID | <87zhbgl9yd.fsf@bsb.me.uk> |
| In reply to | #151298 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>> > On 4/10/20 2:38 PM, Malcolm McLean wrote:
>> >> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
>> >>>
>> >>> I was asking because you were seemingly claiming that when
>> >>> some used bits are originating from memory mapped input and/or
>> >>> some altered bits go into memory mapped output then it somehow
>> >>> does not matter because the code is likely platform specific.
>> >>> However purity and portability seem to be orthogonal properties
>> >>> of code and correlation seems incidental.
>> >>>
>> >> Pure functions can always be written portably.
>> >
>> > Disagree here. The ONLY way you can make such a claim is to restrict
>> > your machine definition to something that isn't efficient. Either you
>> > need to define that all math is to be done in infinite precision
>> > arithmetic (which is inefficient on most machines), has a language
>> > defined precision (sort of like what Java does so that it is inefficient
>> > on any machine that doesn't well match the language specification) or
>> > you get non-portable answers. C was designed for efficiency over
>> > portability, which is one reason it did succeed in its designed market.
>>
>> I was debating whether to make this point as well. MM is a broad-brush
>> kind of person and I am sure there is some meaning (possibly along the
>> lines you paint here) that is what was really meant. Anyway, for what
>> it's worth, my example was going to be
>>
>> unsigned long long bit_set(void)
>> {
>> return 0x800008000200000020000000800A20AC;
>> }
>>
>> where the author clearly knew that unsigned long long was 128 bits wide.
>>
>> This function can't be written portably (in the usual sense of the word)
>> because not all implementations have an 128-bit unsigned type. The
>> whole program would need to be re-engineered (quite possible including
>> some of the I/O library) to use an invented fake 128-bit integer type.
>> And even that counts as "portable", it's likely that a total re-design
>> of affected parts would be an better option.
>>
>> The fact that this function is pure is, to put is mildly, secondary to
>> the fact that it is very much not portable.
>>
> A function maps bits on entry to bits on exit, and if you want to be
> 100% portable you have to specify it in terms of bits. So yes, you
> need to fake up a 128 bit type if you need 128 bit computations. But
> you can do that.
You appeared to want your odd distinction for "structuring" the code
with, unless I misunderstood, portability in mind. The point of these
examples is that a few Malcolm functions might well be the portability
headaches, and not any of the Malcolm procedures.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-12 14:38 -0700 |
| Message-ID | <35f04e61-0297-4ce4-912b-10831fc16cac@googlegroups.com> |
| In reply to | #151301 |
On Sunday, 12 April 2020 21:34:50 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> > On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>
> >> > On 4/10/20 2:38 PM, Malcolm McLean wrote:
> >> >> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
> >> >>>
> >> >>> I was asking because you were seemingly claiming that when
> >> >>> some used bits are originating from memory mapped input and/or
> >> >>> some altered bits go into memory mapped output then it somehow
> >> >>> does not matter because the code is likely platform specific.
> >> >>> However purity and portability seem to be orthogonal properties
> >> >>> of code and correlation seems incidental.
> >> >>>
> >> >> Pure functions can always be written portably.
> >> >
> >> > Disagree here. The ONLY way you can make such a claim is to restrict
> >> > your machine definition to something that isn't efficient. Either you
> >> > need to define that all math is to be done in infinite precision
> >> > arithmetic (which is inefficient on most machines), has a language
> >> > defined precision (sort of like what Java does so that it is inefficient
> >> > on any machine that doesn't well match the language specification) or
> >> > you get non-portable answers. C was designed for efficiency over
> >> > portability, which is one reason it did succeed in its designed market.
> >>
> >> I was debating whether to make this point as well. MM is a broad-brush
> >> kind of person and I am sure there is some meaning (possibly along the
> >> lines you paint here) that is what was really meant. Anyway, for what
> >> it's worth, my example was going to be
> >>
> >> unsigned long long bit_set(void)
> >> {
> >> return 0x800008000200000020000000800A20AC;
> >> }
> >>
> >> where the author clearly knew that unsigned long long was 128 bits wide.
> >>
> >> This function can't be written portably (in the usual sense of the word)
> >> because not all implementations have an 128-bit unsigned type. The
> >> whole program would need to be re-engineered (quite possible including
> >> some of the I/O library) to use an invented fake 128-bit integer type.
> >> And even that counts as "portable", it's likely that a total re-design
> >> of affected parts would be an better option.
> >>
> >> The fact that this function is pure is, to put is mildly, secondary to
> >> the fact that it is very much not portable.
> >>
> > A function maps bits on entry to bits on exit, and if you want to be
> > 100% portable you have to specify it in terms of bits. So yes, you
> > need to fake up a 128 bit type if you need 128 bit computations. But
> > you can do that.
>
> You appeared to want your odd distinction for "structuring" the code
> with, unless I misunderstood, portability in mind. The point of these
> examples is that a few Malcolm functions might well be the portability
> headaches, and not any of the Malcolm procedures.
>
All the "Malcolm functions" can be written portably, but that doesn't
mean to say that they are written portably, or that if they are not
written portably they are somehow lesser Malcolm functions. That
doesn't even say that they should be written portably.
The signatures need to be specified portably if the code is to be
portable, of course. Which means that we have to say that "an
implemention of a function" means "a compatible mapping of bits to
bits", not a "a mapping of C variables to C variables", though the
latter is how we think in practice, until, as with 128 bit arithmetic,
it bites us and we need to drop down to talking about bits.
In practice, might our Malcolm functions be the portablity headache,
not the IO? In a sense, that you might be fairly confident that
you won't lose the IO, less confident that you won't lose 128 bit type.
But you should know when your Malcolm functions are using non-portable
operations on types. Fix that, and they will work for as long as there
is a compatible dialect of C. However the IO system may be taken away
because of some unexpected future development.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-13 11:13 -0400 |
| Message-ID | <5k%kG.2$th5.0@fx14.iad> |
| In reply to | #151298 |
On 4/12/20 7:39 AM, Malcolm McLean wrote:
> On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 4/10/20 2:38 PM, Malcolm McLean wrote:
>>>> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
>>>>>
>>>>> I was asking because you were seemingly claiming that when
>>>>> some used bits are originating from memory mapped input and/or
>>>>> some altered bits go into memory mapped output then it somehow
>>>>> does not matter because the code is likely platform specific.
>>>>> However purity and portability seem to be orthogonal properties
>>>>> of code and correlation seems incidental.
>>>>>
>>>> Pure functions can always be written portably.
>>>
>>> Disagree here. The ONLY way you can make such a claim is to restrict
>>> your machine definition to something that isn't efficient. Either you
>>> need to define that all math is to be done in infinite precision
>>> arithmetic (which is inefficient on most machines), has a language
>>> defined precision (sort of like what Java does so that it is inefficient
>>> on any machine that doesn't well match the language specification) or
>>> you get non-portable answers. C was designed for efficiency over
>>> portability, which is one reason it did succeed in its designed market.
>>
>> I was debating whether to make this point as well. MM is a broad-brush
>> kind of person and I am sure there is some meaning (possibly along the
>> lines you paint here) that is what was really meant. Anyway, for what
>> it's worth, my example was going to be
>>
>> unsigned long long bit_set(void)
>> {
>> return 0x800008000200000020000000800A20AC;
>> }
>>
>> where the author clearly knew that unsigned long long was 128 bits wide.
>>
>> This function can't be written portably (in the usual sense of the word)
>> because not all implementations have an 128-bit unsigned type. The
>> whole program would need to be re-engineered (quite possible including
>> some of the I/O library) to use an invented fake 128-bit integer type.
>> And even that counts as "portable", it's likely that a total re-design
>> of affected parts would be an better option.
>>
>> The fact that this function is pure is, to put is mildly, secondary to
>> the fact that it is very much not portable.
>>
> A function maps bits on entry to bits on exit, and if you want to be
> 100% portable you have to specify it in terms of bits. So yes, you
> need to fake up a 128 bit type if you need 128 bit computations. But
> you can do that.
> Instead of saying "this function must return a C unsigned long that
> holds the value 0x800008000200000020000000800A20AC, which is clearly
> impossible to achieve portably, we need to say
> "this function must map the unit set (an empty list of bits in), to
> the set of bits that represent values, choosing the member that
> represents the value 0x800008000200000020000000800A20AC".
>
> You then have to provide "the set of bits that represent values", which
> depends on the rest of the program.
>
> There's the human-meaningful function you are trying to model, then
> there's the C type. Sometimes, though rarely, the C types won't be
> up to the task of modelling the human-meaningful function, so you
> have to drop down to bits.
>
> To give another example, consider the fucntion "cosine". We could say
> the human meaningful function is "this function shall a reasonable
> approximation to the cosine of theta, as long as theta is reasonably
> close to the range +/- 2 * PI". Or we could say, "this function shall
> return the cosine of theta, adhering exactly to important body standard
> this and that".
> You can reasonably want either, but if the higher ups demand the second,
> we have a portablity headache. However that won't daunt us. We'll just
> download some floating point routines from github, and build the
> function on top of integer operations.
>
So I guess this means that C can't have functions, since C has no
totally portable way of defining inputs and outputs in terms of 'bits'.
The closest you can get with this would be arrays of unsigned chars,
which even that is technically not portable in C since you have some
machines where CHAR_BITS != 8. Also most of the standard library are not
functiona since it defines inputs and outputs in terms of things that
aren't fixed in size. (maybe some of the string functions are if you are
willing to restrict yourself to machines with CHAR_BITS = 8).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-13 08:24 -0700 |
| Message-ID | <e7a78448-9358-4609-b138-3107e572534d@googlegroups.com> |
| In reply to | #151304 |
On Monday, 13 April 2020 16:13:13 UTC+1, Richard Damon wrote:
> On 4/12/20 7:39 AM, Malcolm McLean wrote:
> > On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>
> >>> On 4/10/20 2:38 PM, Malcolm McLean wrote:
> >>>> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
> >>>>>
> >>>>> I was asking because you were seemingly claiming that when
> >>>>> some used bits are originating from memory mapped input and/or
> >>>>> some altered bits go into memory mapped output then it somehow
> >>>>> does not matter because the code is likely platform specific.
> >>>>> However purity and portability seem to be orthogonal properties
> >>>>> of code and correlation seems incidental.
> >>>>>
> >>>> Pure functions can always be written portably.
> >>>
> >>> Disagree here. The ONLY way you can make such a claim is to restrict
> >>> your machine definition to something that isn't efficient. Either you
> >>> need to define that all math is to be done in infinite precision
> >>> arithmetic (which is inefficient on most machines), has a language
> >>> defined precision (sort of like what Java does so that it is inefficient
> >>> on any machine that doesn't well match the language specification) or
> >>> you get non-portable answers. C was designed for efficiency over
> >>> portability, which is one reason it did succeed in its designed market.
> >>
> >> I was debating whether to make this point as well. MM is a broad-brush
> >> kind of person and I am sure there is some meaning (possibly along the
> >> lines you paint here) that is what was really meant. Anyway, for what
> >> it's worth, my example was going to be
> >>
> >> unsigned long long bit_set(void)
> >> {
> >> return 0x800008000200000020000000800A20AC;
> >> }
> >>
> >> where the author clearly knew that unsigned long long was 128 bits wide.
> >>
> >> This function can't be written portably (in the usual sense of the word)
> >> because not all implementations have an 128-bit unsigned type. The
> >> whole program would need to be re-engineered (quite possible including
> >> some of the I/O library) to use an invented fake 128-bit integer type.
> >> And even that counts as "portable", it's likely that a total re-design
> >> of affected parts would be an better option.
> >>
> >> The fact that this function is pure is, to put is mildly, secondary to
> >> the fact that it is very much not portable.
> >>
> > A function maps bits on entry to bits on exit, and if you want to be
> > 100% portable you have to specify it in terms of bits. So yes, you
> > need to fake up a 128 bit type if you need 128 bit computations. But
> > you can do that.
> > Instead of saying "this function must return a C unsigned long that
> > holds the value 0x800008000200000020000000800A20AC, which is clearly
> > impossible to achieve portably, we need to say
> > "this function must map the unit set (an empty list of bits in), to
> > the set of bits that represent values, choosing the member that
> > represents the value 0x800008000200000020000000800A20AC".
> >
> > You then have to provide "the set of bits that represent values", which
> > depends on the rest of the program.
> >
> > There's the human-meaningful function you are trying to model, then
> > there's the C type. Sometimes, though rarely, the C types won't be
> > up to the task of modelling the human-meaningful function, so you
> > have to drop down to bits.
> >
> > To give another example, consider the fucntion "cosine". We could say
> > the human meaningful function is "this function shall a reasonable
> > approximation to the cosine of theta, as long as theta is reasonably
> > close to the range +/- 2 * PI". Or we could say, "this function shall
> > return the cosine of theta, adhering exactly to important body standard
> > this and that".
> > You can reasonably want either, but if the higher ups demand the second,
> > we have a portablity headache. However that won't daunt us. We'll just
> > download some floating point routines from github, and build the
> > function on top of integer operations.
> >
>
> So I guess this means that C can't have functions, since C has no
> totally portable way of defining inputs and outputs in terms of 'bits'.
> The closest you can get with this would be arrays of unsigned chars,
> which even that is technically not portable in C since you have some
> machines where CHAR_BITS != 8. Also most of the standard library are not
> functiona since it defines inputs and outputs in terms of things that
> aren't fixed in size. (maybe some of the string functions are if you are
> willing to restrict yourself to machines with CHAR_BITS = 8).
>
You define "implementing the function" as "producing a compatible
mapping of bits to bits". You then define the bits in terms of C types
when you actually implement it.
You don't define the function in terms of a mapping of C variables
to other C variables. Then it's not inherently portable, because the
C variables aren't inherently portable. They are good enough for most
practical purposes, but not if you insist on completely exact
results from floating point operations under any implementation
whatsoever, for example. Or if you want 128 bit arithmetic.
Ben's function is so simple that it isn't obvious that we are "implementing
it" by changing the representation of the value. Make it a bit more
complicated, for example to sum a list of 128 bit values, and then
it should be clearer that the version with a portable interface is
"the same function".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-11 15:08 -0700 |
| Message-ID | <87d08dk74c.fsf@nosuchdomain.example.com> |
| In reply to | #151293 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> This simple question of what is the natural result of 20,000 + 20,000
> has two possible answers on common current machines, 40,000 and -25,536
> (on a machine with 16 bit integers).
[...]
For certain meanings of "natural result". In C semantics, the
possible answers are 40000 and undefined behavior.
(Or just 0 if those commas are comma operators, but I've decided
not to be quite that pedantic.)
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-09 09:53 -0700 |
| Message-ID | <cc4bee96-5f3d-40e4-b090-99a289c44faa@googlegroups.com> |
| In reply to | #151266 |
On Thursday, April 9, 2020 at 11:56:40 AM UTC-4, Malcolm McLean wrote: > On Thursday, 9 April 2020 16:42:13 UTC+1, James Kuyper wrote: > > On Thursday, April 9, 2020 at 4:58:09 AM UTC-4, Malcolm McLean wrote: > > > > OK - that I missed. So my follow-up question remains: why did you > > follow up at a later time, by saying "volatile ... can't have any > > effect unless you use non-core language facilities"? I guess that > > the answer is your assumption, explained below, that interrupts > > must be invoked to make that happen: > > > Making data volatile means "something outside of the current thread > may read / write this", or, in the case of a delay loop, "don't optimise this > away". However using core C, there's no way to create the "something > outside of the current thread". True - but that something might have been created for you without your code needing to do anything about it. For instance, it might be hardware physically attached to your system. ... > Interrupts are an example of something that might access volatile > memory. The interrupt service routine and the main routine can both > be written in core C, but they can't be set up in that relationship. If the hardware needs an interrupt, the C compiler could generated an executable that issues the required interrupt as a side-effect of the corresponding read from/write to memory. ... > Yes, but you need to obtain an address from somewhere to do memory > mapped IO. You can't do that with the core language. The relevant address, or at least a method for finding out what its is before you write the code, might be described in the documentation for the implementation. The fact that you have to read the documentation in order to write the code isn't exactly unusual - it's the norm for every feature of C that is described as "implementation-defined". That's what the required documentation is for. Or, from another point of view, that what the documentation requirement is for. The fact that you have to do such reading to make it work doesn't change the fact that, if such an implementation did exist, it would work - code that only makes use of core-language features could cause I/O to occur.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-07 14:35 -0400 |
| Message-ID | <r6ih4t$ot2$1@dont-email.me> |
| In reply to | #151195 |
On 4/7/20 12:55 PM, Scott Lurndal wrote: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> 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. >>> >>> Does anyone else care about the distinction you are making? But if you >>> come up with any references that support the idea that a routine that >>> does not do IO should be called a function and one the does, a >>> procedure, I'd be interested. It might answer the questions you have >>> not. >> >> Of course not. If anyone did, either there would be competing >> definitions of "function" and "procedure" (or, conceivably, the existing >> terms could match Malcolm's definitions), or there would be new terms >> based on the distinction. > > He's probably an old Pascal programmer, wherein there was a distinction > between procedure and function. That's not a plausible explanation, because the distinction Pascal makes between a procedure and a function is NOT the one that Malcolm makes. In fact, as far as I know, nobody makes that particular distinction the way Malcolm does, except Malcolm. That's the fundamental problem: languages are for communication between two or more people, and the words of the language have to have the same meaning to all of the participants in the discussion for meaningful communication to occur. And Malcolm routinely uses idiosyncratic meanings for a wide variety of terms, while believing that his idiosyncratic meanings are in fact nearly universal.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-06 21:04 -0700 |
| Message-ID | <7a652b93-d4b8-4e07-87b5-46781034d4b3@googlegroups.com> |
| In reply to | #151166 |
On Tuesday, 7 April 2020 05:08:53 UTC+3, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > 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. > > Does anyone else care about the distinction you are making? But if you > come up with any references that support the idea that a routine that > does not do IO should be called a function and one the does, a > procedure, I'd be interested. It might answer the questions you have > not. Function that can not have side effects is important concept since it is easy for human to reason about and for compiler to optimize (up to executing it at compile time). I am unsure if Malcolm McLean talks about introducing such functions into C. He seems to talk about procedures that have little difference with what are functions of C right now. However about distinction of functional programming functions in C many would be happy I guess.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 01:16 -0700 |
| Message-ID | <ab5e3f77-ea97-4fa4-bfe5-390b5bf6bfa8@googlegroups.com> |
| In reply to | #151169 |
On Tuesday, 7 April 2020 05:04:13 UTC+1, Öö Tiib wrote: > On Tuesday, 7 April 2020 05:08:53 UTC+3, Ben Bacarisse wrote: > > Function that can not have side effects is important concept since it > is easy for human to reason about and for compiler to optimize (up > to executing it at compile time). I am unsure if Malcolm McLean > talks about introducing such functions into C. He seems to talk > about procedures that have little difference with what are functions > of C right now. However about distinction of functional programming > functions in C many would be happy I guess. > The concept of "a fucntion without side effects" or a "pure function" works well in some other programming languages. And you are right thst part of what I am trying to do is to get the benefits of such languages into C. In "language x" we can often write functions in the form output = functioncall(inputa, inputb) where functioncall is forbidden from modifying inputa or inputb, or anything accessed via them, and output can be a complex data structure. That's not so easy to achieve in C, because it doesn't have good facilities for returning values through the return type, and because for efficiency reasons, we often pass modifable buffers. Also C allows you to pass a modifable pointer to a variable that mgiht be far out of scope, and it allows globals. I agree that globals should be avoided where possible, but we've got to face the fact that the language allows them. Therefore, instead of saying that "functions are functions of their parameters and return value", I say, "functions are functions of the entire program state at entry, and the entire state at exit, with no side effects". So I'm not imposing a rule on the C programmer like "you can't use globals" or "all your pointer parameters must be const". Now to talk of the entire program state might be wild (and really its just to shut up those who get hung up by the fact that the C standard uses the term "function" to mean something else). In fact it's not as bad as that, because most programmers are sensible. The area of memory affected by the function is closely and clearly defined. However I am saying, essentially, that if it does IO, or to meet the objections, if it does anything other than mapping bit patterns to bit patterns, then it is not a "function", it's "procedure". I'm not hung up by the term s"function" and "procedure" but they seem to me the best words to use, rather than try to invent a word. A procedure can call a function, but a function may not call a procedure. Now we separate out the functions from the procedures, and put them in separate source files. What are the benefits? Well we can always write our functions portably. They're not doing anything other than moving bits about. We can also eliminate all subroutine calls (except malloc() and family), so we can port it even to a platform that doesn't have a standard library. And we can take it out of its context, put it into a test environment, then put it back. Because it can be made dependency free (or in reality it depends on other functions, but only on other functions, which we also take). Also, it can only fail if it runs out of memory (annoyingly). Which in many environments is vanishingly unlikely to happen. So we don't need complex error handling, the only error we need to handle is the out of memory condition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-07 02:08 -0700 |
| Message-ID | <87d08jmzmh.fsf@nosuchdomain.example.com> |
| In reply to | #151176 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> However I am saying, essentially, that if it does IO, or to meet the
> objections, if it does anything other than mapping bit patterns to
> bit patterns, then it is not a "function", it's "procedure". I'm
> not hung up by the term s"function" and "procedure" but they seem
> to me the best words to use, rather than try to invent a word.
No, that's not what "function" means in C.
[...]
--
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-07 02:19 -0700 |
| Message-ID | <69267d29-cc98-458a-b80d-48c17743af51@googlegroups.com> |
| In reply to | #151177 |
On Tuesday, 7 April 2020 10:09:05 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > However I am saying, essentially, that if it does IO, or to meet the > > objections, if it does anything other than mapping bit patterns to > > bit patterns, then it is not a "function", it's "procedure". I'm > > not hung up by the term s"function" and "procedure" but they seem > > to me the best words to use, rather than try to invent a word. > > No, that's not what "function" means in C. > I've told you. If you can suggest another word which means "function" in the sense of "a mapping of one set of bits to another", then I'll consider using it instead. If you can't we've just got to live with the fact that the same word means different but related things in different contexts.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-07 08:42 -0700 |
| Message-ID | <878sj7mhf1.fsf@nosuchdomain.example.com> |
| In reply to | #151178 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 7 April 2020 10:09:05 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > However I am saying, essentially, that if it does IO, or to meet the
>> > objections, if it does anything other than mapping bit patterns to
>> > bit patterns, then it is not a "function", it's "procedure". I'm
>> > not hung up by the term s"function" and "procedure" but they seem
>> > to me the best words to use, rather than try to invent a word.
>>
>> No, that's not what "function" means in C.
>>
> I've told you. If you can suggest another word which means "function"
> in the sense of "a mapping of one set of bits to another", then I'll
> consider using it instead. If you can't we've just got to live with
> the fact that the same word means different but related things in
> different contexts.
Nope. It's not my job to come up with a word for a concept that
you find useful and I don't. It's your job to communicate clearly.
If you fail to do so, well, I have a solution for that.
I might tentatively suggest that a phrase of the form "<adjective>
function", where <adjective> is *not* a technical term defined
by the C standard, might suit your purposes. Picking the right
adjective is up to you.
--
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-07 10:39 -0700 |
| Message-ID | <c76b6bd0-cdbd-49b0-b825-d117f38614fe@googlegroups.com> |
| In reply to | #151189 |
On Tuesday, 7 April 2020 16:42:22 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Tuesday, 7 April 2020 10:09:05 UTC+1, Keith Thompson wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> [...] > >> > However I am saying, essentially, that if it does IO, or to meet the > >> > objections, if it does anything other than mapping bit patterns to > >> > bit patterns, then it is not a "function", it's "procedure". I'm > >> > not hung up by the term s"function" and "procedure" but they seem > >> > to me the best words to use, rather than try to invent a word. > >> > >> No, that's not what "function" means in C. > >> > > I've told you. If you can suggest another word which means "function" > > in the sense of "a mapping of one set of bits to another", then I'll > > consider using it instead. If you can't we've just got to live with > > the fact that the same word means different but related things in > > different contexts. > > Nope. It's not my job to come up with a word for a concept that > you find useful and I don't. It's your job to communicate clearly. > If you fail to do so, well, I have a solution for that. > > I might tentatively suggest that a phrase of the form "<adjective> > function", where <adjective> is *not* a technical term defined > by the C standard, might suit your purposes. Picking the right > adjective is up to you. > OK, how about "independent functions" for the functions that just do calculations, and "environmentally dependent functions" for the functions that do IO? Then we're still using the word "function" in the C sense.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-04-07 17:45 +0000 |
| Message-ID | <A_2jG.2229$Eu2.694@fx01.iad> |
| In reply to | #151199 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 7 April 2020 16:42:22 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> > On Tuesday, 7 April 2020 10:09:05 UTC+1, Keith Thompson wrote:
>> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> >> [...]
>> >> > However I am saying, essentially, that if it does IO, or to meet the
>> >> > objections, if it does anything other than mapping bit patterns to
>> >> > bit patterns, then it is not a "function", it's "procedure". I'm
>> >> > not hung up by the term s"function" and "procedure" but they seem
>> >> > to me the best words to use, rather than try to invent a word.
>> >>
>> >> No, that's not what "function" means in C.
>> >>
>> > I've told you. If you can suggest another word which means "function"
>> > in the sense of "a mapping of one set of bits to another", then I'll
>> > consider using it instead. If you can't we've just got to live with
>> > the fact that the same word means different but related things in
>> > different contexts.
>>
>> Nope. It's not my job to come up with a word for a concept that
>> you find useful and I don't. It's your job to communicate clearly.
>> If you fail to do so, well, I have a solution for that.
>>
>> I might tentatively suggest that a phrase of the form "<adjective>
>> function", where <adjective> is *not* a technical term defined
>> by the C standard, might suit your purposes. Picking the right
>> adjective is up to you.
>>
>OK, how about "independent functions" for the functions that just do
>calculations, and "environmentally dependent functions" for the functions
>that do IO?
>Then we're still using the word "function" in the C sense.
I believe the term of art to be "pure functions".
'pure'
Many functions have no effects except the return value and their
return value depends only on the parameters and/or global
variables. Such a function can be subject to common subexpression
elimination and loop optimization just as an arithmetic operator
would be. These functions should be declared with the attribute
'pure'. For example,
int square (int) __attribute__ ((pure));
says that the hypothetical function 'square' is safe to call fewer
times than the program says.
Some of common examples of pure functions are 'strlen' or 'memcmp'.
Interesting non-pure functions are functions with infinite loops or
those depending on volatile memory or other system resource, that
may change between two consecutive calls (such as 'feof' in a
multithreading environment).
The attribute 'pure' is not implemented in GCC versions earlier
than 2.96.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-07 14:40 -0400 |
| Message-ID | <r6ihf1$roh$1@dont-email.me> |
| In reply to | #151200 |
On 4/7/20 1:45 PM, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: ... >> OK, how about "independent functions" for the functions that just do >> calculations, and "environmentally dependent functions" for the functions >> that do IO? >> Then we're still using the word "function" in the C sense. > > I believe the term of art to be "pure functions". > > 'pure' > Many functions have no effects except the return value and their > return value depends only on the parameters and/or global > variables. Such a function can be subject to common subexpression > elimination and loop optimization just as an arithmetic operator > would be. These functions should be declared with the attribute > 'pure'. For example, > > int square (int) __attribute__ ((pure)); > > says that the hypothetical function 'square' is safe to call fewer > times than the program says. > > Some of common examples of pure functions are 'strlen' or 'memcmp'. > Interesting non-pure functions are functions with infinite loops or > those depending on volatile memory or other system resource, that > may change between two consecutive calls (such as 'feof' in a > multithreading environment). > > The attribute 'pure' is not implemented in GCC versions earlier > than 2.96. No, in repeated discussions Malcolm has made it abundantly clear that Malcolm-functions are a superset of "pure functions". For instance, rand() qualifies as a Malcolm-function, but is certainly not a pure function. He justifies that distinction by including the program state as one of the inputs to the function, something that no one else does. Note that the definition you quote says that pure functions "have no effects except the return value". rand() changes the state of it's internals, which is an example of the kinds of effects prohibited to pure functions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-07 11:03 -0700 |
| Message-ID | <87r1wzkwb5.fsf@nosuchdomain.example.com> |
| In reply to | #151199 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 7 April 2020 16:42:22 UTC+1, Keith Thompson wrote:
[...]
>> Nope. It's not my job to come up with a word for a concept that
>> you find useful and I don't. It's your job to communicate clearly.
>> If you fail to do so, well, I have a solution for that.
>>
>> I might tentatively suggest that a phrase of the form "<adjective>
>> function", where <adjective> is *not* a technical term defined
>> by the C standard, might suit your purposes. Picking the right
>> adjective is up to you.
>>
> OK, how about "independent functions" for the functions that just do
> calculations, and "environmentally dependent functions" for the functions
> that do IO?
> Then we're still using the word "function" in the C sense.
That's not what "environment" means in C. See section 5 of the
C standard. If you mean I/O, why not just say I/O?
--
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-07 11:14 -0700 |
| Message-ID | <6a5fbe6f-20a8-4aa3-84bf-b07e9c28704d@googlegroups.com> |
| In reply to | #151203 |
On Tuesday, 7 April 2020 19:03:34 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Tuesday, 7 April 2020 16:42:22 UTC+1, Keith Thompson wrote: > [...] > >> Nope. It's not my job to come up with a word for a concept that > >> you find useful and I don't. It's your job to communicate clearly. > >> If you fail to do so, well, I have a solution for that. > >> > >> I might tentatively suggest that a phrase of the form "<adjective> > >> function", where <adjective> is *not* a technical term defined > >> by the C standard, might suit your purposes. Picking the right > >> adjective is up to you. > >> > > OK, how about "independent functions" for the functions that just do > > calculations, and "environmentally dependent functions" for the functions > > that do IO? > > Then we're still using the word "function" in the C sense. > > That's not what "environment" means in C. See section 5 of the > C standard. If you mean I/O, why not just say I/O? > People have been kicking up a fuss about what exactly constitutes "IO". It's anything that isn't a mapping of bits to bits. So writing to volatiles, setting values held outside the program's data store, terminating the program. It's maybe fair to say that this is broader than just "IO", though in the vast majority of case it will be IO that prevents a function from bring just a mapping of bits to bits.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-07 12:19 -0700 |
| Message-ID | <87mu7nksrq.fsf@nosuchdomain.example.com> |
| In reply to | #151204 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 7 April 2020 19:03:34 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> > On Tuesday, 7 April 2020 16:42:22 UTC+1, Keith Thompson wrote:
>> [...]
>> >> Nope. It's not my job to come up with a word for a concept that
>> >> you find useful and I don't. It's your job to communicate clearly.
>> >> If you fail to do so, well, I have a solution for that.
>> >>
>> >> I might tentatively suggest that a phrase of the form "<adjective>
>> >> function", where <adjective> is *not* a technical term defined
>> >> by the C standard, might suit your purposes. Picking the right
>> >> adjective is up to you.
>> >>
>> > OK, how about "independent functions" for the functions that just do
>> > calculations, and "environmentally dependent functions" for the functions
>> > that do IO?
>> > Then we're still using the word "function" in the C sense.
>>
>> That's not what "environment" means in C. See section 5 of the
>> C standard. If you mean I/O, why not just say I/O?
>>
> People have been kicking up a fuss about what exactly constitutes "IO".
> It's anything that isn't a mapping of bits to bits. So writing to
> volatiles, setting values held outside the program's data store,
> terminating the program. It's maybe fair to say that this is broader
> than just "IO", though in the vast majority of case it will be IO
> that prevents a function from bring just a mapping of bits to bits.
That's close to what the standard calls "observable behavior".
See N1570 5.1.2.3p6. See also "side effects", 5.1.2.3p2.
In fact, let me encourage you to consult the standard yourself
rather than relying on others to do it for you.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-07 12:02 +0100 |
| Message-ID | <871roza78f.fsf@bsb.me.uk> |
| In reply to | #151176 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > However I am saying, essentially, that if it does IO, or to meet the > objections, if it does anything other than mapping bit patterns to > bit patterns, then it is not a "function", it's "procedure". I'm > not hung up by the term s"function" and "procedure" but they seem > to me the best words to use, rather than try to invent a word. It's usually better to invent a word than attach a new meaning to an old word. > Well we can always write our functions portably. Our Malcolm functions. > They're not doing > anything other than moving bits about. We can also eliminate all > subroutine calls (except malloc() and family), so we can port it > even to a platform that doesn't have a standard library. And we > can take it out of its context, put it into a test environment, > then put it back. Because it can be made dependency free (or in > reality it depends on other functions, but only on other > functions, which we also take). Can you see how confusing that paragraph is to someone who does not know you mean Malcolm functions? None of these supposed benefits flow from re-purposing the terms. All that does is add to the confusion when you talk about it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-07 06:27 -0700 |
| Message-ID | <1c05dfa4-96f4-4282-b729-f5e26647c48a@googlegroups.com> |
| In reply to | #151176 |
On Tuesday, 7 April 2020 11:16:31 UTC+3, Malcolm McLean wrote: > On Tuesday, 7 April 2020 05:04:13 UTC+1, Öö Tiib wrote: > > On Tuesday, 7 April 2020 05:08:53 UTC+3, Ben Bacarisse wrote: > > > > Function that can not have side effects is important concept since it > > is easy for human to reason about and for compiler to optimize (up > > to executing it at compile time). I am unsure if Malcolm McLean > > talks about introducing such functions into C. He seems to talk > > about procedures that have little difference with what are functions > > of C right now. However about distinction of functional programming > > functions in C many would be happy I guess. > > > The concept of "a fucntion without side effects" or a "pure function" > works well in some other programming languages. And you are right thst > part of what I am trying to do is to get the benefits of such > languages into C. > In "language x" we can often write functions in the form > > output = functioncall(inputa, inputb) > > where functioncall is forbidden from modifying inputa or inputb, > or anything accessed via them, and output can be a complex data > structure. That's not so easy to achieve in C, because it doesn't > have good facilities for returning values through the return type, > and because for efficiency reasons, we often pass modifable > buffers. C has had feature of returning whole structs (for long time) and C compilers optimize away making copies during such returns because of "as-if" rule (also for long time). So that issue is not there. Issues arise from side effects like doing input-output reading and writing externs or volatiles or whatever through pointers and calling non-pure functions. > Also C allows you to pass a modifable pointer to a > variable that mgiht be far out of scope, and it allows globals. > I agree that globals should be avoided where possible, but we've > got to face the fact that the language allows them. > > Therefore, instead of saying that "functions are functions of > their parameters and return value", I say, "functions are functions > of the entire program state at entry, and the entire state at > exit, with no side effects". > > So I'm not imposing a rule on the C programmer like "you can't use > globals" or "all your pointer parameters must be const". Now to > talk of the entire program state might be wild (and really its > just to shut up those who get hung up by the fact that the C > standard uses the term "function" to mean something else). > In fact it's not as bad as that, because most programmers are > sensible. The area of memory affected by the function is closely > and clearly defined. It does not matter since writing "pure" function as opposed to "complicated" or "impure" is not so dead difficult while "procedure" and "function" are indeed confusing as other posters keep telling. Having whole program state as input and output is bad idea since that removes benefit of pure functions to be easy to reason about and to optimize. Something impure might access some state of whole program potentially at same time and then there are no benefits whatsoever or very few. > However I am saying, essentially, that if it does IO, or to meet the > objections, if it does anything other than mapping bit patterns to > bit patterns, then it is not a "function", it's "procedure". I'm > not hung up by the term s"function" and "procedure" but they seem > to me the best words to use, rather than try to invent a word. > > A procedure can call a function, but a function may not call > a procedure. > > Now we separate out the functions from the procedures, and put them > in separate source files. > What are the benefits? > > Well we can always write our functions portably. They're not doing > anything other than moving bits about. We can also eliminate all > subroutine calls (except malloc() and family), so we can port it > even to a platform that doesn't have a standard library. And we > can take it out of its context, put it into a test environment, > then put it back. Because it can be made dependency free (or in > reality it depends on other functions, but only on other > functions, which we also take). In my experience pure functions are already useful in C without any changes into language. The constraints are that parameters are read only, nothing external that isn't passed as parameter is accessed and impure functions are not called. Compiler could just help me a bit to keep track of following those policies and to take a hint of optimization potential of such ... and that is basically it. > Also, it can only fail if it runs out of memory (annoyingly). Which > in many environments is vanishingly unlikely to happen. So we > don't need complex error handling, the only error we need to handle > is the out of memory condition. Nothing so magical can happen. Some things just are bit better but big parts of most useful programs there are would remain impure. So every external input keeps being potentially controversial or nonsensical and every output keeps potentially being failing and therefore majority of error handling will remain there.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web