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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 09:48 +0530 |
| Message-ID | <nmhlbf$cu5$1@dont-email.me> |
| In reply to | #90478 |
On 07/17/2016 11:44 PM, jacobnavia wrote: > 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. If by "lisp heads" you mean those who have learned Lisp, then yes, even your mistranslation is easy to read. (Ben Bacarisse gave the correct one.) The parentheses are as invisible to a "lisp head" as the many punctuators in C are to "C people." And surely school is not the be-all and end-all of learning. Even if you were taught infix first, does that preclude learning other notations? HP would have had even less success with their RPN calculators if infix was all that people could learn. > Other guys... well YMMV. Precisely. People are different in what they like. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-18 00:55 -0700 |
| Message-ID | <48b3a55b-a04d-47b8-9d1d-288e55258fbd@googlegroups.com> |
| In reply to | #90493 |
On Monday, July 18, 2016 at 5:19:06 AM UTC+1, Udyant Wig wrote: > On 07/17/2016 11:44 PM, jacobnavia wrote: > > And surely school is not the be-all and end-all of learning. Even if > you were taught infix first, does that preclude learning other > notations? HP would have had even less success with their RPN > calculators if infix was all that people could learn. > If you learn something as a child, you tend to accept it as "natural" or "normative" in way that you don't as an adult.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 22:25 +0530 |
| Message-ID | <nmj1li$ocb$1@dont-email.me> |
| In reply to | #90497 |
On 07/18/2016 01:25 PM, Malcolm McLean wrote: > If you learn something as a child, you tend to accept it as "natural" > or "normative" in way that you don't as an adult. Yes, and unless overridden by conscious acts of thought, one might still carry on believing in what one did as a child, such as fairy-tales and myths. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-18 11:40 +0100 |
| Message-ID | <nmibnu$cds$1@dont-email.me> |
| In reply to | #90493 |
On 18/07/2016 05:18, Udyant Wig wrote: > On 07/17/2016 11:44 PM, jacobnavia wrote: >> 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. > > If by "lisp heads" you mean those who have learned Lisp, then yes, > even your mistranslation is easy to read. (Ben Bacarisse gave the > correct one.) The parentheses are as invisible to a "lisp head" as > the many punctuators in C are to "C people." Those parentheses had better not be invisible, as they can change the meaning of the expression! For amusement, I just spent 20 minutes adding lisp-style expressions to one of my languages. Not a full treatment, but enough to be able to do: a:=10 b:=100 c:=20 println a+(b-5)/(c+47) println lisp(+ a (/ (- b 5) (+ c 47))) Both display 11.41791. So if there are any advantages in writing expressions lisp-style, you can have these and still keep the rest of the program normal. You can have the best of both worlds! What this approach can't do is to be able to apply 'quote' to such an expression, and use it as data or as a macro or however it works. But that isn't needed for the majority of normal coding. Ben said however that you can see the 'head' operation, and you can in my example. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-18 05:05 -0700 |
| Message-ID | <67e34faf-1461-4f83-b87f-2a18262b6812@googlegroups.com> |
| In reply to | #90502 |
On Monday, July 18, 2016 at 11:41:10 AM UTC+1, Bart wrote: > On 18/07/2016 05:18, Udyant Wig wrote: > > What this approach can't do is to be able to apply 'quote' to such an > expression, and use it as data or as a macro or however it works. But > that isn't needed for the majority of normal coding. > That's a strength and a weakness of Lisp. If we want a derivative-taker in Lisp, we can pass (x + dx) to a function which is ultimately built up of arithmetical operations, throw away the dx^2 terms (dx is a tiny step, so dx^2 is nothing), and we've got the derivative. It's very powerful, but you've got to suppress evaluation. But the quote system is confusing. It's hard to work out what is evaluated when and where.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 22:59 +0530 |
| Message-ID | <nmj3lr$ud$1@dont-email.me> |
| In reply to | #90503 |
Malcolm McLean, please fix your attributions by hand if you don't use a decent Usenet client. What you quote me as writing was said by BartC. On 07/18/2016 05:35 PM, Malcolm McLean wrote: > On Monday, July 18, 2016 at 11:41:10 AM UTC+1, Bart wrote: >> On 18/07/2016 05:18, Udyant Wig wrote: >> >> What this approach can't do is to be able to apply 'quote' to such an >> expression, and use it as data or as a macro or however it works. But >> that isn't needed for the majority of normal coding. >> > That's a strength and a weakness of Lisp. > > If we want a derivative-taker in Lisp, we can pass (x + dx) to a > function which is ultimately built up of arithmetical operations, > throw away the dx^2 terms (dx is a tiny step, so dx^2 is nothing), and > we've got the derivative. It's very powerful, but you've got to > suppress evaluation. > > But the quote system is confusing. It's hard to work out what is > evaluated when and where. You know something of Lisp and (more) of C. Then why do say one aspect of Lisp -- the quote system -- is confusing, when a) both Common Lisp and C have published standards, and b) the HyperSpec (the Common Lisp standard in all but name) is available to read and learn from? If you are having some trouble with it, the fine people in comp.lang.lisp can surely help. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-18 22:50 +0530 |
| Message-ID | <nmj351$upa$1@dont-email.me> |
| In reply to | #90502 |
On 07/18/2016 04:10 PM, BartC wrote: > On 18/07/2016 05:18, Udyant Wig wrote: >> The parentheses are as invisible to a "lisp head" as the many >> punctuators in C are to "C people." > > Those parentheses had better not be invisible, as they can change the > meaning of the expression! Again, I said that the parentheses are as invisible in Lisp as the punctuators in C, which is to say that they no more bear down on the consciousness than do the various punctuators do in C. Or do you actively keep track of the semicolons and other delimeters when reading and writing? > For amusement, I just spent 20 minutes adding lisp-style expressions > to one of my languages. Not a full treatment, but enough to be able to > do: > > a:=10 > b:=100 > c:=20 > > println a+(b-5)/(c+47) > > println lisp(+ a (/ (- b 5) (+ c 47))) > > Both display 11.41791. > > So if there are any advantages in writing expressions lisp-style, you > can have these and still keep the rest of the program normal. You can > have the best of both worlds! > > What this approach can't do is to be able to apply 'quote' to such an > expression, and use it as data or as a macro or however it works. But > that isn't needed for the majority of normal coding. What is normal to one person may not be normal to another. > Ben said however that you can see the 'head' operation, and you can in > my example. There are advantages to a short and compact infix notation for simple arithmetic. And this likely has to do with the binary nature of the arithmetic operators. In contrast, +, for instance, is n-ary. We can write (+) => 0 I find this very pleasing myself. (+ foo bar baz quux) The latter might be read as the sum of the named elements. This is one advantage of what Ben Bacarisse said. The 'head' can be seen at once. Whereas you have to examine all the operators instead of just one in foo + bar + baz + quux The relational functions are also n-ary: (> foo bar baz quux) Which might be read as the named elements in monotonically decreasing order as opposed to reading "foo is greater than bar AND bar is greater than baz AND baz is greater than quux." Now, even in C, functions are not infix in nature: The function name precedes its arguments. On command lines, such as those in Unix, command names precede options and arguments. You are already used to non-infix in some form. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-18 19:07 +0100 |
| Message-ID | <nmj5tr$8oi$1@dont-email.me> |
| In reply to | #90524 |
On 18/07/2016 18:20, Udyant Wig wrote: > On 07/18/2016 04:10 PM, BartC wrote: >> So if there are any advantages in writing expressions lisp-style, you >> can have these and still keep the rest of the program normal. You can >> have the best of both worlds! > What is normal to one person may not be normal to another. Suppose you had to bet on which of several ways of writing an expression was most readable to a random programmer; would you really choose Lisp notation? The most common programming languages generally use infix. >> Ben said however that you can see the 'head' operation, and you can in >> my example. > > There are advantages to a short and compact infix notation for simple > arithmetic. And this likely has to do with the binary nature of the > arithmetic operators. In contrast, +, for instance, is n-ary. We can > write > > (+) => 0 > > I find this very pleasing myself. > > (+ foo bar baz quux) > > The latter might be read as the sum of the named elements. This starts to break down with asymmetric operators: (-) error (in Clisp) (- a) -a (- a b) a-b (- a b c) a-b-c) And are also only practical when you have fixed known number of terms to add. In which case using a+b+c or a-b-c is easy enough, and matches what is done in mathematics. When you you want to sum the elements of a list, then that is generally a different kind of operation. > (> foo bar baz quux) The infix form is more general (here = means equality): foo = bar < baz <= quux > Now, even in C, functions are not infix in nature: The function name > precedes its arguments. On command lines, such as those in Unix, > command names precede options and arguments. You are already used to > non-infix in some form. Yes, there is a mix of styles in a language. There are expressions with infix ops and function calls; statements; declarations; initialisers... It sounds great at first if all those are unified into one thing. But then you lose structure and form; everything blends together. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-19 11:53 +0530 |
| Message-ID | <nmkh0q$ltf$1@dont-email.me> |
| In reply to | #90529 |
On 07/18/2016 11:37 PM, BartC wrote: > Suppose you had to bet on which of several ways of writing an > expression was most readable to a random programmer; would you really > choose Lisp notation? What would be the purpose of this test? Again, what else do you test for suitability to a random person, let alone programmer? > The most common programming languages generally use infix. Treading the same road once more, infix is commonly used in arithmetic. Function calls are made using prefix syntax; commands on command lines use prefix syntax. > And are also only practical when you have fixed known number of terms > to add. In which case using a+b+c or a-b-c is easy enough, and matches > what is done in mathematics. Isn't there more to mathematics than arithmetic? > When you you want to sum the elements of a list, then that is > generally a different kind of operation. > >> (> foo bar baz quux) > > The infix form is more general (here = means equality): > > foo = bar < baz <= quux Why do you think the same cannot be done in non-infix? Do you implicitly accept my point about foo > bar > baz > quux ? > Yes, there is a mix of styles in a language. There are expressions > with infix ops and function calls; statements; declarations; > initialisers... It sounds great at first if all those are unified into > one thing. But then you lose structure and form; everything blends > together. Structure and form are not the sole dominion of infix. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 11:15 +0100 |
| Message-ID | <nmkuku$u3u$1@dont-email.me> |
| In reply to | #90570 |
On 19/07/2016 07:23, Udyant Wig wrote: > On 07/18/2016 11:37 PM, BartC wrote: >>> (> foo bar baz quux) >> >> The infix form is more general (here = means equality): >> >> foo = bar < baz <= quux > > Why do you think the same cannot be done in non-infix? You mean with: (and (= foo bar) (< bar baz) (<= baz quuz))? > Do you implicitly accept my point about > > foo > bar > baz > quux > > ? Yes, but it's the same one as using +, which can be emulated even in C by using a function gt(foo,bar,baz,quuz). But while it is a satisfying feature, being able to apply basic operators to N operands at the same time, the lack of it in most languages is hardly a problem. In the vast majority of instances, binary operators need to be applied to just two operands. Where there are three operands, then it's not a hardship to repeat the operator. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 14:00 +0100 |
| Message-ID | <8760s1g4vb.fsf@bsb.me.uk> |
| In reply to | #90573 |
...about (> foo bar baz quux) BartC <bc@freeuk.com> writes: > On 19/07/2016 07:23, Udyant Wig wrote: <snip> >> Do you implicitly accept my point about >> >> foo > bar > baz > quux >> >> ? > > Yes, but it's the same one as using +, which can be emulated even in C > by using a function gt(foo,bar,baz,quuz). How? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 15:01 +0100 |
| Message-ID | <nmlbr3$b2c$1@dont-email.me> |
| In reply to | #90576 |
On 19/07/2016 14:00, Ben Bacarisse wrote:
> ...about (> foo bar baz quux)
>
> BartC <bc@freeuk.com> writes:
>> On 19/07/2016 07:23, Udyant Wig wrote:
> <snip>
>>> Do you implicitly accept my point about
>>>
>>> foo > bar > baz > quux
>>>
>>> ?
>>
>> Yes, but it's the same one as using +, which can be emulated even in C
>> by using a function gt(foo,bar,baz,quuz).
>
> How?
I was thinking of something like the code below.
The GT() macro is for signed ints; separate versions are needed for
different primitive types (but not for different widths).
This version is limited to 10 operands but that can be probably be
increased to any reasonable number. (But by then, you'd want a function
that takes an arrray really.)
The example above would be written as GT(foo,bar,baz,quuz).
#include <stdio.h>
#include <stdarg.h>
#define VA_NUM_ARGS(...) VA_NUM_ARGS_IMPL(__VA_ARGS__,\
10,9,8,7,6,5,4,3,2,1)
#define VA_NUM_ARGS_IMPL(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,N,...) N
typedef long long int i64;
int gt_i64(int count,...){
va_list ap;
i64 a,b;
int i;
va_start(ap,count);
a=va_arg(ap,i64);
if (count<=1) return 0;
for (i=1; i<count; ++i){
b=va_arg(ap,i64);
if (a<=b) return 0;
a=b;
}
va_end(ap);
return 1;
}
#define GT(...) gt_i64(VA_NUM_ARGS(__VA_ARGS__),__VA_ARGS__)
int main(void){
printf("%d\n",GT(30,20,10));
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 15:26 +0100 |
| Message-ID | <87r3apembn.fsf@bsb.me.uk> |
| In reply to | #90578 |
BartC <bc@freeuk.com> writes:
> On 19/07/2016 14:00, Ben Bacarisse wrote:
>> ...about (> foo bar baz quux)
>>
>> BartC <bc@freeuk.com> writes:
>>> On 19/07/2016 07:23, Udyant Wig wrote:
>> <snip>
>>>> Do you implicitly accept my point about
>>>>
>>>> foo > bar > baz > quux
>>>>
>>>> ?
>>>
>>> Yes, but it's the same one as using +, which can be emulated even in C
>>> by using a function gt(foo,bar,baz,quuz).
>>
>> How?
>
> I was thinking of something like the code below.
>
> The GT() macro is for signed ints; separate versions are needed for
> different primitive types (but not for different widths).
Ah, right. A macro not a function. You definitely need to start with a
macro.
> This version is limited to 10 operands but that can be probably be
> increased to any reasonable number. (But by then, you'd want a
> function that takes an arrray really.)
>
> The example above would be written as GT(foo,bar,baz,quuz).
>
> #include <stdio.h>
> #include <stdarg.h>
>
> #define VA_NUM_ARGS(...) VA_NUM_ARGS_IMPL(__VA_ARGS__,\
> 10,9,8,7,6,5,4,3,2,1)
> #define VA_NUM_ARGS_IMPL(_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,N,...) N
>
> typedef long long int i64;
>
> int gt_i64(int count,...){
> va_list ap;
> i64 a,b;
> int i;
>
> va_start(ap,count);
>
> a=va_arg(ap,i64);
And this does not emulate the is either. You've decided on a particular
type.
Not only will floats and double not work (let alone rationals and so on)
but you have the problem that GT(1,2,3) may be undefined because of the
default argument promotions. If it's system-specific C you might be
alright.
When thinking over what you'd said, I decided that what you have here is
probable the closest you can get, but it's not what I'd call "emulated
... in C using a function".
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 15:57 +0100 |
| Message-ID | <nmlf5j$nc9$1@dont-email.me> |
| In reply to | #90580 |
On 19/07/2016 15:26, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: BC: >>>> Yes, but it's the same one as using +, which can be emulated even in C >> I was thinking of something like the code below. >> >> The GT() macro is for signed ints; separate versions are needed for >> different primitive types (but not for different widths). > > Ah, right. A macro not a function. You definitely need to start with a > macro. >> a=va_arg(ap,i64); > > And this does not emulate the is either. You've decided on a particular > type. > > Not only will floats and double not work I mentioned that above. C is statically typed. You might need GT, GTU and GTF versions as GT is not built-in to the language as an automatically overloaded operator or variadic function. > (let alone rationals and so on) I'm losing track of what your argument is here. Yes, C and Lisp are different languages; there's no disagreement there. I said above this could be emulated 'even in C', suggesting other more capable languages (in terms of dynamic types and built-in bigints and so on) would have less problem. I was under the impression that this was about Lisp syntax vs Normal syntax, not C vs a completely different language. > but you have the problem that GT(1,2,3) may be undefined because of the > default argument promotions. If it's system-specific C you might be > alright. That's a problem with any variadic C function. With printf too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 17:13 +0100 |
| Message-ID | <87a8hdehcv.fsf@bsb.me.uk> |
| In reply to | #90585 |
BartC <bc@freeuk.com> writes: > On 19/07/2016 15:26, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > > BC: >>>>> Yes, but it's the same one as using +, which can be emulated even in C > >>> I was thinking of something like the code below. >>> >>> The GT() macro is for signed ints; separate versions are needed for >>> different primitive types (but not for different widths). >> >> Ah, right. A macro not a function. You definitely need to start with a >> macro. > >>> a=va_arg(ap,i64); >> >> And this does not emulate the is either. You've decided on a particular >> type. >> >> Not only will floats and double not work > > I mentioned that above. C is statically typed. You might need GT, GTU > and GTF versions as GT is not built-in to the language as an > automatically overloaded operator or variadic function. And how many for all the combinations of gt(int, double, int, float), gt(double, double, int, long int) and so on up to, I don't know, 20 arguments? And how do you arrange for the right one to be called? >> (let alone rationals and so on) > > I'm losing track of what your argument is here. Yes, C and Lisp are > different languages; there's no disagreement there. It was *your* clam that a C *function* gt(foo,bar,baz) can emulate Lisp's > function (at least it seemed to be). My argument has been simply to show the differences so anyone else (you won't be persuaded, I know) can decide for themselves if this is "emulating". > I said above this could be emulated 'even in C', suggesting other more > capable languages (in terms of dynamic types and built-in bigints and > so on) would have less problem. > > I was under the impression that this was about Lisp syntax vs Normal > syntax, not C vs a completely different language. For me it was about you saying (if my editing does not distort your meaning): (> foo bar baz quux) can be emulated even in C by using a function gt(foo,bar,baz,quuz). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 18:14 +0100 |
| Message-ID | <nmln65$l8b$1@dont-email.me> |
| In reply to | #90592 |
On 19/07/2016 17:13, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> I mentioned that above. C is statically typed. You might need GT, GTU >> and GTF versions as GT is not built-in to the language as an >> automatically overloaded operator or variadic function. > > And how many for all the combinations of gt(int, double, int, float), > gt(double, double, int, long int) and so on up to, I don't know, 20 > arguments? And how do you arrange for the right one to be called? I stated there would be three versions, GT, GTU and GTF for signed, unsigned and float respectively. The programmer decides which one to call, and is responsible that the arguments are compatible. In the same way that an argument needs to match a printf format. If you're saying this would be a bit of a pig to use in C, then you're right. If the language was less intransigent about adding interesting new features, then this sort of thing could have had more language support. (But if still statically typed, then it would need to determine the dominant type of the N mixed-type expressions being compared, then they are coerced as needed to that type.) (Although I don't consider being able to apply binary ops to a fixed number of N operands a particular useful feature; not one that would be worth the effort. My own languages allow constructs such as a>b>c or a=b<=c directly; I think I've used them once so far. While allowing N to be a runtime value starts to impinge on list processing. But you don't really need that to be built-in in C; you'd use a more apt language (I was quite impressed with K in a way that I wasn't with Lisp, although the former is probably harder to read).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 19:20 +0100 |
| Message-ID | <87h9blcww6.fsf@bsb.me.uk> |
| In reply to | #90610 |
BartC <bc@freeuk.com> writes: > On 19/07/2016 17:13, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> I mentioned that above. C is statically typed. You might need GT, GTU >>> and GTF versions as GT is not built-in to the language as an >>> automatically overloaded operator or variadic function. >> >> And how many for all the combinations of gt(int, double, int, float), >> gt(double, double, int, long int) and so on up to, I don't know, 20 >> arguments? And how do you arrange for the right one to be called? > > I stated there would be three versions, GT, GTU and GTF for signed, > unsigned and float respectively. The programmer decides which one to > call, and is responsible that the arguments are compatible. In the > same way that an argument needs to match a printf format. So more reasons why C's gt(foo,bar,baz,quux) emulate Lisp's (> foo bar baz quux) then? All you've done since saying that it does is explain exactly why it does not. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 19:46 +0100 |
| Message-ID | <nmlsho$9du$1@dont-email.me> |
| In reply to | #90618 |
On 19/07/2016 19:20, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 19/07/2016 17:13, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> I mentioned that above. C is statically typed. You might need GT, GTU >>>> and GTF versions as GT is not built-in to the language as an >>>> automatically overloaded operator or variadic function. >>> >>> And how many for all the combinations of gt(int, double, int, float), >>> gt(double, double, int, long int) and so on up to, I don't know, 20 >>> arguments? And how do you arrange for the right one to be called? >> >> I stated there would be three versions, GT, GTU and GTF for signed, >> unsigned and float respectively. The programmer decides which one to >> call, and is responsible that the arguments are compatible. In the >> same way that an argument needs to match a printf format. > > So more reasons why C's gt(foo,bar,baz,quux) emulate Lisp's (> foo bar > baz quux) then? All you've done since saying that it does is explain > exactly why it does not. Most of your arguments are along the lines of: * Lisp can do > on bignums and C can't * List can do > on rationals and C can't * List can do > on mixed types such as (integer, float, bignum, rational, fixnum,... whatever other numeric types there are), whereas C can only deal with mixed integer and float (and only two at time) This is really little to do with doing (> a b c), but everything to do with Lisp being (I guess) a dynamically typed language with more high-level numeric types. I put forward a solution for C that is necessarily cruder and more restricted than the Lisp equivalent, because of C's static nature. You didn't like that. I suggested that feature could be added to a language, even with the right syntax: (> a b c ) but if the language is statically typed and doesn't have high level numeric types built-in, it will still have some restrictions (a, b and c can be mixed types but the types must be compatible). But presumably that wouldn't be enough either! I guess nothing will satisfy you that (> a b c) can be successfully implemented anywhere else unless someone produces an actual Lisp implementation, and can therefore write '(> a b c). My own dissatisfaction with Lisp is with its syntax when I try and use it to write conventional programs in it. I don't become dissatisfied with conventional syntax because I can't do (+ a b c) because it is rarely needed, and when it is I just write a+b+c. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-20 02:44 +0100 |
| Message-ID | <8760s1ccbv.fsf@bsb.me.uk> |
| In reply to | #90623 |
BartC <bc@freeuk.com> writes: > On 19/07/2016 19:20, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 19/07/2016 17:13, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> I mentioned that above. C is statically typed. You might need GT, GTU >>>>> and GTF versions as GT is not built-in to the language as an >>>>> automatically overloaded operator or variadic function. >>>> >>>> And how many for all the combinations of gt(int, double, int, float), >>>> gt(double, double, int, long int) and so on up to, I don't know, 20 >>>> arguments? And how do you arrange for the right one to be called? >>> >>> I stated there would be three versions, GT, GTU and GTF for signed, >>> unsigned and float respectively. The programmer decides which one to >>> call, and is responsible that the arguments are compatible. In the >>> same way that an argument needs to match a printf format. >> >> So more reasons why C's gt(foo,bar,baz,quux) emulate Lisp's (> foo bar >> baz quux) then? All you've done since saying that it does is explain >> exactly why it does not. > > Most of your arguments are along the lines of: > > * Lisp can do > on bignums and C can't > > * List can do > on rationals and C can't > > * List can do > on mixed types such as (integer, float, bignum, > rational, fixnum,... whatever other numeric types there are), > whereas C can only deal with mixed integer and float (and only > two at time) Pretty much. > This is really little to do with doing (> a b c), but everything to do > with Lisp being (I guess) a dynamically typed language with more > high-level numeric types. Yes, that's very much it. > I put forward a solution for C that is necessarily cruder and more > restricted than the Lisp equivalent, because of C's static nature. You > didn't like that. No I loved it. It's the way C does functions -- very much differently to the way Lisp does them. You've neatly summaried the main ways in which your suggested gt(a,b,c,d) does not emulate Lisp's (> a b c d). We agree on it all except for what you seem to mean by "emulate". <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-20 10:59 +0100 |
| Message-ID | <nmni31$10q$1@dont-email.me> |
| In reply to | #90634 |
On 20/07/2016 02:44, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > No I loved it. It's the way C does functions -- very much differently > to the way Lisp does them. You've neatly summaried the main ways in > which your suggested gt(a,b,c,d) does not emulate Lisp's (> a b c d). > We agree on it all except for what you seem to mean by "emulate". Here's a non-function version: #include <iso646.h> (a>b and b>c and c>d) If you were transcribing a general purpose algorithm from Lisp (so that it wasn't full of Lispisms that would be impossible to translate to any other language except Lisp), but it happened to use constructs like (> a b c) in a couple of places, then the result would work. (However Lisp would be the last language I would use to convert algorithms from. The language is all over the place. If I saw this: a[i] = x in most languages then I can guess it's replacing an element of a list with x. In Lisp, I don't even know what that would look like. Is it this: (aset a i x) or is it: (setf (aref a i) x) which don't even work on actual lists. Lisp texts could have been written by JRR Tolkien being so full of weird and wonderful functions and invocations.) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 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