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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 07:44 -0700 |
| Message-ID | <46b1aa9e-c1ea-42eb-b3f4-c69b452e2301@googlegroups.com> |
| In reply to | #151184 |
On Tuesday, 7 April 2020 14:27:44 UTC+1, Öö Tiib wrote: > > 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. > Exactly. Pure functions are a stricter form of what I am proposing. > > 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. > That's because a "pure function" is an accepted idea which most people have come across and has an agreed term. But the concept of a function doesn't do IO is no more difficult than the concept of a pure function. It's just not in common currency. > > 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. > Certainly globals and writeable pointers are problematic. But remember that whilst if you don't ban globals, some people will misuse them, only very few people will go crazy with them. Very few functions access massive swathes of program state. > > 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. > Certainly I don't want to discourage pure functions. But the constraints mean you can't use the object paradigm, for example, where a struct stores the state of variables that relate to something, and functions manipulate it. > > 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. > As you say, in reality, probably most parts of big programs won't be pure functions. So maybe we need to try something similar, but a bit less restrictive.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-07 08:30 -0700 |
| Message-ID | <da7b2f7b-9bea-4248-a59f-157cae727c8f@googlegroups.com> |
| In reply to | #151185 |
On Tuesday, 7 April 2020 17:44:26 UTC+3, Malcolm McLean wrote: > On Tuesday, 7 April 2020 14:27:44 UTC+1, Öö Tiib wrote: > > > That's because a "pure function" is an accepted idea which most people > have come across and has an agreed term. But the concept of a function > doesn't do IO is no more difficult than the concept of a pure > function. It's just not in common currency. There are reasons to it. > > > 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. > > > Certainly globals and writeable pointers are problematic. But > remember that whilst if you don't ban globals, some people > will misuse them, only very few people will go crazy with > them. Very few functions access massive swathes of program > state. The issue is that the restriction can't be enforced by compiler and so it is not more helpful than just adding comment that /* it is Malcolm's "function" */ altering anything in language does not help. > > > > 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. > > > Certainly I don't want to discourage pure functions. But the constraints > mean you can't use the object paradigm, for example, where a struct > stores the state of variables that relate to something, and functions > manipulate it. Yes but if we change length of one edge of triangle for example then it becomes different triangle, why triangle stops being an object because of that? > > > > 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. > > > As you say, in reality, probably most parts of big programs won't > be pure functions. So maybe we need to try something similar, but > a bit less restrictive. I doubt it. Removing restrictions always remove also the benefits of simplicity of usage and efficiency. Complicated is more fragile than pure. Mutable more fragile than immutable.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 00:27 -0700 |
| Message-ID | <03153fa6-e2b0-4259-a428-1433c9db4e30@googlegroups.com> |
| In reply to | #151166 |
On Tuesday, 7 April 2020 03:08:53 UTC+1, 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. > Who knows. You seem to think that everything worth saying must have been said by someone before. You agree now that a routine that accepts one arrangment of bits in the computers memory on entry and produces another arrangement one exit, such that the arrangement on exit is wholly determined by the arrangment on entry, is a function (of the bits)? You agree that if it produces different arrangments depending on outside circumstances it is not a function (of the bits), and if it produces output then it might be a function, but it is also something else, and that this is a reasonable, normal, natural, proper English use of the term "function"?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-07 12:50 +0100 |
| Message-ID | <87v9mb8qgn.fsf@bsb.me.uk> |
| In reply to | #151174 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 7 April 2020 03:08:53 UTC+1, 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.
>>
> Who knows. You seem to think that everything worth saying must have
> been said by someone before.
What a peculiar thing to say. My job used to involve finding things
that no one else had said before. But it also involved explaining why
these things matter enough to be worth saying. I have not come across
anyone who cares about the specific distinction you are making.
> You agree now that a routine that accepts one arrangment of bits
> in the computers memory on entry and produces another arrangement
> one exit, such that the arrangement on exit is wholly determined
> by the arrangment on entry, is a function (of the bits)?
Yes. But I object to your disingenuous used of "accepts". I see now
why you re-purposed two other terms when you spoke of a function's
inputs and outputs. You have to use some term that paints the code as
"taking" or "accepting" the whole program state. Unfortunately you
picked examples (sqrt this time and sin in 2014) that hide this
important point. Talk about burying the lede.
The way in which C code is usually thought of as analogous to a
mathematical function is not as a function of the whole program store
but as a function of the code's arguments. The next time this crops up,
pick an example Malcolm function that highlights, right away, the fact
that you are not using the analogy with a mathematical function in the
usual way. I suggest something like
int f(void) { static int c; return c++; }
For this to be thought of as a mathematical function -- mapping one set
to another -- the reader will be forced to see you are using the term in
a slightly unusual way.
> You agree
> that if it produces different arrangments depending on outside
> circumstances it is not a function (of the bits),
It is, however, a function the program's state in a sense that is only
slightly more general than yours. In fact, this broader use of function
/is/ widely accepted in computer science. It's how denotational
semantics is done, but it turns your Malcolm procedures into functions
too.
> and if it
> produces output then it might be a function, but it is also something
> else, and that this is a reasonable, normal, natural, proper English
> use of the term "function"?
I can't follow this. We need proper terms to be able to talk these
things.
Malcolm functions (a subset of C functions) are mathematical functions
of the program's bit store. Calling them (and only them) functions in a
C group is going to be confusing.
Malcolm procedures (C functions that are not Malcolm functions) are also
mathematical functions but of the program's state (in the formal
semantics sense).
Neither the C nor the mathematical meaning for "function" differentiates
between Malcolm functions and Malcolm procedures in a way that is
obvious enough that you can use the term without qualification. And the
normal meaning of "procedure" does not make the distinction either as it
is also far too general.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 05:25 -0700 |
| Message-ID | <b16f8a36-2552-4511-b553-806e7df2b63c@googlegroups.com> |
| In reply to | #151180 |
On Tuesday, 7 April 2020 12:50:49 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> > On Tuesday, 7 April 2020 03:08:53 UTC+1, 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.
> >>
> > Who knows. You seem to think that everything worth saying must have
> > been said by someone before.
>
> What a peculiar thing to say. My job used to involve finding things
> that no one else had said before. But it also involved explaining why
> these things matter enough to be worth saying. I have not come across
> anyone who cares about the specific distinction you are making.
>
You seem to imply that you'd be interested if I can produce a list
of references, not otherwise. Thus if an only if the idea has been
discussed by other people. i agree that trying to find out if anyone
has done anything related would be useful and might point us in
fruitful directions and close of blind alleys. Maybe even come up
with some accepted terminology.
But that can't be the litmus test of what is and what is not worth
discussing.
I have looked up some work on functional programming, but whilst it's
in the same general area, it's not really the same.
>
> > You agree now that a routine that accepts one arrangment of bits
> > in the computers memory on entry and produces another arrangement
> > one exit, such that the arrangement on exit is wholly determined
> > by the arrangment on entry, is a function (of the bits)?
>
> Yes. But I object to your disingenuous used of "accepts". I see now
> why you re-purposed two other terms when you spoke of a function's
> inputs and outputs. You have to use some term that paints the code as
> "taking" or "accepting" the whole program state. Unfortunately you
> picked examples (sqrt this time and sin in 2014) that hide this
> important point. Talk about burying the lede.
>
Yes, "accepts" isn't really the right term. The data store is in one
state on function entry, in another state on function exit. The state
on exit is wholly determined by the state on entry, and we can replace
the function by any other code that performs the same transformation
without affecting the correctness of the program.
sqrt() isn't a pure function, by the way. It sets errno if the argument
is negative.
>
> The way in which C code is usually thought of as analogous to a
> mathematical function is not as a function of the whole program store
> but as a function of the code's arguments. The next time this crops up,
> pick an example Malcolm function that highlights, right away, the fact
> that you are not using the analogy with a mathematical function in the
> usual way. I suggest something like
>
> int f(void) { static int c; return c++; }
>
> For this to be thought of as a mathematical function -- mapping one set
> to another -- the reader will be forced to see you are using the term in
> a slightly unusual way.
>
The code has to be correct C, so you would need to initialise c.
But yes, this is an example. However it's not a normal example.
Global variables are rare, and functions that have static state
are rarer still.
However that doesn't break the characteristics I wish to preserve.
>
> > You agree
> > that if it produces different arrangments depending on outside
> > circumstances it is not a function (of the bits),
>
> It is, however, a function the program's state in a sense that is only
> slightly more general than yours. In fact, this broader use of function
> /is/ widely accepted in computer science. It's how denotational
> semantics is done, but it turns your Malcolm procedures into functions
> too.
>
But it's not. Consider
int foo(FILE *fp)
{
static int last = EOF;
int answer = last;
last = fgetc(fp);
return answer;
}
state on function exit is not determined by the state of the program,
but by the state of whatever is attached to our file stream. It might
well be the case that "last" is set to 0 if we leave the computer as it
is, to EOF if we pull the cable attaching the disk drive out.
>
> > and if it
> > produces output then it might be a function, but it is also something
> > else, and that this is a reasonable, normal, natural, proper English
> > use of the term "function"?
>
> I can't follow this. We need proper terms to be able to talk these
> things.
>
> Malcolm functions (a subset of C functions) are mathematical functions
> of the program's bit store. Calling them (and only them) functions in a
> C group is going to be confusing.
>
> Malcolm procedures (C functions that are not Malcolm functions) are also
> mathematical functions but of the program's state (in the formal
> semantics sense).
>
> Neither the C nor the mathematical meaning for "function" differentiates
> between Malcolm functions and Malcolm procedures in a way that is
> obvious enough that you can use the term without qualification. And the
> normal meaning of "procedure" does not make the distinction either as it
> is also far too general.
>
You might be right here. I'm willing to change the terminology. But
the challenge to Keith Thompson was unmet.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-07 23:52 +0100 |
| Message-ID | <87k12q9ae7.fsf@bsb.me.uk> |
| In reply to | #151181 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 7 April 2020 12:50:49 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> > On Tuesday, 7 April 2020 03:08:53 UTC+1, 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.
>> >>
>> > Who knows. You seem to think that everything worth saying must have
>> > been said by someone before.
>>
>> What a peculiar thing to say. My job used to involve finding things
>> that no one else had said before. But it also involved explaining why
>> these things matter enough to be worth saying. I have not come across
>> anyone who cares about the specific distinction you are making.
>>
> You seem to imply that you'd be interested if I can produce a list
> of references, not otherwise.
I was, I thought, quite explicit: the references would be interesting
because you have not been prepared to answer my questions. Maybe
someone else's explanation would make things clearer.
> I have looked up some work on functional programming, but whilst it's
> in the same general area, it's not really the same.
Did you find:
Simon Peyton Jones, "Tackling the Awkward Squad: monadic input/output,
concurrency, exceptions, and foreign-language calls in Haskell",
Microsoft Research, Cambridge, 2010.
<cut>
> sqrt() isn't a pure function, by the way. It sets errno if the argument
> is negative.
It may do, but not necessarily. An exception might be raised instead or
as well. Obviously that, too, makes it not a pure function. At first
glance, that stops is being even a Malcolm function. Does it?
>> The way in which C code is usually thought of as analogous to a
>> mathematical function is not as a function of the whole program store
>> but as a function of the code's arguments. The next time this crops up,
>> pick an example Malcolm function that highlights, right away, the fact
>> that you are not using the analogy with a mathematical function in the
>> usual way. I suggest something like
>>
>> int f(void) { static int c; return c++; }
>>
>> For this to be thought of as a mathematical function -- mapping one set
>> to another -- the reader will be forced to see you are using the term in
>> a slightly unusual way.
>>
> The code has to be correct C, so you would need to initialise c.env
Eh?
> But yes, this is an example. However it's not a normal example.
> Global variables are rare, and functions that have static state
> are rarer still.
Yes, that's exactly why it's a good example. I shows that you don't
mean "this code is like a mathematical function" in any of the normal
senses. The more exceptional the example, the more usefully it
illustrates your odd point of view. Look at all the posts people have
made suggesting you probably mean something like a "pure function". Had
you given this example, you'd have stacked out the ground covered by
Malcolm functions much more quickly.
> However that doesn't break the characteristics I wish to preserve.
>>
>> > You agree
>> > that if it produces different arrangments depending on outside
>> > circumstances it is not a function (of the bits),
>>
>> It is, however, a function the program's state in a sense that is only
>> slightly more general than yours. In fact, this broader use of function
>> /is/ widely accepted in computer science. It's how denotational
>> semantics is done, but it turns your Malcolm procedures into functions
>> too.
>>
> But it's not. Consider
>
> int foo(FILE *fp)
> {
> static int last = EOF;
> int answer = last;
> last = fgetc(fp);
> return answer;
> }
>
> state on function exit is not determined by the state of the program,
> but by the state of whatever is attached to our file stream.
That's right. Maybe I exaggerated when I said "slightly more general".
The semantics of some code is defined in terms of functions of the
program's execution state -- defined to include anything that impinges
on the code's meaning.
> It might
> well be the case that "last" is set to 0 if we leave the computer as it
> is, to EOF if we pull the cable attaching the disk drive out.
Generally, there is no need to include "drive present/removed" in the
state because a language's IO interface will abstract out such details.
But you can add as much of the gory details as you want.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 03:15 -0700 |
| Message-ID | <bbe001cb-55be-40c7-bfc0-22731a0b93b9@googlegroups.com> |
| In reply to | #151214 |
On Tuesday, 7 April 2020 23:52:27 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > I was, I thought, quite explicit: the references would be interesting > because you have not been prepared to answer my questions. Maybe > someone else's explanation would make things clearer. > > > I have looked up some work on functional programming, but whilst it's > > in the same general area, it's not really the same. > > Did you find: > > Simon Peyton Jones, "Tackling the Awkward Squad: monadic input/output, > concurrency, exceptions, and foreign-language calls in Haskell", > Microsoft Research, Cambridge, 2010. > Thanks for the reference. Stage one is to define the difference between "Malcolm functions" and "Malcolm procedures". Stage two is to say "separate out your Malcolm functions from your Malcolm procedures". State three is to say "convert as much code as possible from Malcolm procedures to Malcolm functions". That's where monads potentially come in. > <cut> > > sqrt() isn't a pure function, by the way. It sets errno if the argument > > is negative. > > It may do, but not necessarily. An exception might be raised instead or > as well. Obviously that, too, makes it not a pure function. At first > glance, that stops is being even a Malcolm function. Does it? > Ideally I'd like to say that "for every possible arangment of bits on fucntion entry, there is one and one only arrangement of bits on function exit". Unfortunately C has undefined behaviour, and it's impossible to demand that functions be written to avoid any undefined behaviour because then you'd have to ban pointer parameters. Also it's not so useful, because in fact if the input bits aren't in the domain of the human-meaningful function you are trying to model, then it's not necessary to have them in the domain of the computer function. But if you deliberately and explictly raise a signal, it's not a Malcolm function. Malcolm functions either map bits to bits and do nothing else, or they have undefined behaviour. > > > But yes, this is an example. However it's not a normal example. > > Global variables are rare, and functions that have static state > > are rarer still. > > Yes, that's exactly why it's a good example. I shows that you don't > mean "this code is like a mathematical function" in any of the normal > senses. The more exceptional the example, the more usefully it > illustrates your odd point of view. Look at all the posts people have > made suggesting you probably mean something like a "pure function". Had > you given this example, you'd have stacked out the ground covered by > Malcolm functions much more quickly. > You might be write. One concern was that it sounds like I'm saying "I encourage globals and static state". In fact I'm just allowing it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-08 21:28 +0100 |
| Message-ID | <87r1wx7mdb.fsf@bsb.me.uk> |
| In reply to | #151229 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 7 April 2020 23:52:27 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> I was, I thought, quite explicit: the references would be interesting >> because you have not been prepared to answer my questions. Maybe >> someone else's explanation would make things clearer. >> >> > I have looked up some work on functional programming, but whilst it's >> > in the same general area, it's not really the same. >> >> Did you find: >> >> Simon Peyton Jones, "Tackling the Awkward Squad: monadic input/output, >> concurrency, exceptions, and foreign-language calls in Haskell", >> Microsoft Research, Cambridge, 2010. >> > Thanks for the reference. > > Stage one is to define the difference between "Malcolm functions" > and "Malcolm procedures". You have has a few gos. One is based on what the function does (IO or no IO) which is not a property of the code, but of the call. Another is whether it can or can not (in principle) be implemented in standard C without calling any library functions. This has the advantage of actually being a property of the code itself. > Stage two is to say "separate out your Malcolm functions from your > Malcolm procedures". But only if you have this particular bee in your bonnet. Otherwise, just keep calm and carry on. > [Stage] three is to say "convert as much code as possible from Malcolm > procedures to Malcolm functions". That's where monads potentially come > in. I don't get this. C has no monads and I can't fit the distinction you are making into any language that has monads. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 15:40 -0700 |
| Message-ID | <2f10b713-3817-420e-a62a-27fea1cf3e8e@googlegroups.com> |
| In reply to | #151240 |
On Wednesday, 8 April 2020 21:28:59 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > > > Stage one is to define the difference between "Malcolm functions" > > and "Malcolm procedures". > > You have has a few gos. One is based on what the function does (IO or > no IO) which is not a property of the code, but of the call. Another is > whether it can or can not (in principle) be implemented in standard C > without calling any library functions. This has the advantage of > actually being a property of the code itself. > One's a definition, a mapping of bits to bit and nothing else. The other is a property which flows from the definition. But if a property holds can then use it in an alternative definition if you wish. > > > [Stage] three is to say "convert as much code as possible from Malcolm > > procedures to Malcolm functions". That's where monads potentially come > > in. > > I don't get this. C has no monads and I can't fit the distinction you > are making into any language that has monads. > Haskell needs monads because of "lazy evaluation". Essentially you compose a function, then evaluate it only when you need the result. Which means you can't attach an IO action to an expression. In C we have a = fgetc(fp); b = fgetc(fp); return b - a; so a will always be the character in the stream preceding b. However if you have lazy evaluation, this is recast as return "fgetc(fp) - fgetc(fp)" I'm not quite sure at which point the expression collapses into a single integer. But we've reversed a and b and it's no good. Now you've got a similar issue with Malcolm functions. They're not "lazy" - bits on entry and bits on exit must be in their positions on function entry and function exit, we don't wait until they are read to set them to required values. But you've got a similar problem that the function has to be replaceable by another function that performs the same mapping. Intermediate bit states between function entry and function exit don't matter. So we have no way of expressing "write a to a port, wait a while for it to clear, then write b to the same port". Maybe it's time to start talking about function pointers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-09 00:31 +0100 |
| Message-ID | <87d08h7dws.fsf@bsb.me.uk> |
| In reply to | #151242 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Wednesday, 8 April 2020 21:28:59 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> >
>> > Stage one is to define the difference between "Malcolm functions"
>> > and "Malcolm procedures".
>>
>> You have has a few gos. One is based on what the function does (IO or
>> no IO) which is not a property of the code, but of the call. Another is
>> whether it can or can not (in principle) be implemented in standard C
>> without calling any library functions. This has the advantage of
>> actually being a property of the code itself.
>>
> One's a definition, a mapping of bits to bit and nothing else. The other
> is a property which flows from the definition. But if a property holds
> can then use it in an alternative definition if you wish.
I don't wish to use any definition of Malcolm functions! I have no idea
why you care about this so much. I can't even tell if the property is
supposed to one attached to a piece of code, or to a call to that piece
of code. Is
function comp(f, g) { return x => f(g(x)) }
(ECMAScript) a Malcolm function? I think I first asked six years ago.
>> > [Stage] three is to say "convert as much code as possible from Malcolm
>> > procedures to Malcolm functions". That's where monads potentially come
>> > in.
>>
>> I don't get this. C has no monads and I can't fit the distinction you
>> are making into any language that has monads.
>>
> Haskell needs monads because of "lazy evaluation".
No.
> Essentially you
> compose a function, then evaluate it only when you need the result.
> Which means you can't attach an IO action to an expression.
I don't know where to start with that. Another "no" will have to do.
> In C we have
> a = fgetc(fp);
> b = fgetc(fp);
> return b - a;
>
> so a will always be the character in the stream preceding b. However
> if you have lazy evaluation, this is recast as
>
> return "fgetc(fp) - fgetc(fp)"
>
> I'm not quite sure at which point the expression collapses into
> a single integer. But we've reversed a and b and it's no good.
What are you talking about? What do you mean "this is recast as"? Who
does this recasting, and why is this recasting linked to lazy
evaluation? If it's incorrect to recast it like this in a lazy language
like Haskell, it could be just as incorrect in C or in ML.
But the immediate problem is that
return "fgetc(fp) - fgetc(fp)"
is written in a language who semantics I don't know. What do the quotes
mean? Until I know, I can't even know that this recasting is
incorrect. Maybe this line is that same as the original C snippet.
> Now you've got a similar issue with Malcolm functions. They're not
> "lazy" - bits on entry and bits on exit must be in their positions
> on function entry and function exit, we don't wait until they
> are read to set them to required values. But you've got a similar
> problem that the function has to be replaceable by another function
> that performs the same mapping. Intermediate bit states between
> function entry and function exit don't matter. So we have no
> way of expressing "write a to a port, wait a while for it to
> clear, then write b to the same port".
>
> Maybe it's time to start talking about function pointers.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2020-04-07 21:40 +0000 |
| Message-ID | <slrn3md8r8psqv.s9g.ike@sdf.lonestar.org> |
| In reply to | #151174 |
On 2020-04-07, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > You agree now that a routine that accepts one arrangment of bits > in the computers memory on entry and produces another arrangement > one exit, such that the arrangement on exit is wholly determined > by the arrangment on entry, is a function (of the bits)? You agree > that if it produces different arrangments depending on outside > circumstances it is not a function (of the bits), and if it > produces output then it might be a function, but it is also something > else, and that this is a reasonable, normal, natural, proper English > use of the term "function"? Take for instance the Unix system that I'm currently using to type this post. It has a filesystem type called tmpfs, which is a filesystem that resides entirely in the computer's memory. A function that reads from a file in such a tmpfs filesystem (i.e. a function that performs i/o) effectively gets its data from the computer's memory because that's where the file resides. A function that "accepts one arrangement of bits in the computer's memory" also effectively gets its data from the computer's memory. Both functions do the same thing: using data from the computer's memory. Why make an artificial distinction between such functions?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-04-06 09:41 -0700 |
| Message-ID | <c8cb7b32-e021-4831-b520-8882f397bded@googlegroups.com> |
| In reply to | #151127 |
On Monday, April 6, 2020 at 5:56:39 AM UTC-5, Malcolm McLean wrote: > 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. > Begging the question. To prove that function/procedure is a useful distinction, you cannot start by assuming that it is true.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-06 12:46 -0700 |
| Message-ID | <87a73oo0rr.fsf@nosuchdomain.example.com> |
| In reply to | #151119 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> 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.
We are not unable. We are unwilling.
--
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 | Guillaume <message@bottle.org> |
|---|---|
| Date | 2020-04-07 17:17 +0200 |
| Message-ID | <r6i5he$3fp$1@gioia.aioe.org> |
| In reply to | #151119 |
Le 06/04/2020 à 11:25, Malcolm McLean a écrit :
> 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.
Agreed.
I think a typical way of implementing a rand-like function in a typical
"functional" language would be with a "closure" (although some may argue
that closures are monsters that shouldn't belong to functional
languages, so YMMV.)
Of course you don't need closures if you change the "interface" of the
function. In a "functional" way, you could write it passing around an
object (or tuple) containing any of the parameters needed for
calculating the next value.
A function without parameters is not really a function strictly speaking
anyway. (I mean in the general sense of course, C functions are just a
combination of "procedures" and "functions".)
A pure functional (IMO) way of implementing a random generator in C
would be like so (using a simple generator for illustration):
typedef struct { unsigned int w; unsigned int z; unsigned int rand; }
rand_t;
rand_t Rand_Seed(unsigned int w0, unsigned int z0)
{
return (rand_t){ .w = w0, .z = z0 };
}
rand_t Rand_Next(rand_t R)
{
R.w = 18000 * (R.w % 65536) + (R.w / 65536);
R.z = 36969 * (R.z % 65536) + (R.z / 65536);
return (rand_t){ .w = R.w, .z = R.z, .rand = R.z * 65536 + R.w };
}
A simple use example:
int main(void)
{
rand_t R = Rand_Seed(521288629, 362436069);
for (int i = 0; i < 100; i++)
{
R = Rand_Next(R);
printf("%u\n", R.rand);
}
}
Passing around the state instead of storing it statically somewhere
makes it a pure functional approach IMO.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-09 07:23 -0700 |
| Message-ID | <868sj4n3ey.fsf@linuxsc.com> |
| In reply to | #151187 |
Guillaume <message@bottle.org> writes: > Le 06/04/2020 at 11:25, Malcolm McLean a ecrit: > >> 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. > > Agreed. > > I think a typical way of implementing a rand-like function in a > typical "functional" language would be with a "closure" (although some > may argue that closures are monsters that shouldn't belong to > functional languages, so YMMV.) It's hard to imagine any serious functional programming without closures. Were you perhaps thinking of continuations?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-04 22:32 +0100 |
| Message-ID | <87a73rc4xl.fsf@bsb.me.uk> |
| In reply to | #151012 |
David Brown <david.brown@hesbynett.no> writes: > 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. Yes, exactly. I knew what was probably meant, but given the context, it seemed likely that Malcolm was winding people up by using "input" and "output" to mean something other than IO. Maybe he wasn't, but I replied to what was written in order to make the point. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-03 21:59 +0200 |
| Message-ID | <r684ju$hok$1@dont-email.me> |
| In reply to | #150984 |
On 03/04/2020 19:05, Bart wrote: > On 03/04/2020 16:34, David Brown wrote: >> On 03/04/2020 17:03, already5chosen@yahoo.com wrote: > >>> The point is *not* to correct any specific mistake of Malcolm McLean> >>> but to persuade him to stop taking part in discussions in-between >>> High Priesthood. Which I consider not a bad advice. >>> >> >> It is good advice for most people not to get involved in some of these >> discussions about the small details in the wording of the standards - >> the details are not easy to get right, and their influence in >> real-world practical programming is usually very small. (It can, >> however, be useful for the rest of us that /someone/ has read and >> understood them.) > > Or, possibly, not understand them. > > It's useful to know that even 'high priests' can't agree about some of > that stuff. > Agreed. It can be useful to know that some points in the standards may not have a single universally agreed interpretation. (I know that the people who know more details of the C standards than others in this group don't like to be thought of as "High priests" - the phrase has less flattering implications. I prefer to think of them as knowledgeable people who are happy to share that knowledge.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-03 23:48 -0400 |
| Message-ID | <r6902g$bl6$1@dont-email.me> |
| In reply to | #150994 |
On 4/3/20 3:59 PM, David Brown wrote: ... > (I know that the people who know more details of the C standards than > others in this group don't like to be thought of as "High priests" - the > phrase has less flattering implications. I prefer to think of them as > knowledgeable people who are happy to share that knowledge.) The phrase "High Priests" carries the implication that we claim authority based upon divine endorsement. As someone who doesn't even believe in Divinities, I find the suggestion that I'm making such a claim quite disgusting. What I say is true, if it is true, only because (and therefore, only insofar as) it accurately reflects what the standard says. And the standard doesn't have authority because it is a infallible Holy Book containing the word of God. It is a somewhat fallible document that has authority only because fallible human beings created ISO and gave ISO the authority to create international standards, and ISO in turn gave the fallible committee the authority to produce an international C standard.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2020-04-04 09:00 +0000 |
| Subject | Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <r69ib5$pq4$1@news.xmission.com> |
| In reply to | #151003 |
In article <r6902g$bl6$1@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> babbled: ... >The phrase "High Priests" carries the implication that we claim >authority based upon divine endorsement. As someone who doesn't even >believe in Divinities, I find the suggestion that I'm making such a >claim quite disgusting. What I say is true, if it is true, only because >(and therefore, only insofar as) it accurately reflects what the >standard says. And the standard doesn't have authority because it is a >infallible Holy Book containing the word of God. It is a somewhat >fallible document that has authority only because fallible human beings >created ISO and gave ISO the authority to create international >standards, and ISO in turn gave the fallible committee the authority to >produce an international C standard. Yes, Jared would be proud of your ability to utter zillions of words and say absolutely nothing. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/BestCLCPostEver
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 02:45 -0700 |
| Subject | Re: Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <4081ce0c-e0fb-4ada-b8b1-4fb97a1db723@googlegroups.com> |
| In reply to | #151006 |
On Saturday, 4 April 2020 10:00:30 UTC+1, Kenny McCormack wrote: > In article <r6902g$bl6$1@dont-email.me>, > James Kuyper <jameskuyper@alumni.caltech.edu> babbled: > ... > >The phrase "High Priests" carries the implication that we claim > >authority based upon divine endorsement. As someone who doesn't even > >believe in Divinities, I find the suggestion that I'm making such a > >claim quite disgusting. What I say is true, if it is true, only because > >(and therefore, only insofar as) it accurately reflects what the > >standard says. And the standard doesn't have authority because it is a > >infallible Holy Book containing the word of God. It is a somewhat > >fallible document that has authority only because fallible human beings > >created ISO and gave ISO the authority to create international > >standards, and ISO in turn gave the fallible committee the authority to > >produce an international C standard. > > Yes, Jared would be proud of your ability to utter zillions of words and > say absolutely nothing. > It's a rather literal interpretation of a metaphor.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web