Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #133735 > unrolled thread
| Started by | skybuck2000@hotmail.com |
|---|---|
| First post | 2018-08-13 12:53 -0700 |
| Last post | 2018-10-10 18:24 -0700 |
| Articles | 20 on this page of 354 — 27 participants |
Back to article view | Back to comp.lang.c
>< swap operator skybuck2000@hotmail.com - 2018-08-13 12:53 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-08-13 16:05 -0400
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-13 13:46 -0700
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-08-14 11:19 +0300
Re: >< swap operator skybuck2000@hotmail.com - 2018-08-14 06:16 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 07:50 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 16:59 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 10:46 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 20:03 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 11:37 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 21:16 +0200
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-14 11:32 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 16:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-15 11:32 +0200
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-01 07:46 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 05:20 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 13:58 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 14:08 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-02 15:35 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:43 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:51 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:08 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 10:52 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 17:57 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 13:27 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 11:52 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 20:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 15:56 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:05 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:26 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:36 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:47 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:14 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:37 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:02 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:25 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 10:52 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 14:29 +0200
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:52 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:31 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 16:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:43 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 04:25 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 20:44 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 11:53 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 05:15 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 10:56 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:47 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:01 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-04 22:15 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 16:19 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 21:42 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 15:01 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 23:59 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:54 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 18:03 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 21:08 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 20:31 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-05 15:59 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 21:18 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 12:19 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 19:49 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 12:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 14:19 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 06:56 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:30 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-09 13:17 +0200
C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:07 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 14:27 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 00:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-10 02:03 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 01:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 02:09 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 12:39 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 16:24 +0100
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 15:55 +0000
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 09:42 -0700
Re: C idioms Wouter Verhelst <w@uter.be> - 2018-10-11 19:23 +0200
Re: C idioms jameskuyper@alumni.caltech.edu - 2018-10-11 11:11 -0700
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 12:05 -0700
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 17:53 +0100
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 10:38 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-12 00:14 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 19:26 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 16:38 +0200
Re: C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 15:23 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 20:31 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 20:18 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:11 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-09 20:50 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:58 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 22:34 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:10 +0200
Re: C idioms (Was: >< swap operator) jameskuyper@alumni.caltech.edu - 2018-10-09 14:45 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:07 +0200
Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 07:56 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 10:32 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Ike Naar <ike@iceland.freeshell.org> - 2018-10-10 13:44 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:52 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Wouter Verhelst <w@uter.be> - 2018-10-10 17:47 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:18 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:22 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 23:58 +0200
Re: Hmmm... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 07:51 -0600
Re: Hmmm... gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:53 +0000
Re: Hmmm... David Brown <david.brown@hesbynett.no> - 2018-10-10 17:21 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:57 +0000
Re: C idioms (Was: >< swap operator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-10 12:29 -0400
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:07 +0200
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-09 14:50 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:13 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:56 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 15:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 15:17 +0100
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:49 +0000
Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:59 +0000
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) Bart <bc@freeuk.com> - 2018-10-10 16:09 +0100
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) nobody@example.org (Scott) - 2018-10-10 17:29 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 16:01 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:29 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-10 17:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 17:11 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 23:15 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:16 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 23:23 +0100
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:31 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 15:32 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:24 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 10:52 +0200
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 09:59 -0600
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:26 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:48 +0000
Return values of fork() (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:51 +0000
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 15:20 +0000
You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:28 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:23 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:22 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 15:58 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:17 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 16:42 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) Wouter Verhelst <w@uter.be> - 2018-10-11 16:53 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 20:11 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:20 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:15 -0700
Re: Return values of fork() Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-11 14:42 -0600
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-09 16:18 -0600
Re: C idioms gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 22:28 +0000
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:58 +0000
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 07:48 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 16:42 +0100
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:40 +0200
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 12:38 -0700
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 23:41 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:38 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 15:04 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:37 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 16:58 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 12:17 -0400
Grammar police! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 20:37 +0000
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 09:31 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 18:09 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 14:05 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 22:35 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:56 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-08 10:48 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 12:09 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 16:00 +0000
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:44 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:39 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 20:08 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:22 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-09 09:25 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 20:43 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 20:15 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 22:26 +0200
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 21:09 +0000
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 15:18 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 07:55 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:24 +0200
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:19 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 16:26 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-10 10:59 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 19:53 +0100
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 18:00 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:10 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 11:29 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-08 04:41 -0700
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:56 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 08:36 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:34 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 21:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 22:00 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 00:47 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 01:11 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 02:47 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-09 00:49 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 11:28 +0100
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:00 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:28 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:49 -0700
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 20:00 -0600
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:07 -0700
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 23:35 +0000
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:49 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-06 16:18 +0200
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-06 14:48 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 12:53 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:38 +0000
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 15:56 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 16:53 -0700
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-07 17:07 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:24 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:30 +0100
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 19:12 -0600
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 18:26 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 19:41 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:05 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 02:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-07 12:41 +0200
100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 00:22 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 01:55 +0100
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:58 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 11:51 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 13:09 +0100
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 05:26 -0700
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 05:40 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:49 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 06:27 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 12:47 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 09:03 -0400
Re: 100% of the user base... (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:47 +0000
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 10:17 +0200
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:20 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 10:58 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 12:09 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 03:11 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 07:56 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 14:25 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 08:39 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:47 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:30 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:41 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:56 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:00 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 12:34 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:48 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 13:55 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-05 11:20 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:45 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 21:39 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 08:51 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-25 14:18 -0800
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 15:46 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:05 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:16 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:09 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:18 -0400
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:32 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:34 -0400
Of course it is crazy! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:17 +0000
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 18:30 +0000
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:48 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 15:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 13:55 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:14 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 16:18 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 17:27 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:28 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 14:46 +0000
When pigs fly... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 16:10 +0000
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:35 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:46 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:15 +0000
6K years??? (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 13:20 +0000
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:28 -0400
Re: 6K years??? (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-05 17:53 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:56 -0400
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:17 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:21 -0700
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:50 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:52 -0400
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 13:05 -0400
Re: 6K years??? (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:42 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 15:59 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:45 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-04 11:22 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 20:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:28 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:59 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-04 09:56 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 06:03 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 14:37 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 09:51 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 15:39 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:05 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:09 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 16:22 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:29 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 20:52 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 14:57 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 16:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 00:09 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 19:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:21 +0200
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:43 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:01 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 14:29 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:37 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:07 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:01 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:45 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:09 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:11 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:22 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:17 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:24 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 15:04 +0000
Re: >< swap operator Niles Rogoff <eternal-september@niles.xyz> - 2018-10-03 18:28 +0000
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-08-14 11:50 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-14 17:07 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:22 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:34 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:09 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:24 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 04:51 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 05:06 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-15 04:21 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-08-15 14:43 +0100
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 07:08 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-08-15 16:52 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-08-15 15:51 +0000
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-01 14:59 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-02 03:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 11:43 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-02 07:27 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:43 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 11:01 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:54 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 12:39 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:10 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:24 -0700
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-07 16:47 +0000 |
| Subject | Re: 100% of the user base... (Was: >< swap operator) |
| Message-ID | <8MquD.234727$HK2.171073@fx08.iad> |
| In reply to | #136380 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >On 10/07/2018 08:47 AM, Kenny McCormack wrote: >> In article <d07b719f-b186-475d-973a-2323bf8546b4@googlegroups.com>, >> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: >>> You all mock me today. The day of true Mocking will >>> come for all who reject Jesus Christ, and who mock His >>> servants, for He calls us His friends (John 15). >>> >>> A day of true Mocking (with a capital M). Judgment Day. >> >> See sig... > >Even the demons tremble at the name of Jesus. Both are figments of your imagination.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-05 10:17 +0200 |
| Message-ID | <r9jj8f-g8f.ln1@gangtai.home.grep.be> |
| In reply to | #136232 |
On 10/5/18 12:01 AM, Rick C. Hodgin wrote: > On Thursday, October 4, 2018 at 4:42:24 PM UTC-4, Bart wrote: >> What happens with: >> >> (a + b + c) += d; ? > > d is increased by the sum of a + b + c. > >> Sorry, I'm having some fun, but this is truly terrible idea. > > Don't you see what I'm doing here, Bart? Re-thinking programming, > removing artificial constraints, These "artificial constraints" have the advantage of making the language be readable. Making (a + b + c) += d really mean "d += (a + b + c)" might make sense in an RTL programming language, but really?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 09:20 +0200 |
| Message-ID | <pp73cc$oh5$1@dont-email.me> |
| In reply to | #136223 |
On 04/10/18 22:19, Rick C. Hodgin wrote: > On 10/4/2018 4:15 PM, David Brown wrote: >> On 04/10/18 20:01, Rick C. Hodgin wrote: >>> We're dealing with a new thing here, Ben. It doesn't already >>> exist in C. It would open the door to allowing things like >>> this: >>> >>> (a + b + c) = d; >>> >> >> What do you expect that statement to do? > > In this case, since d is a solid target, and (a + b + c) is an > expression, the equal operator would be able to see that the > assignment is to the right, rather than the left, and make it > so. > > In cases where you have "a = b;" it would infer or imply the > traditional "store b into a" form we always see. But if there > is a case around an operator where the solid target is on the > right, then use it. If that is all you have, it is pretty much useless. "(a + b + c) = d" becomes a confusing way to write "d = (a + b + c)". > >> I know of one language (MetaPost) that lets you write statements like >> that, but it is not a very C-like language. I am not sure that it is >> the kind of thing you could add to a language without massive changes >> to its character. > > Agreed. It's a thing for CAlive I can see already. :-) It's > almost no additional work to add either. > It is no work, because you are not adding anything useful. In Metapost (and Metafont), you have a /declarative/ language, not an imperative one (like C and CAlive). So you can write: a + b = 3; 12 = 2 * a - b; and the language will conclude that a == 5 and b == 2. That is a very powerful feature. If you can figure out how to integrate something like that into your language in a practical and natural way, /then/ you would be onto something new. It may be possible to use such declarations for optimisation hints, or for static or run-time checking.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 10:58 +0100 |
| Message-ID | <qBGtD.410705$Vv.319136@fx20.am4> |
| In reply to | #136242 |
On 05/10/2018 08:20, David Brown wrote: > In Metapost (and Metafont), you have a /declarative/ language, not an > imperative one (like C and CAlive). So you can write: > > a + b = 3; > 12 = 2 * a - b; > > and the language will conclude that a == 5 and b == 2. That is a very > powerful feature. I make it b = -2. But this sounds like it's just algebra; "=" has a different meaning from how it's normally used in programs. -- bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 12:09 +0200 |
| Message-ID | <pp7d8o$fmg$1@dont-email.me> |
| In reply to | #136246 |
On 05/10/18 11:58, Bart wrote: > On 05/10/2018 08:20, David Brown wrote: > >> In Metapost (and Metafont), you have a /declarative/ language, not an >> imperative one (like C and CAlive). So you can write: >> >> a + b = 3; >> 12 = 2 * a - b; >> >> and the language will conclude that a == 5 and b == 2. That is a very >> powerful feature. > > I make it b = -2. Ah, you spotted the intentional mistake I added to make sure people were reading carefully :-) > > But this sounds like it's just algebra; "=" has a different meaning from > how it's normally used in programs. > As I said, mp and mf are /declarative/ languages, not /imperative/ ones. In an imperative programming language, you give a series of commands to be carried out. You say /how/ the problem should be solved. In a declarative language, you make statements of fact or definition, and let the tool figure out how to get the results you want. You say what problem you want solved, not how to solve it. Obviously it does this by applying a series of rules or patterns, which will be limited. Metafont and Metapost are concerned primarily with drawings - metafont is for drawing fonts, and metapost extends that to general postscript drawings. So it will solve series of equations involving linear equations, bezier curves, and a few other types of equation - but not, for example, trigonometry.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-05 03:11 +0100 |
| Message-ID | <87a7ntnnvp.fsf@bsb.me.uk> |
| In reply to | #136210 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Thursday, October 4, 2018 at 12:47:11 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > Both sides are being updated. The normal nomenclature does not >> > lend well to this type of dual target. >> >> The C terminology works just fine. If C had >< as I am describing it, >> the standard would say that both operands must be modifiable lvalues and >> that the result is, itself, an lvalue denoting either the first operand. > > I still disagree. What do you disagree with? That a >< b should be an lvalue? Why? You have given no reason at all. You could simply say "because it's simpler". For example, C and C++ disagree on whether an assignment is or is not a lvalue. C takes the simpler option. Had you said just that when you first replied, I'd have left you too it. I was simply speculating on what could be done if the other choice were made. I have no horse in this race. > I think the same can be said with something like > ++x. It is a unary value that's computed, then stored. You could look up how the standard describes that form. It forbids ++(2 + 3) because (2 + 3) is not an lvalue. >> > Oh I really do. >> >> Then what was that long detailed post showing that a >< b >< c did not >> do as I said? > > When I posted that I thought you were under the mistaken impression > that it was an lvalue. That was and still is my position -- that a >< b should be an lvalue so that a >< b >< c is a rotate. Can you see how that would work even if you disagree with whatever it is you disagree with? > I misunderstood your post. My reply was to > correct what I thought was your misunderstanding. I don't see how. I have never espoused any other position than that a swap expression should be an lvalue. >> You'd understood me but decided to post about a slightly >> different swap -- one that was not an lvalue expression -- why? Just to >> be argumentative? > > As stated above, because I thought you misunderstood what Bart > and I had discussed previously. > > It was my mistake. I apologize. > >> > One returns the right hand value, the other the left. Much value. >> >> a ><= b returns the same value as b ><= a. Can you give an example of >> where it would be better to use one rather than the other? > > When either b or a are the return result of a function, or > the result of something computed. How so? I'd like an example. I can't see why one or other of a or b being something computed makes it worth while having two swap operators. We don't have two subtraction operators. If I want "the other one" I just write b - a rather than a - b. Why can't I do that with a swap if I want the "other" return? By the way, in C, a function call is not an lvalue so you can't write f() = 42; I'd expect the same to apply to a swap since it is, in effect, two assignments. I would expect both 2 >< 3 and f() >< g() to be constraint violations. > This opens up a whole new can of worms because it allows the > general concept of something like: > > (a + b + c) >< d; > > It's the same as "a + b + c = d" in normal math class. Why would you permit that? (a + b + c) is not an lvalue so you can't assign to it. > We're dealing with a new thing here, Ben. It doesn't already > exist in C. But it's /trivially/ new. There is no reason to make it complicated. You can't assign to 2 so why do you even consider swapping with 2? Why would you want to give that a meaning? > It would open the door to allowing things like > this: > > (a + b + c) = d; Why on earth would you allow that? What do think 2 = d; could possibly mean? Operators like =, +=, ++, -- and now >< all require lvalues. In the case of >< it needs two where the others need only one. That's the starting point and I can't see why you would want to start from any other position. The question of whether >< should itself be an lvalue comes later. I think it should. You, for some as yet unexplained reason, don't. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 07:56 -0400 |
| Message-ID | <pp7jia$ldi$1@dont-email.me> |
| In reply to | #136239 |
On 10/04/2018 10:11 PM, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> I think the same can be said with something like
>> ++x. It is a unary value that's computed, then stored.
>
> You could look up how the standard describes that form. It forbids
> ++(2 + 3) because (2 + 3) is not an lvalue.
Well, ++(2+3) is a perfectly valid statement. It's even re-
solved at compile-time. It's one of the artificial constraints
C places on things, and something I'm beginning to realize I
have issue with.
>>>> Oh I really do.
>>>
>>> Then what was that long detailed post showing that a >< b >< c did not
>>> do as I said?
>>
>> When I posted that I thought you were under the mistaken impression
>> that it was an lvalue.
>
> That was and still is my position -- that a >< b should be an lvalue so
> that a >< b >< c is a rotate. Can you see how that would work even if
> you disagree with whatever it is you disagree with?
I disagree with the lvalue constraint. It limits the utility of
the fundamental abilities which exist by imposing rules upon what
is otherwise perfectly valid behavior.
>> When either b or a are the return result of a function, or
>> the result of something computed.
>
> How so? I'd like an example. I can't see why one or other of a or b
> being something computed makes it worth while having two swap
> operators. We don't have two subtraction operators. If I want "the
> other one" I just write b - a rather than a - b. Why can't I do that
> with a swap if I want the "other" return?
>
> By the way, in C, a function call is not an lvalue so you can't write
>
> f() = 42;
Why not, Ben? f() = 42 is a perfectly valid statement in logic:
; f() = 42
call f
mov eax,42
It replaces the return result of f() with the value 42. Or, if
f() didn't have a return result because it was declared void f(void),
it assigns one in this instance, effectively creating a new function
that can be used with the integer return result.
> I'd expect the same to apply to a swap since it is, in effect, two
> assignments. I would expect both 2 >< 3 and f() >< g() to be constraint
> violations.
While both of those are effectively meaningless, they are valid
operations. They just don't convey any useful work. A compiler
would be justified in issuing a warning in those statements, but
I do not think a compiler should prevent them, because who knows
what the human developer is doing there. Maybe he/she needed to
add some pad space in their app for some code that will be in-
stalled in a later phase of the compilation, or at runtime? Why
impose those constraints upon people without resolution? Why not
setup a system which allows human developers to flourish, and
then also, if you want to, add some --safety switch, which lets
you then impose some rules to prevent newbies from shooting off
their leg too easily?
This whole concept of the swap operator and what it truly means
is opening my eyes to bypass some of C/C++'s limitations in this
way. And the thing about it is, as I've tried to explain to Bart,
is that it doesn't cost any more to allow these things, and if
they are not used then it won't ever be an issue for anybody.
But in those cases where they are used, there they are, another
tool in the toolbox.
[singing] "All they are is just a...nother tool in the box."
>> This opens up a whole new can of worms because it allows the
>> general concept of something like:
>>
>> (a + b + c) >< d;
>>
>> It's the same as "a + b + c = d" in normal math class.
>
> Why would you permit that? (a + b + c) is not an lvalue so you can't
> assign to it.
Because I'm not constrained by the limitations of C's way of do-
ing things in my thinking. I'm trying to look at fundamentals,
and create an extension or follow-on to C which incorporates the
many qualities of C which are fantastic.
>> We're dealing with a new thing here, Ben. It doesn't already
>> exist in C.
>
> But it's /trivially/ new. There is no reason to make it complicated.
It's not complicated at all. It's actually freeing.
> You can't assign to 2 so why do you even consider swapping with 2? Why
> would you want to give that a meaning?
Why not? The equal or swap operator is not an artifact of math.
It is an operation. You can assign 3 to the value 2. It would
be like having a small flash card with the number 2 written on
it with a big Sharpie, and then you strike through the 2 and now
write a number 3. The same is happening in code. It's just
functionally meaningless, but it's still perfectly valid.
>> It would open the door to allowing things like
>> this:
>>
>> (a + b + c) = d;
>
> Why on earth would you allow that? What do think 2 = d; could possibly
> mean?
It means you assign 2 to d, because d is a solid target, and 2
is not.
> Operators like =, +=, ++, -- and now >< all require lvalues.
In C/C++, yes.
> In the
> case of >< it needs two where the others need only one. That's the
> starting point and I can't see why you would want to start from any
> other position.
My point is that because there are two targets there, it's a
new thing. And my understanding of what that new things means
has opened up this whole new line of thinking about why we do
have artificial constraints in C. Many of them don't need to
be there, they are simply there by convention.
> The question of whether >< should itself be an lvalue comes later. I
> think it should. You, for some as yet unexplained reason, don't.
I think the concept of lvalue should be tossed outside of the
aforementioned --safety compilation mode.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-05 14:25 +0200 |
| Message-ID | <iq1k8f-1nm.ln1@gangtai.home.grep.be> |
| In reply to | #136251 |
On 10/5/18 1:56 PM, Rick C. Hodgin wrote: > On 10/04/2018 10:11 PM, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> I think the same can be said with something like >>> ++x. It is a unary value that's computed, then stored. >> >> You could look up how the standard describes that form. It forbids >> ++(2 + 3) because (2 + 3) is not an lvalue. > > Well, ++(2+3) is a perfectly valid statement. It's even re- > solved at compile-time. It's one of the artificial constraints > C places on things, and something I'm beginning to realize I > have issue with. What you mean to say is, (2+3)+1 which is not the same thing as "increase the constant value (2+3) by one". ++ means "change this variable". Since 2+3 is not a variable, that statement makes no sense at all. [...] >> How so? I'd like an example. I can't see why one or other of a or b >> being something computed makes it worth while having two swap >> operators. We don't have two subtraction operators. If I want "the >> other one" I just write b - a rather than a - b. Why can't I do that >> with a swap if I want the "other" return? >> >> By the way, in C, a function call is not an lvalue so you can't write >> >> f() = 42; > > Why not, Ben? f() = 42 is a perfectly valid statement in logic: > > ; f() = 42 > call f > mov eax,42 The way to express that (correctly) in C is f(), 42;
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 08:39 -0400 |
| Message-ID | <pp7m1k$6ld$1@dont-email.me> |
| In reply to | #136253 |
On 10/5/2018 8:25 AM, Wouter Verhelst wrote:
> On 10/5/18 1:56 PM, Rick C. Hodgin wrote:
>> On 10/04/2018 10:11 PM, Ben Bacarisse wrote:
>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>> I think the same can be said with something like
>>>> ++x. It is a unary value that's computed, then stored.
>>>
>>> You could look up how the standard describes that form. It forbids
>>> ++(2 + 3) because (2 + 3) is not an lvalue.
>>
>> Well, ++(2+3) is a perfectly valid statement. It's even re-
>> solved at compile-time. It's one of the artificial constraints
>> C places on things, and something I'm beginning to realize I
>> have issue with.
>
> What you mean to say is,
>
> (2+3)+1
>
> which is not the same thing as "increase the constant value (2+3) by one".
>
> ++ means "change this variable". Since 2+3 is not a variable, that
> statement makes no sense at all.
There's no reason to prevent it, and it does make sense. Look
at the operation sequence, Wouter:
01: load 2
02: load 3
03: add (results in new "t" the equivalent of 2 + 3)
04: increment t
If you brought it forward into assembly (rather than resolving
it at compile time), it would produce this on 32-bit x86:
01: mov eax,2
02: mov ebx,3
03: add eax,ebx
04: inc eax
Just because they're constants doesn't mean the fundamental
operation is invalid. It's perfectly valid. It's just silly
to do it this way. But, there's no reason why it couldn't
happen. Suppose the values were fundamental operations. We
would not have an issue with this:
float unit_circle_circumference = 2 * _PI * 1;
So why not allow other operations similarly:
// Two feet to dog house top, three feet for flag pole,
// and increase by one for some spacing.
int distance_off_ground = ++(2 + 3);
The values there are descriptive, rather than merely arbitrary
values. Why not allow them?
You're talking about an imposed constraint on the operation by
C, and not by the true abilities of the machine.
> [...]
>>> How so? I'd like an example. I can't see why one or other of a or b
>>> being something computed makes it worth while having two swap
>>> operators. We don't have two subtraction operators. If I want "the
>>> other one" I just write b - a rather than a - b. Why can't I do that
>>> with a swap if I want the "other" return?
>>>
>>> By the way, in C, a function call is not an lvalue so you can't write
>>>
>>> f() = 42;
>>
>> Why not, Ben? f() = 42 is a perfectly valid statement in logic:
>>
>> ; f() = 42
>> call f
>> mov eax,42
>
> The way to express that (correctly) in C is
>
> f(), 42;
I realize that. My point is, from the fundamental operation
point of view, it is valid to say f() = 42; Just not in C.
Note also, I remain here in the C group to try to introduce
these alternate ways of looking at things to C developers.
I hope to be like Morpheus to Neo, "Free your mind," before
jumping across the street to the other building.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 15:47 +0100 |
| Message-ID | <cQKtD.275$8J3.171@fx01.am4> |
| In reply to | #136254 |
On 05/10/2018 13:39, Rick C. Hodgin wrote: > If you brought it forward into assembly (rather than resolving > it at compile time), it would produce this on 32-bit x86: > > 01: mov eax,2 > 02: mov ebx,3 > 03: add eax,ebx > 04: inc eax > The problem is not in assigning such a meaning to "++". Sure, you can make ++A mean A+1 if you want. (In Python, ++A means A. Because it really means +(+A).) The first problem is that it is at odds with the way "++" is used in most languages that allow increment. The second problem is that it will be at odds with the way "++" is used even within the same language! That is far more crazy than the other. If you want people to use CAlive, you're going the wrong way about it. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-05 17:30 +0200 |
| Message-ID | <dlck8f-nm1.ln1@gangtai.home.grep.be> |
| In reply to | #136254 |
On 10/5/18 2:39 PM, Rick C. Hodgin wrote: > Just because they're constants doesn't mean the fundamental > operation is invalid. It's perfectly valid. It's just silly > to do it this way. That's a perfectly good reason not to do it, and not to allow it, in my opinion. [...] > You're talking about an imposed constraint on the operation by > C, and not by the true abilities of the machine. The machine also allows you to jump to an arbitrary address. That doesn't make it a good idea. You're designing a write-only language. At least perl is still readable.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 11:41 -0400 |
| Message-ID | <pp80nq$d4a$1@dont-email.me> |
| In reply to | #136280 |
On 10/5/2018 11:30 AM, Wouter Verhelst wrote: > You're designing a write-only language. At least perl is still readable. In CAlive, you'll be able to take your C code and compile it and run without change (or minimal change). You'll be able to write code as you do today and it will work. You'll be able to compile your code as you're used to and it will work. CAlive then also offers extensions to be used if they're desirable for your purposes. BTW, I heard a joke one time that said: "If you had a million monkey banging on a million keyboards, eventually one of them would write a Python program. The rest would write Perl." :-) I actually prefer Perl over Python, and do not use Python unless there's no other choice. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-05 17:56 +0200 |
| Message-ID | <o5ek8f-rs2.ln1@gangtai.home.grep.be> |
| In reply to | #136281 |
On 10/5/18 5:41 PM, Rick C. Hodgin wrote: > On 10/5/2018 11:30 AM, Wouter Verhelst wrote: >> You're designing a write-only language. At least perl is still readable. > > In CAlive, you'll be able to take your C code and compile it and > run without change (or minimal change). > > You'll be able to write code as you do today and it will work. Not with your increment operator it won't. > You'll be able to compile your code as you're used to and it > will work. > > CAlive then also offers extensions to be used if they're desirable > for your purposes. > > BTW, I heard a joke one time that said: "If you had a million > monkey banging on a million keyboards, eventually one of them > would write a Python program. The rest would write Perl." :-) > > I actually prefer Perl over Python, and do not use Python unless > there's no other choice. Well, I prefer perl too, but that's because it has rules that make sense.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 12:00 -0400 |
| Message-ID | <pp81r0$irf$2@dont-email.me> |
| In reply to | #136283 |
On 10/5/2018 11:56 AM, Wouter Verhelst wrote: > On 10/5/18 5:41 PM, Rick C. Hodgin wrote: >> On 10/5/2018 11:30 AM, Wouter Verhelst wrote: >>> You're designing a write-only language. At least perl is still readable. >> In CAlive, you'll be able to take your C code and compile it and >> run without change (or minimal change). >> >> You'll be able to write code as you do today and it will work. > Not with your increment operator it won't. It will work as it always has when used as it is today. Only if you now begin to apply ++ to other things will it be different, but if you constrain yourself to use it only on those things you can today, then it will be the same. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-10-05 12:34 -0400 |
| Message-ID | <2oMtD.39997$mJ1.32401@fx24.iad> |
| In reply to | #136254 |
Early in the development of the C++ language, reference could bind to temporaries, It was found that this lead to too many bugs in things where a mutating operation was done on a temporary and that operation then disappear (having meant the operation to have changed a variable, and not just a temporary copy of it). Expressions like (a+b)++ just cry out to that mistake. Because if this, non-constant references now can not bind to temporaries (aka r-values), and this greatly reduced bugs in code. You seem to be ignoring the history of language development and recreating many things that have been found to not be good ideas, and seem to be doomed to repeat the same mistakes. I see this in many things that you propose. You seem very sure that you know better than everyone else, include people who are experts in the field. You have admitted that you have difficulty understand technical documentation, yet you have committed yourself to embarking on a path which to be honest, should require you to generate similar technical documentation and understanding the work of others to avoid making the same mistakes others have admitted they have made. I suppose the one redeeming factor is that no one but you is apt to use your language, so you will not really be constrained by the problem of the desire to try and minimize backwards compatibility breaks when you do find the problems that you have repeated. I would suggest you listen to the words of someone you claim to follow: The way of a fool seems right to him, but a wise man listens to advice.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 12:48 -0400 |
| Message-ID | <pp84ln$9ar$1@dont-email.me> |
| In reply to | #136290 |
On 10/5/2018 12:34 PM, Richard Damon wrote:
> Early in the development of the C++ language, reference could bind to
> temporaries, It was found that this lead to too many bugs in things
> where a mutating operation was done on a temporary and that operation
> then disappear (having meant the operation to have changed a variable,
> and not just a temporary copy of it). Expressions like (a+b)++ just cry
> out to that mistake.
>
> Because if this, non-constant references now can not bind to temporaries
> (aka r-values), and this greatly reduced bugs in code.
>
> You seem to be ignoring the history of language development and
> recreating many things that have been found to not be good ideas, and
> seem to be doomed to repeat the same mistakes.
I have proposed the idea of adding --safety to enforce con-
straints. It could also be flipped to --nosafeties to remove
those constraints (which are enabled by default).
> I see this in many things that you propose. You seem very sure that you
> know better than everyone else, include people who are experts in the
> field.
I think of things differently than other people. It yields a
continuous flow of ideas, many of which are beneficial, many
of which are neutral or otherwise.
> You have admitted that you have difficulty understand technical
> documentation, yet you have committed yourself to embarking on a path
> which to be honest, should require you to generate similar technical
> documentation and understanding the work of others to avoid making the
> same mistakes others have admitted they have made.
I have no trouble generating technical documentation. It is
easily written by me because it flows out in the way I naturally
think.
> I suppose the one redeeming factor is that no one but you is apt to use
> your language, so you will not really be constrained by the problem of
> the desire to try and minimize backwards compatibility breaks when you
> do find the problems that you have repeated.
I hope you never spoke to children that way in their various
ideas. You would crush invisible things on their inside,
things they'd never recover from over their lifetime.
> I would suggest you listen to the words of someone you claim to follow:
> The way of a fool seems right to him,
> but a wise man listens to advice.
Such evil to suggest I do not, Richard.
https://www.biblegateway.com/passage/?search=Isaiah+5%3A20&version=KJV
Isaiah 5:20 -- Woe unto them that call evil good, and good
evil; that put darkness for light, and light for darkness;
that put bitter for sweet, and sweet for bitter!
I have a vision to create a powerful tool. When it is ready
for release it will be usable, stable, and will be in use for
all of my projects from that day forward.
I am writing this tool to honor God, and He remains ahead of
all other concerns.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-10-05 13:55 -0400 |
| Message-ID | <uANtD.240466$4S3.123343@fx47.iad> |
| In reply to | #136291 |
On 10/5/18 12:48 PM, Rick C. Hodgin wrote: > On 10/5/2018 12:34 PM, Richard Damon wrote: >> Early in the development of the C++ language, reference could bind to >> temporaries, It was found that this lead to too many bugs in things >> where a mutating operation was done on a temporary and that operation >> then disappear (having meant the operation to have changed a variable, >> and not just a temporary copy of it). Expressions like (a+b)++ just cry >> out to that mistake. >> >> Because if this, non-constant references now can not bind to temporaries >> (aka r-values), and this greatly reduced bugs in code. >> >> You seem to be ignoring the history of language development and >> recreating many things that have been found to not be good ideas, and >> seem to be doomed to repeat the same mistakes. > > I have proposed the idea of adding --safety to enforce con- > straints. It could also be flipped to --nosafeties to remove > those constraints (which are enabled by default). You seem to have LOTS of these disjointed ideas of little pieces of options and features. I see little evidence that you have actually thought through the interactions of all these or sat down to actually try to create a COMPLETE definition of what you want. > >> I see this in many things that you propose. You seem very sure that you >> know better than everyone else, include people who are experts in the >> field. > > I think of things differently than other people. It yields a > continuous flow of ideas, many of which are beneficial, many > of which are neutral or otherwise. Yes, you can a continuous flow of disjointed ideas, but lacking a fundamental basis to tie them together into a unified whole. > >> You have admitted that you have difficulty understand technical >> documentation, yet you have committed yourself to embarking on a path >> which to be honest, should require you to generate similar technical >> documentation and understanding the work of others to avoid making the >> same mistakes others have admitted they have made. > > I have no trouble generating technical documentation. It is > easily written by me because it flows out in the way I naturally > think. I have looked at some of your 'technical documentation', and it is at best a high level overview of features. It is woefully incomplete to allow someone to use the tool based solely on the documentation. Have your ever asked someone to review your 'documentation' to determine if it is anywhere near good enough to be a language definition. > >> I suppose the one redeeming factor is that no one but you is apt to use >> your language, so you will not really be constrained by the problem of >> the desire to try and minimize backwards compatibility breaks when you >> do find the problems that you have repeated. > > I hope you never spoke to children that way in their various > ideas. You would crush invisible things on their inside, > things they'd never recover from over their lifetime. I hope you are more mature than a child (although that might explain a lot of things). I child you start by encouraging them to think about what they are doing and starting to get them to think beyond themselves and to broader things, and away from personal fantasies. It is ok to allow them to have fantasies that still allow them to work with the real world, but when their fantasies make them unable to handle reality you do need to get them out of them. You seem to have a fantasy that you really understand computer language design, and that fantasy > >> I would suggest you listen to the words of someone you claim to follow: >> The way of a fool seems right to him, >> but a wise man listens to advice. > > Such evil to suggest I do not, Richard. Please name ONE person you have really taken advice from (related to your programming project). > > https://www.biblegateway.com/passage/?search=Isaiah+5%3A20&version=KJV > > Isaiah 5:20 -- Woe unto them that call evil good, and good > evil; that put darkness for light, and light for darkness; > that put bitter for sweet, and sweet for bitter! How do you know which side that refers to in this case? Do you claim that somewhere in the Bible is a definition of what is a 'good' programming language and what is an evil one? The Bible tells us to generally obey earthly authority (the only exception being if something directly conflicts commands of the scriptures). That would include following the rules of topicality in forums like this. If you actually had an intent to realistically propose some of these changes to be incorporated into the C language, it might have some topicality here. If your questions were focused on trying to understand why C works the way it does, it might be topical here. Annoying people with off topic rants does NOT bring honor to God. > > I have a vision to create a powerful tool. When it is ready > for release it will be usable, stable, and will be in use for > all of my projects from that day forward. > > I am writing this tool to honor God, and He remains ahead of > all other concerns. > You claim a vision, you claim you are doing it to honor God, you claim a lot of things. Please look at what God really asks of us, what he really expects, what he promises to provide. My fear is that you seem to really be mocking God by claiming that all your work is evidence of the power of God, when it looks like in the end it may well turn for nought, and YOUR failure here will be blamed on God. It is one thing to draw inner power in a trust that God is working with you as your strive for a goal, it is quite another to invoke him to others as an excuse for doing something he hasn't clearly called you to do. (Show me a biblical reference for your calling to create a computer language).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-05 11:20 -0700 |
| Message-ID | <lnmurs2r3f.fsf@kst-u.example.com> |
| In reply to | #136299 |
I humbly request that people *do not* discuss religion with Rick
Hodgin on this newsgroup. It encourages him to post more off-topic
material, and it hurts this newsgroup by damaging the signal-to-noise
ratio, even for those of us who have killfiled Rick.
Many of us do not see his propaganda unless someone else quotes it
and responds to it.
I don't object to people who respond when he posts topical material
(I don't, but that's my choice), but please don't engage with him
in religious arguments. There are newsgroups where such discussions
are appropriate, and if I recall correctly Rick will likely respond
to email if you want to discuss something with him privately.
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-05 14:45 -0400 |
| Message-ID | <pp8bge$oic$1@dont-email.me> |
| In reply to | #136299 |
On 10/5/2018 1:55 PM, Richard Damon wrote:
> On 10/5/18 12:48 PM, Rick C. Hodgin wrote:
> You seem to have LOTS of these disjointed ideas of little pieces of
> options and features. I see little evidence that you have actually
> thought through the interactions of all these or sat down to actually
> try to create a COMPLETE definition of what you want.
I develop software for a living. It is also my "hobby." Things
occur to me when I'm writing code. I get into a coding situation
and I realize what could work here. It goes along with the same
general philosophy I've had for a language since the late 90s.
The only difference now is I am doing something about it.
>> I think of things differently than other people. It yields a
>> continuous flow of ideas, many of which are beneficial, many
>> of which are neutral or otherwise.
>
> Yes, you can a continuous flow of disjointed ideas, but lacking a
> fundamental basis to tie them together into a unified whole.
Do you realize that when you write something to someone like, "a
continuous flow of disjointed ideas" you are being insulting?
I have a solid fundamental basis, Richard. I have wanted some-
thing that hasn't existed since the late 90s, and specifically
with renewed vigor since the first half of this decade. It's
when I came to the C group back in 2014 to try and get some of
the ideas I have implemented in C. That was rejected, so I am
moving forward with CAlive.
I move by inspiration. The inspiration does not come from me.
I am the receiver of it. I sit there writing code, going about
my regular days doing the various things I do and these things
occur to me. I do not have to sit down and think them through.
I receive as fully-populated and complete ideas.
This swap thing was not my idea. And this particular one I did
begin to think through as the threads progressed. I began to
realize the difference between a = b; and a >< b; ... it's some-
thing new to C, and not trivially new as Ben indicated. It is
a whole new class of ability. And once I realized that, then I
began to see the whole other side open up about why couldn't we
write "2 = d;" and have it be valid?
I can't even say I would write code like that, but I also rec-
ognize that such an ability is fundamental to the abilities of
the hardware we use. And while constraints imposed upon those
fundamental abilities are desirable, they should not be inhibit-
ing, nor denied.
My whole goal with CAlive is flexibility, and if it's discovered
during development that developers are shooting themselves in
the foot and blowing off their legs, then I will introduce some
safeties for those purposes, but I will not nor ever impose them.
>>> You have admitted that you have difficulty understand technical
>>> documentation, yet you have committed yourself to embarking on a path
>>> which to be honest, should require you to generate similar technical
>>> documentation and understanding the work of others to avoid making the
>>> same mistakes others have admitted they have made.
>>
>> I have no trouble generating technical documentation. It is
>> easily written by me because it flows out in the way I naturally
>> think.
>
> I have looked at some of your 'technical documentation', and it is at
> best a high level overview of features. It is woefully incomplete to
> allow someone to use the tool based solely on the documentation. Have
> your ever asked someone to review your 'documentation' to determine if
> it is anywhere near good enough to be a language definition.
It's the best I can do. Someone will come along some day who
can formalize it into some form, do so for the Lord, and in the
process teach me a thing or two about how to do it better.
My goal is to give /MY BEST/ unto the Lord. He knows my heart's
intent, and if He wants to send others to help me then great.
If not, then I'll proceed /UNTO HIM/ alone, doing the best I can
do. I liken it to the child who seeks to bring home the art /
craft thing he/she made in school to give to their parents. Com-
pared to what He can do it will be perhaps laughable, but to Him
it is the most precious and amazing gift He could receive, because
I am giving back to Him because of who He is.
If you want to serve the Lord and help me on this project, then
come on board and help. I would welcome it. I get so tired of
being attacked by people for giving my best to the Lord, in do-
ing my best for Him. I receive nothing but peace in my efforts
when I approach Him, but when I approach man, it is a constant
slew of attacks and disparaging / hateful comments. It is very
hurtful to receive such comments continually, and were it not
for me working to serve Him, I would've left long long long ago.
>>> I suppose the one redeeming factor is that no one but you is apt to use
>>> your language, so you will not really be constrained by the problem of
>>> the desire to try and minimize backwards compatibility breaks when you
>>> do find the problems that you have repeated.
>>
>> I hope you never spoke to children that way in their various
>> ideas. You would crush invisible things on their inside,
>> things they'd never recover from over their lifetime.
>
> I hope you are more mature than a child (although that might explain a
> lot of things). I child you start by encouraging them to think about
> what they are doing and starting to get them to think beyond themselves
> and to broader things, and away from personal fantasies. It is ok to
> allow them to have fantasies that still allow them to work with the real
> world, but when their fantasies make them unable to handle reality you
> do need to get them out of them. You seem to have a fantasy that you
> really understand computer language design, and that fantasy
You are cruel, Richard. I hope someday you see that.
>>> I would suggest you listen to the words of someone you claim to follow:
>>> The way of a fool seems right to him,
>>> but a wise man listens to advice.
>>
>> Such evil to suggest I do not, Richard.
>
> Please name ONE person you have really taken advice from (related to
> your programming project).
David Brown. I had previously not wanted to support namespaces.
In 2017 he convinced me to do so.
> How do you know which side that refers to in this case? Do you claim
> that somewhere in the Bible is a definition of what is a 'good'
> programming language and what is an evil one?
The one given over to God, coupled to a life lived rightly unto
Him. It is the holy offering, offering up one's life as a living
sacrifice, holy and acceptable, pleasing unto the Lord.
> The Bible tells us to generally obey earthly authority (the only
> exception being if something directly conflicts commands of the
> scriptures). That would include following the rules of topicality in
> forums like this.
You do not know the Bible, Richard. You know pieces. Bits.
Some things you've glommed on to at some point, but you do
not know it or God. If you did, you'd praise Him with your
life.
The authorities had been telling the early Apostles and the
disciples not to preach or teach about Jesus in the areas
where they were. These were the leaders, legal authorities
of the time:
https://www.biblegateway.com/passage/?search=Acts+4%3A19&version=KJV
19 But Peter and John answered and said unto them,
Whether it be right in the sight of God to hearken
unto you more than unto God, judge ye.
Jesus has given us an authority which supersedes all other
Earthly authority:
https://www.biblegateway.com/passage/?search=Matthew+28%3A18-20&version=KJV
18 And Jesus came and spake unto them, saying, All
power is given unto me in heaven and in earth.
19 Go ye therefore, and teach all nations, baptizing
them in the name of the Father, and of the Son,
and of the Holy Ghost:
20 Teaching them to observe all things whatsoever I
have commanded you: and, lo, I am with you always,
even unto the end of the world. Amen.
The words used in verse 18 for "All power" relate to authority.
And this is now Rick's discernment and understanding of God
brought to bear on this passage: In verse 19 when it says,
"baptizing them in the name of the Father, and of the Son,
and of the Holy Ghost," I do not believe that is referring
to water baptism at all, but rather their lives are to be
baptized in those names, so that we are to go forth and teach
people to place God first, and to have Him out there in front
of all people, baptizing them in the name in that way.
Why do I conclude that? Because I have come to know God over
my studies. This passage is sandwiched in between two verses
that relate to teaching and obeying His guidance. We are to
teach people because there's an active enemy teaching all man-
ner of false / contradictory things. We are to teach them to
observe the things of God (to keep themselves holy) because
then they are empowered by the spirit, and not heavy laden by
the flesh.
> If you actually had an intent to realistically propose
> some of these changes to be incorporated into the C language, it might
> have some topicality here. If your questions were focused on trying to
> understand why C works the way it does, it might be topical here.
> Annoying people with off topic rants does NOT bring honor to God.
I do not work that way. I have tried to understand C, and I'm
not equipped to do it the way it is presented / exists. I have
to rely upon my innate understanding of how things work, and to
then apply them to how I see C working to understand how they
must be working.
I did the best I could coming here. I met with resistance top
to bottom, so I began my own endeavor, and even now, more of
the same resistance top to bottom.
>> I have a vision to create a powerful tool. When it is ready
>> for release it will be usable, stable, and will be in use for
>> all of my projects from that day forward.
>>
>> I am writing this tool to honor God, and He remains ahead of
>> all other concerns.
>
> You claim a vision, you claim you are doing it to honor God, you claim a
> lot of things. Please look at what God really asks of us, what he really
> expects, what he promises to provide.
I have. Deeply. Over many years. Routinely. Regularly. I
fall down before God asking if I should walk away from it all
and do something else.
> My fear is that you seem to really
> be mocking God by claiming that all your work is evidence of the power
> of God, when it looks like in the end it may well turn for nought, and
> YOUR failure here will be blamed on God.
There is no failure, you most rude and hateful person. I am
giving the fruit of my labor over to God. I already have the
full victory for my efforts, because I have turned it over to
Him in that way. I am creating something to honor Him. Where
I fail are in my own weaknesses and limitations, but not in
the efforts nor desire to turn it over to Him.
Whether or not I succeed or fail will be entirely upon Him be-
cause He knows my strengths and weaknesses and limitations, and
I will stand by what He brings me.
https://www.biblegateway.com/passage/?search=Habakkuk+3%3A17-19&version=KJV
17 Although the fig tree shall not blossom, neither shall
fruit be in the vines; the labour of the olive shall
fail, and the fields shall yield no meat; the flock
shall be cut off from the fold, and there shall be no
herd in the stalls:
18 Yet I will rejoice in the Lord, I will joy in the God
of my salvation.
19 The Lord God is my strength, and he will make my feet
like hinds' feet, and he will make me to walk upon mine
high places.
==> To the chief singer on my stringed instruments.
A song of praise no matter the circumstance.
> It is one thing to draw inner
> power in a trust that God is working with you as your strive for a goal,
> it is quite another to invoke him to others as an excuse for doing
> something he hasn't clearly called you to do. (Show me a biblical
> reference for your calling to create a computer language).
May the Lord shine His holy light upon your understanding, and
deliver you from your iniquity.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-10-05 21:39 -0400 |
| Message-ID | <inUtD.316413$YL3.7587@fx48.iad> |
| In reply to | #136302 |
On 10/5/18 2:45 PM, Rick C. Hodgin wrote: > On 10/5/2018 1:55 PM, Richard Damon wrote: >> On 10/5/18 12:48 PM, Rick C. Hodgin wrote: >> You seem to have LOTS of these disjointed ideas of little pieces of >> options and features. I see little evidence that you have actually >> thought through the interactions of all these or sat down to actually >> try to create a COMPLETE definition of what you want. > > I develop software for a living. It is also my "hobby." Things > occur to me when I'm writing code. I get into a coding situation > and I realize what could work here. It goes along with the same > general philosophy I've had for a language since the late 90s. > The only difference now is I am doing something about it. Which has what to do with designing a new language? A programmer takes a specification and creates code that implements it. The program has a hard time really being better than what the specification defines. My issue isn't with you being able to implement a defined language, but with being able to come up with a usable definition for that language. Since one of your stated goals was that your compiler should be able to compile 'Standard C', would have been to write a reasonably conforming C compiler, without worrying about all of your additions. Perhaps give some thought to your changes, so you implement things in ways that make adding the additions easier, but target to get a reasonably compliant C compiler produced first, THEN worry about your additions. If you had a working C compiler that you could point people to, people would take you much more serious. I do have serious concerns that you have what it takes to DESIGN a new language, which says nothing about your ability to program. Would you expect Mario Andretti to be able to design a racing car? > >>> I think of things differently than other people. It yields a >>> continuous flow of ideas, many of which are beneficial, many >>> of which are neutral or otherwise. >> >> Yes, you can a continuous flow of disjointed ideas, but lacking a >> fundamental basis to tie them together into a unified whole. > > Do you realize that when you write something to someone like, "a > continuous flow of disjointed ideas" you are being insulting? I am being honest. If you really think that is being insulting, ask yourself how other people should take some of your comments about them. And if me being truthful about you isn't a justification, why is it for you. In one sense, disjointed ideas aren't inherently bad. Many development processes start with the creation of many disjointed ideas, brainstorming, it is just those processes then move past that stage into organizing them and working out a harmony to them. I don't see this stage happening for you language design, just a rush to try and do something with it. Looking at your documentation for RDC/CAlive I see the same thing. Your documentation is pages after pages of short ideas of new things, not apparently organized in any manner. Compare that to something like the C Standard, it is organized in a hierarchical manner, where given concepts are defined and fleshed out, and then related ideas are fleshed out, and then you move on to other concepts. > > I have a solid fundamental basis, Richard. I have wanted some- > thing that hasn't existed since the late 90s, and specifically > with renewed vigor since the first half of this decade. It's > when I came to the C group back in 2014 to try and get some of > the ideas I have implemented in C. That was rejected, so I am > moving forward with CAlive. > > I move by inspiration. The inspiration does not come from me. > I am the receiver of it. I sit there writing code, going about > my regular days doing the various things I do and these things > occur to me. I do not have to sit down and think them through. > I receive as fully-populated and complete ideas. Running by random inspiration is a very good source of disjointed ideas. As I said, it isn't a bad start, but ideas DO need to be worked out to see how they fit into the whole picture, and seeing how sometimes that may mean rearranging the big picture, but also realizing the cost to do so. If you really think what you have presented where fully-populated and complete ideas, you are mistaken (or badly presenting). > > This swap thing was not my idea. And this particular one I did > begin to think through as the threads progressed. I began to > realize the difference between a = b; and a >< b; ... it's some- > thing new to C, and not trivially new as Ben indicated. It is > a whole new class of ability. And once I realized that, then I > began to see the whole other side open up about why couldn't we > write "2 = d;" and have it be valid? And if you had ANY understanding about real language usability you might understand. The goal of a language designer is NOT to make as many possible arrangement of symbols valid, as that actually leads to higher error rates, as the compiler has less ability to catch typical human mistakes. Ideally you want to allow the programmer to express many different ideas, and sometimes allow multiple (unambiguously) ways to express those ideas. Having a given expression pattern being able to represent some very different operations is bad. It also makes it harder to define how to parse what is there. In this case the example of something1 = something2 where the two somethings are pieces of expressions sometimes meaning move the value of something2 into something1 and sometimes moving something1 into something2 is a recipe of confusion. Then you get into issue of what does a = b + c = d; mean? Does it change if c is changed to be defined as a const? How about #define c 2 ? > > I can't even say I would write code like that, but I also rec- > ognize that such an ability is fundamental to the abilities of > the hardware we use. And while constraints imposed upon those > fundamental abilities are desirable, they should not be inhibit- > ing, nor denied. What hardware does being able to say 2 = d support that saying d = 2 doesn't? What use is it to increment a temporary register that can NEVER again be accessed? Do you mean that a = (b+c)++ + (b+c) should see that b+c was already computed and reuse that temporary, even though it has been modified (and thus the answer you get depends on the compiler being able to recognize the reuse). > > My whole goal with CAlive is flexibility, and if it's discovered > during development that developers are shooting themselves in > the foot and blowing off their legs, then I will introduce some > safeties for those purposes, but I will not nor ever impose them. > >>>> You have admitted that you have difficulty understand technical >>>> documentation, yet you have committed yourself to embarking on a path >>>> which to be honest, should require you to generate similar technical >>>> documentation and understanding the work of others to avoid making the >>>> same mistakes others have admitted they have made. >>> >>> I have no trouble generating technical documentation. It is >>> easily written by me because it flows out in the way I naturally >>> think. >> >> I have looked at some of your 'technical documentation', and it is at >> best a high level overview of features. It is woefully incomplete to >> allow someone to use the tool based solely on the documentation. Have >> your ever asked someone to review your 'documentation' to determine if >> it is anywhere near good enough to be a language definition. > > It's the best I can do. Someone will come along some day who > can formalize it into some form, do so for the Lord, and in the > process teach me a thing or two about how to do it better. > > My goal is to give /MY BEST/ unto the Lord. He knows my heart's > intent, and if He wants to send others to help me then great. > If not, then I'll proceed /UNTO HIM/ alone, doing the best I can > do. I liken it to the child who seeks to bring home the art / > craft thing he/she made in school to give to their parents. Com- > pared to what He can do it will be perhaps laughable, but to Him > it is the most precious and amazing gift He could receive, because > I am giving back to Him because of who He is. > > If you want to serve the Lord and help me on this project, then > come on board and help. I would welcome it. I get so tired of > being attacked by people for giving my best to the Lord, in do- > ing my best for Him. I receive nothing but peace in my efforts > when I approach Him, but when I approach man, it is a constant > slew of attacks and disparaging / hateful comments. It is very > hurtful to receive such comments continually, and were it not > for me working to serve Him, I would've left long long long ago. > God does not ask us to do things he doesn't enable us to do. If we are struggling at doing something we need to ask ourselves if we really have been called to do it, or if we decide for ourselves in our personal arrogance that it was something we wanted to do for him, and he is closing a door and directing us elsewhere. (This isn't always a simple answer). >>>> I suppose the one redeeming factor is that no one but you is apt to use >>>> your language, so you will not really be constrained by the problem of >>>> the desire to try and minimize backwards compatibility breaks when you >>>> do find the problems that you have repeated. >>> >>> I hope you never spoke to children that way in their various >>> ideas. You would crush invisible things on their inside, >>> things they'd never recover from over their lifetime. >> >> I hope you are more mature than a child (although that might explain a >> lot of things). I child you start by encouraging them to think about >> what they are doing and starting to get them to think beyond themselves >> and to broader things, and away from personal fantasies. It is ok to >> allow them to have fantasies that still allow them to work with the real >> world, but when their fantasies make them unable to handle reality you >> do need to get them out of them. You seem to have a fantasy that you >> really understand computer language design, and that fantasy > > You are cruel, Richard. I hope someday you see that. > >>>> I would suggest you listen to the words of someone you claim to follow: >>>> The way of a fool seems right to him, >>>> but a wise man listens to advice. >>> >>> Such evil to suggest I do not, Richard. >> >> Please name ONE person you have really taken advice from (related to >> your programming project). > > David Brown. I had previously not wanted to support namespaces. > In 2017 he convinced me to do so. So ONE tidbit in the whole project, is that REALLY getting advice? > >> How do you know which side that refers to in this case? Do you claim >> that somewhere in the Bible is a definition of what is a 'good' >> programming language and what is an evil one? > > The one given over to God, coupled to a life lived rightly unto > Him. It is the holy offering, offering up one's life as a living > sacrifice, holy and acceptable, pleasing unto the Lord. > >> The Bible tells us to generally obey earthly authority (the only >> exception being if something directly conflicts commands of the >> scriptures). That would include following the rules of topicality in >> forums like this. > > You do not know the Bible, Richard. You know pieces. Bits. > Some things you've glommed on to at some point, but you do > not know it or God. If you did, you'd praise Him with your > life. I will not get into this sort of argument over who knows the Bible better, for it isn't becoming of this forum. If you want to discuss this person to person we can. I will say that I have been following God for a long time and deeply know and understand his Grace and power.
[toc] | [prev] | [next] | [standalone]
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web