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 4 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-20 03:07 -0700 |
| Message-ID | <a30a7c6d-c09a-4cdb-91b9-48abcf0be6da@googlegroups.com> |
| In reply to | #90644 |
On Wednesday, July 20, 2016 at 11:00:09 AM UTC+1, Bart wrote: > On 20/07/2016 02:44, Ben Bacarisse wrote: > 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. > But that's another way of saying that Lisp is in fact a powerful, expressive high level language. If we could easily and trivially translate Lisp programs to C, or assembler, then there wouldn't be much of a case for the language at all. Just use C. If it's easy to go from C to Lisp, but not vice versa (other than by writing a Lisp interpeter in C), then that means that Lisp can express a superset of C-expressible algorithms, and there's a case for using it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-21 01:44 +0100 |
| Message-ID | <87zipbbz1g.fsf@bsb.me.uk> |
| In reply to | #90644 |
BartC <bc@freeuk.com> writes: > 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) That's not the same as the Lisp due (in part) to the multiple evaluation of the sub-expressions and the short-circuit semantics of &&. (But what's the significance of using the iso464 spellings?) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-21 18:58 +0530 |
| Message-ID | <nmqimo$ads$1@dont-email.me> |
| In reply to | #90644 |
On 07/20/2016 03:29 PM, BartC wrote: > (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. I would think it was setting an element of an array. > In Lisp, I don't even know what that would look like. You could ask. On the other hand, one of your forms was correct, if misapplied. > Is it this: > > (aset a i x) > > or is it: > > (setf (aref a i) x) > > which don't even work on actual lists. Yes. Why would you want to use array operations on lists? ASET is not mentioned in the indices of the Common Lisp HyperSpec. So, the second one is the form you would use if you had an array. > Lisp texts could have been written by JRR Tolkien being so full of > weird and wonderful functions and invocations.) Hmm. I like the rich worlds described therein myself. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-21 17:20 +0100 |
| Message-ID | <nmqsod$f6p$1@dont-email.me> |
| In reply to | #90719 |
On 21/07/2016 14:28, Udyant Wig wrote: > On 07/20/2016 03:29 PM, BartC wrote: >> a[i] = x >> >> in most languages then I can guess it's replacing an element of a list >> with x. > > I would think it was setting an element of an array. >> which don't even work on actual lists. > > Yes. Why would you want to use array operations on lists? Lists and arrays are the same thing to me and expect to be able randomly access either. If a list is a linked list, then I call it a linked list. But now I remember there is (nth i a) that can be used to index lists (I This is what I mean about Lisp being untidy: a normal language would use a single bit of syntax such as [] to be able to index anything that can be indexed. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-21 20:52 +0100 |
| Message-ID | <87bn1qbwfx.fsf@bsb.me.uk> |
| In reply to | #90723 |
BartC <bc@freeuk.com> writes: > On 21/07/2016 14:28, Udyant Wig wrote: >> On 07/20/2016 03:29 PM, BartC wrote: > >>> a[i] = x >>> >>> in most languages then I can guess it's replacing an element of a list >>> with x. >> >> I would think it was setting an element of an array. > >>> which don't even work on actual lists. >> >> Yes. Why would you want to use array operations on lists? > > Lists and arrays are the same thing to me and expect to be able > randomly access either. When you want to hide the distinction (and that's not always wise) you can use (elt sequence index). > If a list is a linked list, then I call it a > linked list. > > But now I remember there is (nth i a) that can be used to index lists (I > > This is what I mean about Lisp being untidy: a normal language would > use a single bit of syntax such as [] to be able to index anything > that can be indexed. That's elt. aref and nth are used when the asymptotic cost might matter. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-21 21:14 +0100 |
| Message-ID | <nmraen$47o$1@dont-email.me> |
| In reply to | #90739 |
On 21/07/2016 20:52, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 21/07/2016 14:28, Udyant Wig wrote: >>> On 07/20/2016 03:29 PM, BartC wrote: >> >>>> a[i] = x >>>> >>>> in most languages then I can guess it's replacing an element of a list >>>> with x. >>> >>> I would think it was setting an element of an array. >> >>>> which don't even work on actual lists. >>> >>> Yes. Why would you want to use array operations on lists? >> >> Lists and arrays are the same thing to me and expect to be able >> randomly access either. > > When you want to hide the distinction (and that's not always wise) you > can use (elt sequence index). > >> If a list is a linked list, then I call it a >> linked list. >> >> But now I remember there is (nth i a) that can be used to index lists (I >> >> This is what I mean about Lisp being untidy: a normal language would >> use a single bit of syntax such as [] to be able to index anything >> that can be indexed. > > That's elt. aref and nth are used when the asymptotic cost might matter. This is the point I keep making. Looking up elt, I came across this comment in a forum: "There are an absurd number of accessors for arrays and sequences: I find it almost impossible to know which to use." I now about ETH, NTH, AREF, CHAR, SCHAR; who knows how many more there are. And there appear to be dedicated accessors for special kinds of lists and arrays and vectors (eg. BIT and SBIT). This is not an elegant design. Most 'normal' languages use one kind of accessor, such as []. (I use a[i] to randomly access or set any kind of indexable list, string, homogeneous array, bit array, ... I sometimes use a.[i] to access things normally considered compound objects: strings (as chars rather than substrings), records/structs, ints (extracting bits)... Just two types of access. Use a[i..j] instead and you get a slice. A small number of concepts that can be used everywhere. Not the most elegant language but in this regard it is far ahead of Lisp.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-21 13:23 -0700 |
| Message-ID | <lnbn1qkaee.fsf@kst-u.example.com> |
| In reply to | #90740 |
BartC <bc@freeuk.com> writes:
> On 21/07/2016 20:52, Ben Bacarisse wrote:
[...]
>> That's elt. aref and nth are used when the asymptotic cost might matter.
>
> This is the point I keep making.
[...]
Yes, but why do you keep making it *here*?
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-21 21:50 +0100 |
| Message-ID | <nmrcim$bsl$1@dont-email.me> |
| In reply to | #90741 |
On 21/07/2016 21:23, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 21/07/2016 20:52, Ben Bacarisse wrote: > [...] >>> That's elt. aref and nth are used when the asymptotic cost might matter. >> >> This is the point I keep making. > [...] > > Yes, but why do you keep making it *here*? > The subthread started as C versus Lisp. I'm defending the language for a change... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-22 12:52 +0200 |
| Message-ID | <nmstt5$iut$1@dont-email.me> |
| In reply to | #90741 |
Le 21/07/2016 à 22:23, Keith Thompson a écrit : > BartC <bc@freeuk.com> writes: >> On 21/07/2016 20:52, Ben Bacarisse wrote: > [...] >>> That's elt. aref and nth are used when the asymptotic cost might matter. >> >> This is the point I keep making. > [...] > > Yes, but why do you keep making it *here*? > Note that Mr Thompson says that to people that arguing about the advant ages of C. The people that like lisp do not get any messages like this.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-22 04:03 -0700 |
| Message-ID | <3646569a-0d08-47e4-beb8-322f281d246b@googlegroups.com> |
| In reply to | #90768 |
On Friday, July 22, 2016 at 11:52:29 AM UTC+1, jacobnavia wrote: > Le 21/07/2016 à 22:23, Keith Thompson a écrit : > > BartC <bc@freeuk.com> writes: > >> On 21/07/2016 20:52, Ben Bacarisse wrote: > > [...] > >>> That's elt. aref and nth are used when the asymptotic cost might matter. > >> > >> This is the point I keep making. > > [...] > > > > Yes, but why do you keep making it *here*? > > > Note that Mr Thompson says that to people that arguing about the advant > ages of C. > > The people that like lisp do not get any messages like this. > They terrorise other people with talk of lambda calculus, closures, and being able to prove functions correct by reasoning about them. There is genuinely a powerful theoretical basis to Lisp. But few people can produce efficient, correct, large programs using Lisps or similar languages, to tight deadlines and meeting inevitably slightly fluid specifications. That's also true of all other computer languages, of course.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-22 23:56 +0530 |
| Message-ID | <nmtogm$iul$1@dont-email.me> |
| In reply to | #90740 |
On 07/22/2016 01:44 AM, BartC wrote: > This is the point I keep making. Which is? > Looking up elt, I came across this comment in a forum: > > "There are an absurd number of accessors for arrays and sequences: I > find it almost impossible to know which to use." I could find random opinionated flamebaits on the Internet, too. > I now about ETH, NTH, AREF, CHAR, SCHAR; who knows how many more there > are. You could look them up in the standard and know for sure. > And there appear to be dedicated accessors for special kinds of lists > and arrays and vectors (eg. BIT and SBIT). > > This is not an elegant design. On the contrary, I find it to be _very_ elegant design. > Most 'normal' languages use one kind of accessor, such as []. > > (I use a[i] to randomly access or set any kind of indexable list, > string, homogeneous array, bit array, ... > > I sometimes use a.[i] to access things normally considered compound > objects: strings (as chars rather than substrings), records/structs, > ints (extracting bits)... > > Just two types of access. Use a[i..j] instead and you get a slice. A > small number of concepts that can be used everywhere. > > Not the most elegant language but in this regard it is far ahead of > Lisp.) Such syntax as horrible as a.[i] and you speak of elegance? -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-22 20:09 +0100 |
| Message-ID | <nmtr1t$s8i$1@dont-email.me> |
| In reply to | #90804 |
On 22/07/2016 19:26, Udyant Wig wrote: > On 07/22/2016 01:44 AM, BartC wrote: >> I sometimes use a.[i] to access things normally considered compound > Such syntax as horrible as a.[i] and you speak of elegance? (I copied a.[] syntax from Algol60, my first language, where it was used to extract characters of strings which were otherwise an indivisible type. The a.b syntax, using a dot selector operator, is also very extensively used in many languages for extracting members of compounds types in similar ways. So there is logic involved, it follows existing usage, and it's used polymorphically. Unlike the Lisp which, taking the example of extracting bit i from integer a, or a.[i], I believe would be: (logbitp i a) with presumably a different method for strings and a different one yet for records. Lisp can't even make up its mind whether the index comes first or second!) (Anyway I didn't say my language was elegant. Only more so than Lisp.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-22 23:49 +0530 |
| Message-ID | <nmto2s$hcg$1@dont-email.me> |
| In reply to | #90723 |
On 07/21/2016 09:50 PM, BartC wrote: > On 21/07/2016 14:28, Udyant Wig wrote: >> On 07/20/2016 03:29 PM, BartC wrote: > >>> a[i] = x >>> >>> in most languages then I can guess it's replacing an element of a >>> list with x. >> >> I would think it was setting an element of an array. > >>> which don't even work on actual lists. >> >> Yes. Why would you want to use array operations on lists? > > Lists and arrays are the same thing to me and expect to be able > randomly access either. If a list is a linked list, then I call it a > linked list. Lists are arrays are so different in their semantics that I fail to see how you can consider them the same thing. > But now I remember there is (nth i a) that can be used to index lists > (I ... forgot a closing paren?) > This is what I mean about Lisp being untidy: a normal language would > use a single bit of syntax such as [] to be able to index anything > that can be indexed. I take it that C is not a normal language by this argument. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-22 20:37 +0100 |
| Message-ID | <nmtsm0$2fq$1@dont-email.me> |
| In reply to | #90803 |
On 22/07/2016 19:19, Udyant Wig wrote: > On 07/21/2016 09:50 PM, BartC wrote: >> This is what I mean about Lisp being untidy: a normal language would >> use a single bit of syntax such as [] to be able to index anything >> that can be indexed. > > I take it that C is not a normal language by this argument. Why not? Anything that C can index, can be indexed with []. Do you have in mind something in C that cannot be indexed with []? (Things such as bit-arrays which are not built-in to the language don't count. There you might well need to bolt together accessors from macros and functions, which will need different names for different types. But for things which are part of the language, you expect a consistent, polymorphic interface. And in a language such as C++, that provides a way of extending that interface - use of [] and so on - even to user-defined types.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-19 19:16 +0200 |
| Message-ID | <nmln8p$l5c$1@dont-email.me> |
| In reply to | #90592 |
Le 19/07/2016 à 18:13, Ben Bacarisse a écrit : > 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? Very simple. You start at the left with the first argument. You apply your function with the second one. Any necessary promotions will be done by the add function, following the rule I had in my lisp interpreter: more precision overrides less precision. Then you apply add to the result and the third argument, making again all the necessary promotions. The result will be written in the most precise form, or, if there is any complex numbers, in complex form. Such a function can be written in C, and I have written it back then. But the big problem with such a way of programming, is that you have to figure out what the hell is the type of the argument you are receiving. Numbers must be "boxed" into some type of package that describes the type of the number. You have to test the types of the two arguments and then decide accordingly. This takes time and is by nature inefficient. C gives you access to this way of programming but makes it difficult to do that. It is better (C's philosophy I would say) to use single types, machine types, and use that. C looses the immediacy of the interpreted languages, and must be compiled and examoined by the machine before being accepted. The machine scans all the source code and rejects any wrong constructs. In an interpreter, the interpreter scans only the parts of the program that it is interpreting. Other parts of your program that may contain typos or other errors, are never scanned by the interpreter and can hide bugs that will appear later, much later maybe.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-19 19:17 +0100 |
| Message-ID | <87mvldcx0s.fsf@bsb.me.uk> |
| In reply to | #90611 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 19/07/2016 à 18:13, Ben Bacarisse a écrit : >> 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? > > Very simple. You start at the left with the first argument. You apply > your function with the second one. Any necessary promotions will be > done by the add function, following the rule I had in my lisp > interpreter: more precision overrides less precision. > > Then you apply add to the result and the third argument, making again > all the necessary promotions. The result will be written in the most > precise form, or, if there is any complex numbers, in complex form. > > Such a function can be written in C, and I have written it back then. So what? The claim (by BartC) was that C's gt(foo,bar,baz,quux) emulated Lisp's (> foo bar baz quux). That Lisp can be emulated (indeed implemented) in C is not at issue. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-19 21:07 +0200 |
| Message-ID | <nmltp7$d9s$1@dont-email.me> |
| In reply to | #90617 |
Le 19/07/2016 à 20:17, Ben Bacarisse a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> Such a function can be written in C, and I have written it back then. > > So what? The claim (by BartC) was that C's gt(foo,bar,baz,quux) > emulated Lisp's (> foo bar baz quux). That Lisp can be emulated (indeed > implemented) in C is not at issue. > > <snip> > Yes, [snip] In the snipped part I said that this way of programming is grossly inefficient. I see that you consider better to snip that part.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-20 02:36 +0100 |
| Message-ID | <87bn1tccqh.fsf@bsb.me.uk> |
| In reply to | #90624 |
jacobnavia <jacob@jacob.remcomp.fr> writes: <snip> > In the snipped part I said that this way of programming is grossly > inefficient. > > I see that you consider better to snip that part. I snip things when I agree with then because there's not point in quoting it all and then saying "yes". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-19 07:27 -0700 |
| Message-ID | <3638edb5-3c83-4c88-a4e3-c73e3bff3f5c@googlegroups.com> |
| In reply to | #90578 |
On Tuesday, July 19, 2016 at 3:01:20 PM UTC+1, Bart wrote: > > 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.) > You don't "get it". Lisp is the list processing language. All the data is lists, or lists of lists. They happen to be linked lists, but thats' just an implementation detail. The point is that a list is arbitrarily long, and can contain child lists nested arbitrarily deep. Some functions might be only defined for flat lists of scalars, sometimes with a set number of members, but it's a runtime error to pass an invalid list to such a function, there are no high level "types" other than lists. Functions are also lists, and can be treated as data. So Lisp allows reflection, or self-modifying code if you want to be cheeky about it.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-19 16:27 +0100 |
| Message-ID | <nmlgt4$tr6$1@dont-email.me> |
| In reply to | #90581 |
On 19/07/2016 15:27, Malcolm McLean wrote: > On Tuesday, July 19, 2016 at 3:01:20 PM UTC+1, Bart wrote: >> >> 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.) >> > You don't "get it". > > Lisp is the list processing language. All the data is lists, or lists of lists. > They happen to be linked lists, but thats' just an implementation detail. No, at some point there must be a something that isn't a list. Such as a number, string or symbol. Those can be organised into lists. So the program now manipulates atomic types or lists, not very different from many other languages. However, Lisp also allows code as data, which is what sets it apart (apart from the odd syntax). But it can also be what makes Lisp programs impossible to follow. So that's one thing - well two things if you add the syntax - that make Lisp hard. Three things actually if you add in also the sheer comprehensiveness of the language. Several ways of testing two things for equality. Several ways of doing an assignment. 28 (or however many) different ways of specifying a loop, with umpteen options. You can have dynamic types or you can statically declare them. Lists are linked lists except when you declare arrays of contiguous elements. 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! -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 4 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