Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90419 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-15 23:36 +0200 |
| Last post | 2016-08-02 13:20 -0700 |
| Articles | 20 on this page of 164 — 22 participants |
Back to article view | Back to comp.lang.c
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-19 08:43 -0700 |
| Message-ID | <a4c12857-4e37-4601-a225-28c9fe82ee11@googlegroups.com> |
| In reply to | #90588 |
On Tuesday, July 19, 2016 at 4:27:41 PM UTC+1, Bart wrote: > On 19/07/2016 15:27, Malcolm McLean wrote: > > It just goes on and on. On the one hand it inveigles you in with a > minimalist language that can be described in one page, on the other it > needs a 1000-page reference manual. It's a monster of a language that > can apparently do everything, and better than any other language in > every single way! > Let's see if Ben rises to the Worley noise challenge.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 19:14 +0100 |
| Message-ID | <87shv5cx77.fsf@bsb.me.uk> |
| In reply to | #90590 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, July 19, 2016 at 4:27:41 PM UTC+1, Bart wrote: >> On 19/07/2016 15:27, Malcolm McLean wrote: >> >> It just goes on and on. On the one hand it inveigles you in with a >> minimalist language that can be described in one page, on the other it >> needs a 1000-page reference manual. It's a monster of a language that >> can apparently do everything, and better than any other language in >> every single way! >> > Let's see if Ben rises to the Worley noise challenge. Eh? You mean all the code had a point? What was it? It certainly was not an answer to my question. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-07-18 10:08 +0200 |
| Message-ID | <871t2rid0t.fsf@news.bourguet.org> |
| In reply to | #90478 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 17/07/2016 à 19:43, Udyant Wig a écrit : >> And many times obtain a gain in productivity and readability, while >> obviating having to deal with a complex syntax and the associated >> cognitive load. > > At school we learned how to read > > a+(b-5)/(c+47) > > Now... > > (/ (+ a (- b 5)) (+ c 47)) > > That obviously doesn't require any cognitive load to lisp heads of course. > > Other guys... well YMMV. There have been enough Lisp dialects allowing to write infix notations that if the prefix notation was a burden one that possibility would have spread out to other variants. (As a matter of fact, I had to check the infix version to be sure that it wasn't corresponding to the prefix one, I never had any doubt about the meaning of the prefix version and I mainly program in languages using infix notations for expressions). Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 23:04 +0530 |
| Message-ID | <nmj3vm$24e$1@dont-email.me> |
| In reply to | #90499 |
On 07/18/2016 01:38 PM, Jean-Marc Bourguet wrote: > There have been enough Lisp dialects allowing to write infix notations > that if the prefix notation was a burden one that possibility would > have spread out to other variants. Just to be sure, Common Lisp is a programming language that can be programmed. So, you can program it to read infix, even if it gets converted to some other form for internal use. > (As a matter of fact, I had to check the infix version to be sure that it > wasn't corresponding to the prefix one, I never had any doubt about the > meaning of the prefix version and I mainly program in languages using infix > notations for expressions). This is good to know. Like languages, notations can be learned as well. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-16 10:18 +0100 |
| Message-ID | <87h9bqlz57.fsf@bsb.me.uk> |
| In reply to | #90431 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 16/07/2016 à 00:27, Ben Bacarisse a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> <snip> >>> .... Object oriented programming is >>> no longer "en vogue" and the fad went for templates, now lambdas, and >>> tomorrow whatever computer science students learn at the university, >>> where those fads are fabricated. >> >> Lambdas date from the 1930s. There were amongst the very first concepts >> to be implemented in a programming language (in the 1950s). They are a >> very long-lived fad. >> > > Lambda Calculus dates from 1930s. There was no lisp then. You saw that's what I said, yes? >> But they become important when you provide high-level operations like >> mapping and folding over a sequence. Presumably your C containers have >> map, filter and fold (sometimes called reduce) operations on its >> sequences. Without lambdas, you have write a named top-level function >> and arrange a convention for any user data to be passed in (usually an >> extra void *). It's the ability to simplify this "capturing" of data >> that makes them useful. The fact that they are unnamed (which is what >> the lambda part is about) is less important. >> >> <snip> >> > > Any construct can be useful in some circumstances. So you start piling > up features and constructs without any consideration for the resulting > language and you obtain... > > EUREKA! > > You obtain C++, a language overgrown to the excess, dying of obesity. You've added features to C to make your language. You can't argue against every feature or construct based on the argument that it is the route to obesity or there would be nothing but a couple of minimal programming languages out there. The question is what is worth having and what isn't worth having. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-23 19:26 +0000 |
| Message-ID | <5793c3cb.1636046@news.xs4all.nl> |
| In reply to | #90423 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > <snip> > > .... Object oriented programming is > > no longer "en vogue" and the fad went for templates, now lambdas, and > > tomorrow whatever computer science students learn at the university, > > where those fads are fabricated. > > Lambdas date from the 1930s. There were amongst the very first concepts > to be implemented in a programming language (in the 1950s). They are a > very long-lived fad. No, they're not. They're a long-lived concept. But jacob is right in this, that they've semi-recently started to be pushed as the Latest New Thing (or maybe by now the Second-Latest New Thing) which was going to revolutionise programming. I never pay attention to these things so I can't tell you where, but I _have_ found myself going "what, lambdas _again_? *flip*". I have no problem with lambdas. I don't see myself using them much, ever, but lambdas are fine where they're the appropriate solution. Which, AFAICT, is algorithm research, BICBW - it's not day-to-day programming for me, that's certain. What I _do_ have a problem with, though, is programming fads, and lambdas have become one of them. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-25 09:21 -0700 |
| Message-ID | <kfn8twpsn76.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90858 |
raltbos@xs4all.nl (Richard Bos) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> <snip> >>> .... Object oriented programming is >>> no longer "en vogue" and the fad went for templates, now lambdas, and >>> tomorrow whatever computer science students learn at the university, >>> where those fads are fabricated. >> >> Lambdas date from the 1930s. There were amongst the very first concepts >> to be implemented in a programming language (in the 1950s). They are a >> very long-lived fad. > > No, they're not. They're a long-lived concept. But jacob is right in > this, that they've semi-recently started to be pushed as the Latest New > Thing (or maybe by now the Second-Latest New Thing) which was going to > revolutionise programming. I never pay attention to these things so I > can't tell you where, but I _have_ found myself going "what, lambdas > _again_? *flip*". > I have no problem with lambdas. I don't see myself using them much, > ever, but lambdas are fine where they're the appropriate solution. > Which, AFAICT, is algorithm research, BICBW - it's not day-to-day > programming for me, that's certain. What I _do_ have a problem with, > though, is programming fads, and lambdas have become one of them. I think there was a time when I would have agreed with this viewpoint. Now I have a different perspective, and would like to present that. First, a note on terminology. The key underlying mechanism is closures. Closures can be implemented by way of named, nested functions (which gcc does as an extension), or by anonymous "in-place" function bodies (which often are called lambdas). IMO anonymous closures (aka lambdas) are significantly more convenient than just having nested function definitions, but the difference between those is one of syntactic sugar (rather rich sugar perhaps, but still just a syntactic convenience). Let me use the word closure to refer to the basic underlying mechanism, without regard to whether the nested function bodies are named or anonymous. Closures are significant because they enable control abstraction, which is remarkably powerful. It is difficult to realize the full potential of closures in a language like C, because it does not provide automatic storage reclamation, and because C's type system isn't rich enough to provide parametric polymorphism. Despite that, closures offer a substantial benefit even when restricted by those limitations. Readers may remember that Pascal allowed nested function definitions, which provide (IIANM) the same limited closure capabilities that gcc nested functions do. I believe closures (and lambdas) are becoming more common in imperative/procedural languages, such as C, due to a growing awareness in the hinterlands of the value they bring to writing real programs. Closures/lambdas aren't important because they are becoming popular; they are becoming popular because they are important. I guess I should end with an offer to respond to a skeptical followup regarding the views just presented. If someone has a question about closures/lambdas, and topical in CLC, please feel free to followup and ask it.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-25 10:19 -0700 |
| Message-ID | <65b61a13-a54c-4ade-9168-4d71de86103f@googlegroups.com> |
| In reply to | #91021 |
On Monday, July 25, 2016 at 11:21:43 AM UTC-5, Tim Rentsch wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > > >> jacobnavia <jacob@jacob.remcomp.fr> writes: > >> <snip> > >>> .... Object oriented programming is > >>> no longer "en vogue" and the fad went for templates, now lambdas, and > >>> tomorrow whatever computer science students learn at the university, > >>> where those fads are fabricated. > >> > >> Lambdas date from the 1930s. There were amongst the very first concepts > >> to be implemented in a programming language (in the 1950s). They are a > >> very long-lived fad. > > > > No, they're not. They're a long-lived concept. But jacob is right in > > this, that they've semi-recently started to be pushed as the Latest New > > Thing (or maybe by now the Second-Latest New Thing) which was going to > > revolutionise programming. I never pay attention to these things so I > > can't tell you where, but I _have_ found myself going "what, lambdas > > _again_? *flip*". > > I have no problem with lambdas. I don't see myself using them much, > > ever, but lambdas are fine where they're the appropriate solution. > > Which, AFAICT, is algorithm research, BICBW - it's not day-to-day > > programming for me, that's certain. What I _do_ have a problem with, > > though, is programming fads, and lambdas have become one of them. > > I think there was a time when I would have agreed with this > viewpoint. Now I have a different perspective, and would like to > present that. > > First, a note on terminology. The key underlying mechanism is > closures. Closures can be implemented by way of named, nested > functions (which gcc does as an extension), or by anonymous > "in-place" function bodies (which often are called lambdas). > IMO anonymous closures (aka lambdas) are significantly more > convenient than just having nested function definitions, but > the difference between those is one of syntactic sugar (rather > rich sugar perhaps, but still just a syntactic convenience). > Let me use the word closure to refer to the basic underlying > mechanism, without regard to whether the nested function bodies > are named or anonymous. > > Closures are significant because they enable control abstraction, > which is remarkably powerful. It is difficult to realize the > full potential of closures in a language like C, because it does > not provide automatic storage reclamation, and because C's type > system isn't rich enough to provide parametric polymorphism. > Despite that, closures offer a substantial benefit even when > restricted by those limitations. Readers may remember that > Pascal allowed nested function definitions, which provide (IIANM) > the same limited closure capabilities that gcc nested functions > do. > > I believe closures (and lambdas) are becoming more common in > imperative/procedural languages, such as C, due to a growing > awareness in the hinterlands of the value they bring to writing > real programs. Closures/lambdas aren't important because they > are becoming popular; they are becoming popular because they > are important. > > I guess I should end with an offer to respond to a skeptical > followup regarding the views just presented. If someone has > a question about closures/lambdas, and topical in CLC, please > feel free to followup and ask it. I've been able to treat function bodies somewhat successfully as anonymous objects by putting them in my X-macros and generating names automatically. But the missing piece for closures in C seems to me to be the "currying" or partial capture of arguments. One possible means might be define a correspondence between a function's argument list and an implicitly-created "argument struct" type which can represent the captured values. It seems it would also need some kind "mask" component to designate which arguments are still pending. I'm not clearly conceiving the gymnastics to do this with user code (even with macros), but this kind of thing doesn't seem impossible for C31.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-28 10:31 -0700 |
| Message-ID | <kfnbn1hpt3p.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91036 |
luser droog <luser.droog@gmail.com> writes:
> On Monday, July 25, 2016 at 11:21:43 AM UTC-5, Tim Rentsch wrote:
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>> <snip>
>>>>> .... Object oriented programming is
>>>>> no longer "en vogue" and the fad went for templates, now lambdas, and
>>>>> tomorrow whatever computer science students learn at the university,
>>>>> where those fads are fabricated.
>>>>
>>>> Lambdas date from the 1930s. There were amongst the very first concepts
>>>> to be implemented in a programming language (in the 1950s). They are a
>>>> very long-lived fad.
>>>
>>> No, they're not. They're a long-lived concept. But jacob is right in
>>> this, that they've semi-recently started to be pushed as the Latest New
>>> Thing (or maybe by now the Second-Latest New Thing) which was going to
>>> revolutionise programming. I never pay attention to these things so I
>>> can't tell you where, but I _have_ found myself going "what, lambdas
>>> _again_? *flip*".
>>> I have no problem with lambdas. I don't see myself using them much,
>>> ever, but lambdas are fine where they're the appropriate solution.
>>> Which, AFAICT, is algorithm research, BICBW - it's not day-to-day
>>> programming for me, that's certain. What I _do_ have a problem with,
>>> though, is programming fads, and lambdas have become one of them.
>>
>> I think there was a time when I would have agreed with this
>> viewpoint. Now I have a different perspective, and would like to
>> present that.
>>
>> First, a note on terminology. The key underlying mechanism is
>> closures. Closures can be implemented by way of named, nested
>> functions (which gcc does as an extension), or by anonymous
>> "in-place" function bodies (which often are called lambdas).
>> IMO anonymous closures (aka lambdas) are significantly more
>> convenient than just having nested function definitions, but
>> the difference between those is one of syntactic sugar (rather
>> rich sugar perhaps, but still just a syntactic convenience).
>> Let me use the word closure to refer to the basic underlying
>> mechanism, without regard to whether the nested function bodies
>> are named or anonymous.
>>
>> Closures are significant because they enable control abstraction,
>> which is remarkably powerful. It is difficult to realize the
>> full potential of closures in a language like C, because it does
>> not provide automatic storage reclamation, and because C's type
>> system isn't rich enough to provide parametric polymorphism.
>> Despite that, closures offer a substantial benefit even when
>> restricted by those limitations. Readers may remember that
>> Pascal allowed nested function definitions, which provide (IIANM)
>> the same limited closure capabilities that gcc nested functions
>> do.
>>
>> I believe closures (and lambdas) are becoming more common in
>> imperative/procedural languages, such as C, due to a growing
>> awareness in the hinterlands of the value they bring to writing
>> real programs. Closures/lambdas aren't important because they
>> are becoming popular; they are becoming popular because they
>> are important.
>>
>> I guess I should end with an offer to respond to a skeptical
>> followup regarding the views just presented. If someone has
>> a question about closures/lambdas, and topical in CLC, please
>> feel free to followup and ask it.
>
> I've been able to treat function bodies somewhat successfully
> as anonymous objects by putting them in my X-macros and generating
> names automatically.
Not nearly the same thing. An important aspect of closures
is that they (may) come into being dynamically. Macros
don't do this.
> But the missing piece for closures in C seems to me to be
> the "currying" or partial capture of arguments.
>
> One possible means might be define a correspondence between
> a function's argument list and an implicitly-created
> "argument struct" type which can represent the captured
> values. It seems it would also need some kind "mask" component
> to designate which arguments are still pending.
>
> I'm not clearly conceiving the gymnastics to do this with
> user code (even with macros), but this kind of thing doesn't
> seem impossible for C31.
I guess I did volunteer to respond to questions, so let
me give this one a try. I'll do what I can to be at least
partly topical.
First, note that currying and closures need not go hand-in-hand.
There are languages that have closures but do not (directly)
support currying. Any language with full closures can simulate
currying by defining a "curried" function suitably. In this
sense currying can be viewed as just syntactic sugar over the
more central mechanism of first-class closures.
In C, it's fairly straightforward to get partial closures in the
form of nested functions. Gcc supports these as an extension.
Here is an example (disclaimer: not compiled):
size_t
compares_needed_to_sort( int v[], size_t n ){
size_t compares = 0;
int
sorter( const void *va, const void *vb ){
const int *pa = va, *pb = vb, a = *pa, b = *pb;
compares ++;
return (a > b) - (a < b);
}
qsort( v, n, sizeof v[0], sorter );
return compares;
}
The gcc extension for nested functions allows this function
definition. It works because the closure for 'sorter' is used
only while the stack frame for compares_needed_to_sort() is still
in existence. The gcc extension implements partial closures:
they can be used while the enclosing stack frame hasn't been left
yet, but they cannot survive returning from that stack frame.
(The last statement assumes of course they access some local
variables. If they don't access local variables then they can be
just like a top-level function, and survive outer return just
fine.) The reason is the variable 'compares' needs to be around
to be incremented, but if the stack frame has been left it's no
longer there. Thus these partial closures cannot usefully be
stored in long-lived data structures or returned as function
values.
To get full closures in C, any local variables accessed by a
closure needs to be put in memory outside the stack. (There is
an additional complication for any parameters accessed by a
closure, but I think that is easy to work out so I won't describe
it further.) It is easy enough to get space for any variables
referenced in closures, by putting a call to malloc() in the
function prologue. Now a closure can be implemented as a
(pointer-to-function, pointer-to-dynamic-block) pair. (There
are also other ways to implement closures, but I won't explain
them here.)
However, now there is another problem. This memory for
closure-referenced variables has been malloc()ed, but when does
it get free()ed? Full closures generally rely on automatic
storage reclamation. To get that in C, we would need to use
something like the Boehm conservative garbage collector.
Moreover the compiler would need to be aware that this is
going on, to call the appropriate allocation routine (which
might be malloc(), but also might be something else, depending
on the particulars). Once this has been done, the step from
partial closures to full closures is fairly easy (subject of
course to the limitations of whatever memory reclamation scheme
is in use).
With full closures being available, currying can be provided by
re-writing a function definition with multiple parameters as
nested function definitions with only one parameter each. For
example, suppose we want to curry a function such as:
int
add3( int a, int b, int c ){
return a+b+c;
}
A curryable version can be done using closures thusly
(for now ignore the types XXX and YYY):
XXX
add3_a( int a0 ){
int a = a0;
YYY
add3_b( int b0 ){
int b = b0;
int
add3_c( int c ){
return a+b+c;
}
return add3_c;
}
return add3_b;
}
With this definition available, to get the functionality of
add3(), we can use chained calls starting with add3_a():
int x = add3_a( 1 )( 2 )( 3 ); // x will be 6
I think partial application and providing a syntactic sugar for a
normal-looking function call on top of this sort of definition
are both fairly straightforward. I won't describe them further.
Getting back to the types XXX and YYY, what should these be? If
closures are implemented so that they are interchangeable with
regular pointer-to-function types (as some languages have done),
these types can be just ordinary pointer-to-function types:
typedef int (*YYY)( int );
typedef YYY (*XXX)( int );
However, if closures are not interchangeable with regular
pointer-to-function types, then that needs to be expressed at the
type level. There are any number of ways these types might be
indicated syntactically; here is one I'm sure lots of people
will dislike :) -
typedef int YYY { int };
typedef YYY XXX { int };
This example syntax is provided only for the purpose of
illustration. I will let other people bike-shed over
what sort of syntax choice might be appropriate in such
cases.
This concludes my answer. How helpful and/or interesting was it?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-28 21:13 -0700 |
| Message-ID | <89cbb9bc-51c5-45f0-b0ba-c0d469a0b668@googlegroups.com> |
| In reply to | #91255 |
On Thursday, July 28, 2016 at 12:31:33 PM UTC-5, Tim Rentsch wrote:
> luser droog <luser.droog@gmail.com> writes:
>
> > On Monday, July 25, 2016 at 11:21:43 AM UTC-5, Tim Rentsch wrote:
> >> raltbos@xs4all.nl (Richard Bos) writes:
> >>
> >>> I have no problem with lambdas. I don't see myself using them much,
> >>> ever, but lambdas are fine where they're the appropriate solution.
> >>> Which, AFAICT, is algorithm research, BICBW - it's not day-to-day
> >>> programming for me, that's certain. What I _do_ have a problem with,
> >>> though, is programming fads, and lambdas have become one of them.
> >>
> >> I think there was a time when I would have agreed with this
> >> viewpoint. Now I have a different perspective, and would like to
> >> present that.
> >>
> >> First, a note on terminology. The key underlying mechanism is
> >> closures. Closures can be implemented by way of named, nested
> >> functions (which gcc does as an extension), or by anonymous
> >> "in-place" function bodies (which often are called lambdas).
> >> IMO anonymous closures (aka lambdas) are significantly more
> >> convenient than just having nested function definitions, but
> >> the difference between those is one of syntactic sugar (rather
> >> rich sugar perhaps, but still just a syntactic convenience).
> >> Let me use the word closure to refer to the basic underlying
> >> mechanism, without regard to whether the nested function bodies
> >> are named or anonymous.
> >>
> >> Closures are significant because they enable control abstraction,
> >> which is remarkably powerful. It is difficult to realize the
> >> full potential of closures in a language like C, because it does
> >> not provide automatic storage reclamation, and because C's type
> >> system isn't rich enough to provide parametric polymorphism.
> >> Despite that, closures offer a substantial benefit even when
> >> restricted by those limitations. Readers may remember that
> >> Pascal allowed nested function definitions, which provide (IIANM)
> >> the same limited closure capabilities that gcc nested functions
> >> do.
> >>
> >> I believe closures (and lambdas) are becoming more common in
> >> imperative/procedural languages, such as C, due to a growing
> >> awareness in the hinterlands of the value they bring to writing
> >> real programs. Closures/lambdas aren't important because they
> >> are becoming popular; they are becoming popular because they
> >> are important.
> >>
> >> I guess I should end with an offer to respond to a skeptical
> >> followup regarding the views just presented. If someone has
> >> a question about closures/lambdas, and topical in CLC, please
> >> feel free to followup and ask it.
> >
> > I've been able to treat function bodies somewhat successfully
> > as anonymous objects by putting them in my X-macros and generating
> > names automatically.
>
> Not nearly the same thing. An important aspect of closures
> is that they (may) come into being dynamically. Macros
> don't do this.
Agreed. Grasping for something from my "functional" bag to segue.
> > But the missing piece for closures in C seems to me to be
> > the "currying" or partial capture of arguments.
> >
> > One possible means might be define a correspondence between
> > a function's argument list and an implicitly-created
> > "argument struct" type which can represent the captured
> > values. It seems it would also need some kind "mask" component
> > to designate which arguments are still pending.
> >
> > I'm not clearly conceiving the gymnastics to do this with
> > user code (even with macros), but this kind of thing doesn't
> > seem impossible for C31.
>
> I guess I did volunteer to respond to questions, so let
> me give this one a try. I'll do what I can to be at least
> partly topical.
I tried to keep it topical. "Hypothetical future extension to C
that could really, actually be possible to happen".
> First, note that currying and closures need not go hand-in-hand.
> There are languages that have closures but do not (directly)
> support currying. Any language with full closures can simulate
> currying by defining a "curried" function suitably. In this
> sense currying can be viewed as just syntactic sugar over the
> more central mechanism of first-class closures.
>
> In C, it's fairly straightforward to get partial closures in the
> form of nested functions. Gcc supports these as an extension.
> Here is an example (disclaimer: not compiled):
>
> size_t
> compares_needed_to_sort( int v[], size_t n ){
> size_t compares = 0;
> int
> sorter( const void *va, const void *vb ){
> const int *pa = va, *pb = vb, a = *pa, b = *pb;
> compares ++;
> return (a > b) - (a < b);
> }
> qsort( v, n, sizeof v[0], sorter );
> return compares;
> }
>
> The gcc extension for nested functions allows this function
> definition. It works because the closure for 'sorter' is used
> only while the stack frame for compares_needed_to_sort() is still
> in existence. The gcc extension implements partial closures:
> they can be used while the enclosing stack frame hasn't been left
> yet, but they cannot survive returning from that stack frame.
> (The last statement assumes of course they access some local
> variables. If they don't access local variables then they can be
> just like a top-level function, and survive outer return just
> fine.) The reason is the variable 'compares' needs to be around
> to be incremented, but if the stack frame has been left it's no
> longer there. Thus these partial closures cannot usefully be
> stored in long-lived data structures or returned as function
> values.
>
> To get full closures in C, any local variables accessed by a
> closure needs to be put in memory outside the stack. (There is
> an additional complication for any parameters accessed by a
> closure, but I think that is easy to work out so I won't describe
> it further.) It is easy enough to get space for any variables
> referenced in closures, by putting a call to malloc() in the
> function prologue. Now a closure can be implemented as a
> (pointer-to-function, pointer-to-dynamic-block) pair. (There
> are also other ways to implement closures, but I won't explain
> them here.)
This reminds of something I read about Algol's "display" data structure
for storing the block of locals.
> However, now there is another problem. This memory for
> closure-referenced variables has been malloc()ed, but when does
> it get free()ed? Full closures generally rely on automatic
> storage reclamation. To get that in C, we would need to use
> something like the Boehm conservative garbage collector.
> Moreover the compiler would need to be aware that this is
> going on, to call the appropriate allocation routine (which
> might be malloc(), but also might be something else, depending
> on the particulars). Once this has been done, the step from
> partial closures to full closures is fairly easy (subject of
> course to the limitations of whatever memory reclamation scheme
> is in use).
So that's a big dang problem in the way of "really, actually possible
to happen".
> With full closures being available, currying can be provided by
> re-writing a function definition with multiple parameters as
> nested function definitions with only one parameter each. For
> example, suppose we want to curry a function such as:
>
> int
> add3( int a, int b, int c ){
> return a+b+c;
> }
>
> A curryable version can be done using closures thusly
> (for now ignore the types XXX and YYY):
>
> XXX
> add3_a( int a0 ){
> int a = a0;
> YYY
> add3_b( int b0 ){
> int b = b0;
> int
> add3_c( int c ){
> return a+b+c;
> }
> return add3_c;
> }
> return add3_b;
> }
>
> With this definition available, to get the functionality of
> add3(), we can use chained calls starting with add3_a():
>
> int x = add3_a( 1 )( 2 )( 3 ); // x will be 6
>
> I think partial application and providing a syntactic sugar for a
> normal-looking function call on top of this sort of definition
> are both fairly straightforward. I won't describe them further.
But in that syntactic sugar may also lie an implementation issue.
The partial application version " add3_a( 1 )( 2 )( 3 );" has a
defined order of evaluating the arguments whereas a normal function
call does not. So this may entail either defining the evaluation
order or leaving weird surprises in there.
> Getting back to the types XXX and YYY, what should these be? If
> closures are implemented so that they are interchangeable with
> regular pointer-to-function types (as some languages have done),
> these types can be just ordinary pointer-to-function types:
>
> typedef int (*YYY)( int );
> typedef YYY (*XXX)( int );
>
> However, if closures are not interchangeable with regular
> pointer-to-function types, then that needs to be expressed at the
> type level. There are any number of ways these types might be
> indicated syntactically; here is one I'm sure lots of people
> will dislike :) -
>
> typedef int YYY { int };
> typedef YYY XXX { int };
>
> This example syntax is provided only for the purpose of
> illustration. I will let other people bike-shed over
> what sort of syntax choice might be appropriate in such
> cases.
>
> This concludes my answer. How helpful and/or interesting was it?
Very interesting. I feel my post was foundered on the wrong iceberg
altogether.
As for "useful". The political issue for extending C to perform
this magic is Garbage Collection. It would still (at first) be
employed only for this feature, so not using them would not pay
a performance penalty. But GC is the hard sell, I think. Based on
only 2 passes, your post pretty much explains everything else that
would need to be done.
I think my false-start non-issue stems from attempting to take the
initial step of adding Lisp-like "homoiconicity" so that a function
*template* can be expressed as normal code but then accessed as a
data structure (and later exectuted as "instantiated" code). I suppose
this part really isn't needed for supporting closures.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 09:05 -0700 |
| Message-ID | <541343b5-a799-4a2c-9be8-db88a53e7b75@googlegroups.com> |
| In reply to | #91301 |
On Thursday, July 28, 2016 at 11:14:41 PM UTC-5, luser droog wrote: > As for "useful". The political issue for extending C to perform > this magic is Garbage Collection. It would still (at first) be > employed only for this feature, so not using them would not pay > a performance penalty. But GC is the hard sell, I think. Based on > only 2 passes, your post pretty much explains everything else that > would need to be done. There are some kinds of useful code which are fundamentally incompatible with garbage-collection (e.g. a program that is running on an embedded system which has access to reasonably-fast external storage but not virtual memory, and which need to be able to store pointers to live data within the external storage). The solution to that, and many other problems, would be for the C Standard to recognize the concept of compilation modes, along with a requirement that compilers need not support all of the modes defined by the Standard, but every compliant compiler must reject any program that requires modes that it does not support. A program which specifies GC-friendly mode manipulates pointers in such a way that the compiler can't recognize them, and then later reconstitutes those pointers and tries to use them, would invoke UB. If the program had specified a mode that allows such pointer manipulations, however, a compiler would have to either process it in defined fashion or else reject the program entirely (the latter perhaps being preferable for some kinds of "sandboxing" implementations). Unless or until the Committee is willing to recognize that it would be good for different implementations to support different features and guarantees, I really don't see much useful a "standard" can accomplish.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-29 09:30 -0700 |
| Message-ID | <lnfuqs76fj.fsf@kst-u.example.com> |
| In reply to | #91322 |
supercat@casperkitty.com writes:
[...]
> Unless or until the Committee is willing to recognize that it would be
> good for different implementations to support different features and
> guarantees, I really don't see much useful a "standard" can accomplish.
Which explains why nobody ever manages to do anything useful in C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 10:08 -0700 |
| Message-ID | <30402443-8a79-4d11-aae0-3b06c568f822@googlegroups.com> |
| In reply to | #91325 |
On Friday, July 29, 2016 at 11:30:49 AM UTC-5, Keith Thompson wrote:
> supercat writes:
> [...]
> > Unless or until the Committee is willing to recognize that it would be
> > good for different implementations to support different features and
> > guarantees, I really don't see much useful a "standard" can accomplish.
>
> Which explains why nobody ever manages to do anything useful in C.
People had doing useful things in C for over a decade before C89 was
published. While the usefulness of the language on obscure platforms
was greatly enhanced by the Standard, most implementations for years
afterward implemented several kinds of behaviors:
1. Those which were mandated by the Standard, but they would have
implemented anyway.
2. Those which were not mandated by the Standard, but they would
have implemented before the Standard and continued to implement
even though the Standard didn't require them.
3. Those they only implemented because of the Standard's mandate.
On implementations for obscure platforms, category #3 may have been quite
large, but for those targeting many commonplace implementations it wasn't.
Some compiler writers saw that C++-style prototypes would be a useful
adjunct to the language and thus implemented them before the publication
of C89, and I think it likely that many others would have followed suit
even in the absence of the standard. Otherwise, I can't think of a whole
lot of useful stuff that C89 added that commonplace implementations weren't
already doing. As such, I don't really see that the Standard did a whole
lot to make the language more useful on commonplace platforms. What am I
missing?
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-29 17:57 +0000 |
| Message-ID | <slrn3vfsnpn67d.if3.ike@iceland.freeshell.org> |
| In reply to | #91331 |
On 2016-07-29, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > On Friday, July 29, 2016 at 11:30:49 AM UTC-5, Keith Thompson wrote: >> supercat writes: >> [...] >> > Unless or until the Committee is willing to recognize that it would be >> > good for different implementations to support different features and >> > guarantees, I really don't see much useful a "standard" can accomplish. >> >> Which explains why nobody ever manages to do anything useful in C. > > People had doing useful things in C for over a decade before C89 was > published. While the usefulness of the language on obscure platforms > was greatly enhanced by the Standard, most implementations for years > afterward implemented several kinds of behaviors: > > 1. Those which were mandated by the Standard, but they would have > implemented anyway. > > 2. Those which were not mandated by the Standard, but they would > have implemented before the Standard and continued to implement > even though the Standard didn't require them. > > 3. Those they only implemented because of the Standard's mandate. > > On implementations for obscure platforms, category #3 may have been quite > large, but for those targeting many commonplace implementations it wasn't. > Some compiler writers saw that C++-style prototypes would be a useful > adjunct to the language and thus implemented them before the publication > of C89, and I think it likely that many others would have followed suit > even in the absence of the standard. Otherwise, I can't think of a whole > lot of useful stuff that C89 added that commonplace implementations weren't > already doing. As such, I don't really see that the Standard did a whole > lot to make the language more useful on commonplace platforms. What am I > missing? What I liked about the C89 standard was standardi(zs)ation of the header files. Before C89, depending on the platform, one had to #include either <string.h> or <strings.h> for string functions, either <stdlib.h> or <mem.h> or <malloc.h> for memory management, either <varargs.h> or <stdargs.h> for variadic functions, etc. Function prototypes would sometime be supported and sometimes not. If one worked on software that had to run on several platforms, the pre-C89 code used to be riddled with #if's. C89 certainly brought order in that chaos.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 11:50 -0700 |
| Message-ID | <f4553efa-cb88-48a5-8187-4dff279c53e7@googlegroups.com> |
| In reply to | #91333 |
On Friday, July 29, 2016 at 12:57:27 PM UTC-5, Ike Naar wrote: > What I liked about the C89 standard was standardi(zs)ation of the > header files. Before C89, depending on the platform, one had to > #include either <string.h> or <strings.h> for string functions, > either <stdlib.h> or <mem.h> or <malloc.h> for memory management, > either <varargs.h> or <stdargs.h> for variadic functions, etc. > Function prototypes would sometime be supported and sometimes not. > If one worked on software that had to run on several platforms, > the pre-C89 code used to be riddled with #if's. C89 certainly > brought order in that chaos. I'd forgotten about some of the difficulties with the header files which were eased by standardization, and where standardization avoided the need to have every implementation implement a lot of things redundantly because nobody knew which functions people expected to find where. I have no problem marking that as a useful thing the Standard accomplished. I also have no objection to crediting the Standard with establishing a reliable protocol for accessing command-line arguments. In both cases, old ways of doing things were effectively deprecated when the Standard introduced ways which may have been slightly different but no less functional than what existed before. If the Standard had defined directives by which programmers could indicate that their programs did or did not require various optional guarantees, then code without such directives could be deprecated in favor of code that includes them (since the latter would be almost unambiguously better). Such directives could easily allow optimization opportunities far beyond anything allowable in the current Standard, while still allowing compilers to maintain compatibility with pre- existing code. Unfortunately, the Standard has been interpreted as deprecating behaviors for which it provides no practical alternative; in the 1990s there was no call to define new ways to do things that could be done just fine on existing implementations (using the ways that would later be regarded as deprecated). Since then, an attitude seems to have emerged that since deprecating the behaviors didn't pose a problem, they should be eliminated, notwithstanding the fact that no practical alternative was ever defined, and people hadn't been inclined to take deprecation seriously when no practical alternative existed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 07:16 -0700 |
| Message-ID | <kfnvazlnb8l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91301 |
luser droog <luser.droog@gmail.com> writes:
> On Thursday, July 28, 2016 at 12:31:33 PM UTC-5, Tim Rentsch wrote:
>> luser droog <luser.droog@gmail.com> writes:
>>
>>> On Monday, July 25, 2016 at 11:21:43 AM UTC-5, Tim Rentsch wrote:
>>>> raltbos@xs4all.nl (Richard Bos) writes:
>>>>
>>>>> I have no problem with lambdas. I don't see myself using them much,
>>>>> ever, but lambdas are fine where they're the appropriate solution.
>>>>> Which, AFAICT, is algorithm research, BICBW - it's not day-to-day
>>>>> programming for me, that's certain. What I _do_ have a problem with,
>>>>> though, is programming fads, and lambdas have become one of them.
>>>>
>>>> [...] [.. and other portions that follow ..]
>>>> I guess I should end with an offer to respond to a skeptical
>>>> followup regarding the views just presented. If someone has
>>>> a question about closures/lambdas, and topical in CLC, please
>>>> feel free to followup and ask it.
>>>
>>> But the missing piece for closures in C seems to me to be
>>> the "currying" or partial capture of arguments.
>>>
>> First, note that currying and closures need not go hand-in-hand.
>> There are languages that have closures but do not (directly)
>> support currying. Any language with full closures can simulate
>> currying by defining a "curried" function suitably. In this
>> sense currying can be viewed as just syntactic sugar over the
>> more central mechanism of first-class closures.
>>
>> In C, it's fairly straightforward to get partial closures in the
>> form of nested functions. Gcc supports these as an extension.
>> [.. example and explanation of full vs partial closures ..]
>>
>> To get full closures in C, any local variables accessed by a
>> closure needs to be put in memory outside the stack. (There is
>> an additional complication for any parameters accessed by a
>> closure, but I think that is easy to work out so I won't describe
>> it further.) It is easy enough to get space for any variables
>> referenced in closures, by putting a call to malloc() in the
>> function prologue. Now a closure can be implemented as a
>> (pointer-to-function, pointer-to-dynamic-block) pair. (There
>> are also other ways to implement closures, but I won't explain
>> them here.)
>>
>> However, now there is another problem. This memory for
>> closure-referenced variables has been malloc()ed, but when does
>> it get free()ed? Full closures generally rely on automatic
>> storage reclamation. To get that in C, we would need to use
>> something like the Boehm conservative garbage collector.
>> Moreover the compiler would need to be aware that this is
>> going on, to call the appropriate allocation routine (which
>> might be malloc(), but also might be something else, depending
>> on the particulars). Once this has been done, the step from
>> partial closures to full closures is fairly easy (subject of
>> course to the limitations of whatever memory reclamation scheme
>> is in use).
>
> So that's a big dang problem in the way of "really, actually
> possible to happen".
The problems of getting automatic storage reclamation (aka
garbage collection) into C are more cultural than technical.
Obviously the C community as a whole would not accept it as
a required feature of the language. However, it might be
palatable as an optional feature, especially if the option
were user-selectable and the default value if no choice
is made were NO.
>> With full closures being available, currying can be provided by
>> re-writing a function definition with multiple parameters as
>> nested function definitions with only one parameter each. For
>> example, suppose we want to curry a function such as:
>>
>> int
>> add3( int a, int b, int c ){
>> return a+b+c;
>> }
>>
>> A curryable version can be done using closures thusly
>> (for now ignore the types XXX and YYY):
>>
>> XXX
>> add3_a( int a0 ){
>> int a = a0;
>> YYY
>> add3_b( int b0 ){
>> int b = b0;
>> int
>> add3_c( int c ){
>> return a+b+c;
>> }
>> return add3_c;
>> }
>> return add3_b;
>> }
>>
>> With this definition available, to get the functionality of
>> add3(), we can use chained calls starting with add3_a():
>>
>> int x = add3_a( 1 )( 2 )( 3 ); // x will be 6
>>
>> I think partial application and providing a syntactic sugar for a
>> normal-looking function call on top of this sort of definition
>> are both fairly straightforward. I won't describe them further.
>
> But in that syntactic sugar may also lie an implementation issue.
> The partial application version " add3_a( 1 )( 2 )( 3 );" has a
> defined order of evaluating the arguments whereas a normal function
> call does not. So this may entail either defining the evaluation
> order or leaving weird surprises in there.
Look again. There is no requirement on evaluation order
for the three argument expressions here. They all can
be evaluated, in any ordering, before the initial call
to add3_a(). Or the first can be evaluated before the
call to add3_a(), and the others after it returns. Etc.
This expression is more or less analogous to 'a+b+c',
which allows a, b, and c to be evaluated in any ordering.
Of course, if we separate the currying steps explicitly, eg
(please excuse some syntactic liberties):
auto foo = add3_a( 1 );
auto bas = foo( 2 );
bas( 3 );
then there is a required order of evaluation (ie, in the abstract
machine). But here again that is no different than how C behaves
with other kinds of expressions.
>> Getting back to the types XXX and YYY, what should these be? If
>> closures are implemented so that they are interchangeable with
>> regular pointer-to-function types (as some languages have done),
>> these types can be just ordinary pointer-to-function types:
>>
>> typedef int (*YYY)( int );
>> typedef YYY (*XXX)( int );
>>
>> However, if closures are not interchangeable with regular
>> pointer-to-function types, then that needs to be expressed at the
>> type level. There are any number of ways these types might be
>> indicated syntactically; here is one I'm sure lots of people
>> will dislike :) -
>>
>> typedef int YYY { int };
>> typedef YYY XXX { int };
>>
>> This example syntax is provided only for the purpose of
>> illustration. I will let other people bike-shed over
>> what sort of syntax choice might be appropriate in such
>> cases.
>>
>> This concludes my answer. How helpful and/or interesting was it?
>
> Very interesting. I feel my post was foundered on the wrong iceberg
> altogether.
>
> As for "useful". The political issue for extending C to perform
> this magic is Garbage Collection. It would still (at first) be
> employed only for this feature, so not using them would not pay
> a performance penalty. But GC is the hard sell, I think. Based on
> only 2 passes, your post pretty much explains everything else that
> would need to be done.
There is a common belief in some circles that GC incurs a
substantial performance penalty relative to manual coding of
free(), etc. Experience with actual systems does not bear this
out. Indeed, the experience in some large code bases has been
that switching to GC actually improves performance. I agree
getting C developers to embrace GC is a hard sell, but I think
that is based largely on misconception rather than on a real
understanding of the issues.
Don't get me wrong, there are consequences for adopting a
GC-based model for memory allocation. Certainly there are
contexts (writing OS kernels being an obvious one) where using GC
is rightly viewed with great skepticism. But I think most C
programs would benefit from switching to a GC-based model. The
reason is a gain in developer productivity: studies that have
been done show a productivity improvement in the range of 60 to
100 percent. That is, writing code where there is no need for
manual deallocation produces somewhere between 1.6 times and 2
times as many lines of code per day. That is a huge win.
> I think my false-start non-issue stems from attempting to take the
> initial step of adding Lisp-like "homoiconicity" so that a function
> *template* can be expressed as normal code but then accessed as a
> data structure (and later exectuted as "instantiated" code). I suppose
> this part really isn't needed for supporting closures.
Right. Most languages that I know of that support closures
do not have the Lisp-like property that code and data have
the same form.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-31 14:34 +0000 |
| Message-ID | <579e0bce.8242578@news.xs4all.nl> |
| In reply to | #91389 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Don't get me wrong, there are consequences for adopting a > GC-based model for memory allocation. Certainly there are > contexts (writing OS kernels being an obvious one) where using GC > is rightly viewed with great skepticism. But I think most C > programs would benefit from switching to a GC-based model. The > reason is a gain in developer productivity: studies that have > been done show a productivity improvement in the range of 60 to > 100 percent. That is, writing code where there is no need for > manual deallocation produces somewhere between 1.6 times and 2 > times as many lines of code per day. That is a huge win. It's also a silly number which I have a hard time believing. How much of your code is spent doing allocation tasks, compared to computation and other data manipulation? How much bookkeeping involves not _just_ free(), but also, I dunno, data_structure_destroy()? I'd need a very atypical project for it even to be _possible_ for me to write twice as many lines of code if I could forget about free(), never mind likely. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 14:55 -0700 |
| Message-ID | <kfn60rlmpzv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91390 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Don't get me wrong, there are consequences for adopting a >> GC-based model for memory allocation. Certainly there are >> contexts (writing OS kernels being an obvious one) where using GC >> is rightly viewed with great skepticism. But I think most C >> programs would benefit from switching to a GC-based model. The >> reason is a gain in developer productivity: studies that have >> been done show a productivity improvement in the range of 60 to >> 100 percent. That is, writing code where there is no need for >> manual deallocation produces somewhere between 1.6 times and 2 >> times as many lines of code per day. That is a huge win. > > It's also a silly number If it is an accurate reporting of an actual measurement of productivity, how is it silly? Do you think that the kind of activities involved are not typical of most code development? Wouldn't that depend on what programming tasks were measured? Or do you think the number is silly for some other reason? > which I have a hard time believing. How much of > your code is spent doing allocation tasks, compared to computation and > other data manipulation? How much bookkeeping involves not _just_ > free(), but also, I dunno, data_structure_destroy()? I'd need a very > atypical project for it even to be _possible_ for me to write twice as > many lines of code if I could forget about free(), never mind likely. I think the key question is not about how much code but about how much mental effort is required. Most of the related mental energy in code that requires manual freeing goes into not having to call malloc()/free() in the first place. Library functions like strcpy(), strcat(), snprintf() reflect this. How much time goes into avoiding overflow of finite buffers? That problem goes away if functions like these allocate new memory for their results, to be automatically freed at a later appropriate moment. And I believe there are numerous other similar examples, if one were to go looking for them. But suppose we back up and guess that these reports are not typical, and that a more representative number is 1.25 times. Doesn't that already seem like a signifcant factor? Being able to accomplish a task that would have taken five weeks in only four weeks? I still would put that in the big win category.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-01 03:10 -0700 |
| Message-ID | <928f054b-32b7-40bf-a5c7-bbd9c7b35987@googlegroups.com> |
| In reply to | #91430 |
On Sunday, July 31, 2016 at 10:55:58 PM UTC+1, Tim Rentsch wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > It's also a silly number > > If it is an accurate reporting of an actual measurement of > productivity, how is it silly? Do you think that the kind of > activities involved are not typical of most code development? > Wouldn't that depend on what programming tasks were measured? > Or do you think the number is silly for some other reason? > Plenty of C coding is done in an environment where there is no dynamic memory at all. So no measure of the impact of GC can be truly representative of a cross-section of C programming. Really the question is, what type of coding, what type of productivity gain, and is it in an area that is a risk to the business. For example, you might have one person you can't easily replace doing core mathematical algorithms, and ten people putting up windows and writing SQL queries and doing all the other jobs needed to gather the data to feed to those algorithms and present the results to the user. Now it's unlikely your pay your mathematician ten times as much as your other programmers, probably more like 50% more and less than than lead programmer on the project. So on one level, if we double everyone else's productivity, and halve the mathematician's we've essentially halved the cost of development. However we've also doubled the development time, and we've doubled the risk that our mathematician will go under a bus before the project is completed. So the move to GC wouldn't really be a good idea, under those hypothetical circumstances. The scenario is a bit extreme, to make the point, but not fundamentally unrealistic. Not all lines of code are worth the same. > > But suppose we back up and guess that these reports are not > typical, and that a more representative number is 1.25 times. > Doesn't that already seem like a signifcant factor? Being > able to accomplish a task that would have taken five weeks > in only four weeks? I still would put that in the big win > category. > I don't think there's any dispute that proper handling of memory allocation failure and freeing of allocated structures adds a lot of unnecessary complexity to C code. Made worse because many people won't use a goto on malloc() failure, so the complexity goes into their main control flow. Also because some people insist that root objects be allocated on the stack, which saves one malloc() call, at cost of complicating the create / destroy paradigm. It also means that some methodolgies, like closures which survive the return from the captured scope, can't easily be implemented in C. You can easily enough malloc a chunk of memory to take a snapshot of the scope, but you can't then destroy it when the closure is finally got rid of.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-01 07:40 -0700 |
| Message-ID | <kfnpopsk0wv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91464 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, July 31, 2016 at 10:55:58 PM UTC+1, Tim Rentsch wrote: >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> It's also a silly number >> >> If it is an accurate reporting of an actual measurement of >> productivity, how is it silly? Do you think that the kind of >> activities involved are not typical of most code development? >> Wouldn't that depend on what programming tasks were measured? >> Or do you think the number is silly for some other reason? > > Plenty of C coding is done in an environment where there is no dynamic > memory at all. So no measure of the impact of GC can be truly > representative of a cross-section of C programming. > Really the question is, what type of coding, what type of productivity gain, > and is it in an area that is a risk to the business. > > For example, you might have one person you can't easily replace doing > core mathematical algorithms, and ten people putting up windows and > writing SQL queries and doing all the other jobs needed to gather the > data to feed to those algorithms and present the results to the user. > Now it's unlikely your pay your mathematician ten times as much as your > other programmers, probably more like 50% more and less than than lead > programmer on the project. So on one level, if we double everyone else's > productivity, and halve the mathematician's we've essentially halved the > cost of development. However we've also doubled the development time, > and we've doubled the risk that our mathematician will go under a bus before > the project is completed. > So the move to GC wouldn't really be a good idea, under those hypothetical > circumstances. The scenario is a bit extreme, to make the point, but not > fundamentally unrealistic. Not all lines of code are worth the same. IMO these comments don't offer any substance of interest to the discussion.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web