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 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-03 14:29 +0200 |
| Message-ID | <pp2cna$a1g$2@dont-email.me> |
| In reply to | #136081 |
On 03/10/18 11:52, Bart wrote: > On 03/10/2018 10:25, David Brown wrote: >> On 02/10/18 23:16, Rick C. Hodgin wrote: >>> On 10/2/2018 5:02 PM, Bart wrote: >>>> On 02/10/2018 21:37, Rick C. Hodgin wrote: >>>>> sizeof(x) --> ?#(x) // # = number of characters >>>>> _Alignof(x) --> ?&&(x) // && = address of the address of x >>>> >>>> You really think that would be a benefit to anybody? >>>> If so I won't bother arguing further. >>> >>> #define sizeof ?# >>> #define _Alignof ?&& >>> >>> Now everybody's happy. See how it works? >> >> No, /not/ everyone is happy. You always forget that people have to >> /read/ code as well as write it. >> >> Most people will write "sizeof" as before. And then you come across >> code that uses "?#" no one (except you) has the slightest clue what it >> might mean. > > Not even Rick will know when he comes across: > > a><f()??#(b):b>:c > > Using normal identifiers, that would be: > > swap(a,f())?sizeof(b):min(b,c) // or it might be max > > This is not that meaningful as it applies swap() in a weird manner that > only makes sense to Rick, but at least you can now see what operations > are being used. > Agreed - though I do wish you would learn how to use the space bar when you write your code! I can't see what sort of return value would make sense from a "swap" operation, but maybe other people do.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-03 05:52 -0700 |
| Message-ID | <f0419f16-e247-4c25-9941-76127a3bcf9d@googlegroups.com> |
| In reply to | #136095 |
On Wednesday, October 3, 2018 at 1:29:39 PM UTC+1, David Brown wrote: > On 03/10/18 11:52, Bart wrote: > > On 03/10/2018 10:25, David Brown wrote: > >> On 02/10/18 23:16, Rick C. Hodgin wrote: > >>> On 10/2/2018 5:02 PM, Bart wrote: > >>>> On 02/10/2018 21:37, Rick C. Hodgin wrote: > >>>>> sizeof(x) --> ?#(x) // # = number of characters > >>>>> _Alignof(x) --> ?&&(x) // && = address of the address of x > >>>> > >>>> You really think that would be a benefit to anybody? > >>>> If so I won't bother arguing further. > >>> > >>> #define sizeof ?# > >>> #define _Alignof ?&& > >>> > >>> Now everybody's happy. See how it works? > >> > >> No, /not/ everyone is happy. You always forget that people have to > >> /read/ code as well as write it. > >> > >> Most people will write "sizeof" as before. And then you come across > >> code that uses "?#" no one (except you) has the slightest clue what it > >> might mean. > > > > Not even Rick will know when he comes across: > > > > a><f()??#(b):b>:c > > > > Using normal identifiers, that would be: > > > > swap(a,f())?sizeof(b):min(b,c) // or it might be max > > > > This is not that meaningful as it applies swap() in a weird manner that > > only makes sense to Rick, but at least you can now see what operations > > are being used. > > > > Agreed - though I do wish you would learn how to use the space bar when > you write your code! > > I can't see what sort of return value would make sense from a "swap" > operation, but maybe other people do. > No, it usually can't fail, and it inherently operates on the bit patterns passed to it in place. So the return type isn't useful unless you can return two values, when it ceases to be "swap" and becomes "assign".
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-03 21:31 +0100 |
| Message-ID | <87in2iu60b.fsf@bsb.me.uk> |
| In reply to | #136102 |
In the context of a >< b being a swap operation... Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, October 3, 2018 at 1:29:39 PM UTC+1, David Brown wrote: <snip> >> I can't see what sort of return value would make sense from a "swap" >> operation, but maybe other people do. >> > No, it usually can't fail, and it inherently operates on the bit patterns > passed to it in place. Why do you say that swap inherently operates on bit patterns? It would make perfect sense to define swap in terms of values, just as C defines assignment in terms of values and not bit patterns. > So the return type isn't useful unless you can > return two values, when it ceases to be "swap" and becomes "assign". If a swap expression were to be an lvalue then a >< b >< c; gets a natural meaning: it rotates the values in a, b and c. The main argument against defining it like this is that the operator is no longer symmetric, despite being written with a symmetric symbol. a >< b >< c rotates right or left depending on whether a >< b yields the lvalue of a or b and the operator gives the reader no clue as to which is the lvalue. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 16:47 -0400 |
| Message-ID | <pp39t5$jve$1@dont-email.me> |
| In reply to | #136134 |
On 10/3/2018 4:31 PM, Ben Bacarisse wrote:
> If a swap expression were to be an lvalue then
> a >< b >< c;
>
> gets a natural meaning: it rotates the values in a, b and c. The main
> argument against defining it like this is that the operator is no longer
> symmetric, despite being written with a symmetric symbol.
The"a >< b >< c;" expression would return this result:
// Initial values:
int a = 1, b = 2, c = 3;
// Rewrite, working on the part in parenthesis
(a >< b) >< c;
01: t1 = b;
02: b = a;
03: a = t1;
// Right now, a = 2, b = 1, t1 = 2
// Now: "t1 >< c;"
04: t2 = c;
05: c = t1;
06: t1 = t2;
// Right now, t1 = 3, c = 2, t2 = 3
// Now: "t2;"
After one iteration, the initial c value is lost to the
intermediate expression calculation, which was not con-
sumed in this form.
Start End
----- -----
a = 1 ---> a = 2
b = 2 ---> b = 1
c = 3 ---> c = 2
If you had used:
a = (a >< b >< c);
Then it would've returned the t2 value, which was 3, and it would
be a cycle to the right one step.
> a >< b >< c rotates right or left depending on whether a >< b yields the
> lvalue of a or b and the operator gives the reader no clue as to which
> is the lvalue.
Based on what was discussed previously, a >< b returns a. And
a ><= b would return b; (takes the thing on the right, and,
while swapping, returns the result of the store, which is ef-
fectively b going into a, even though simultaneously a went
into b).
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 03:43 +0100 |
| Message-ID | <87sh1mqvmt.fsf@bsb.me.uk> |
| In reply to | #136136 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On 10/3/2018 4:31 PM, Ben Bacarisse wrote: >> If a swap expression were to be an lvalue then >> a >< b >< c; >> >> gets a natural meaning: it rotates the values in a, b and c. The main >> argument against defining it like this is that the operator is no longer >> symmetric, despite being written with a symmetric symbol. > > The"a >< b >< c;" expression would return this result: You are free to define it any way you like, but what you write below suggests you are not talking about my suggestion. If a >< b is an lvalue expression (that's the way the C standard uses the term) then there are only two reasonable lvalues to consider -- the left hand side or the right hand side. > // Initial values: > int a = 1, b = 2, c = 3; > > // Rewrite, working on the part in parenthesis > (a >< b) >< c; > > 01: t1 = b; > 02: b = a; > 03: a = t1; > // Right now, a = 2, b = 1, t1 = 2 > // Now: "t1 >< c;" > > 04: t2 = c; > 05: c = t1; > 06: t1 = t2; > // Right now, t1 = 3, c = 2, t2 = 3 > // Now: "t2;" > > After one iteration, the initial c value is lost to the > intermediate expression calculation, which was not con- > sumed in this form. This is very odd. Why would you chose the temporary to be the lvalue to use? And of you are using the temporary to get the ordinary (r)value, why do even permit (a >< b) >< c? It should be a constraint violation in the same what that 2 = b is. Note that with my suggestion the associativity of >< makes no difference. (a >< b) >< c gives the same result as a >< (b >< c). Maybe you are not sure what an lvalue is? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 22:47 -0400 |
| Message-ID | <pp3v0o$tlm$1@dont-email.me> |
| In reply to | #136164 |
On 10/03/2018 10:43 PM, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> The"a >< b >< c;" expression would return this result: >> >> // Initial values: >> int a = 1, b = 2, c = 3; >> >> // Rewrite, working on the part in parenthesis >> (a >< b) >< c; >> >> 01: t1 = b; >> 02: b = a; >> 03: a = t1; >> // Right now, a = 2, b = 1, t1 = 2 >> // Now: "t1 >< c;" >> >> 04: t2 = c; >> 05: c = t1; >> 06: t1 = t2; >> // Right now, t1 = 3, c = 2, t2 = 3 >> // Now: "t2;" >> >> After one iteration, the initial c value is lost to the >> intermediate expression calculation, which was not con- >> sumed in this form. > > This is very odd. Why would you chose the temporary to be the lvalue to > use? And of you are using the temporary to get the ordinary (r)value, > why do even permit (a >< b) >< c? It should be a constraint violation > in the same what that 2 = b is. Because >< is an operator. It is evaluated left-to-right as if you had used a + b + c. > Note that with my suggestion the associativity of >< makes no > difference. (a >< b) >< c gives the same result as a >< (b >< c). I didn't realize you were suggesting something new. I thought you were misunderstanding what had already been discussed. My reply was given relative to the prior discussion between myself and Bart. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 04:25 +0100 |
| Message-ID | <87muruqto8.fsf@bsb.me.uk> |
| In reply to | #136165 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On 10/03/2018 10:43 PM, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> The"a >< b >< c;" expression would return this result: >>> >>> // Initial values: >>> int a = 1, b = 2, c = 3; >>> >>> // Rewrite, working on the part in parenthesis >>> (a >< b) >< c; >>> >>> 01: t1 = b; >>> 02: b = a; >>> 03: a = t1; >>> // Right now, a = 2, b = 1, t1 = 2 >>> // Now: "t1 >< c;" >>> >>> 04: t2 = c; >>> 05: c = t1; >>> 06: t1 = t2; >>> // Right now, t1 = 3, c = 2, t2 = 3 >>> // Now: "t2;" >>> >>> After one iteration, the initial c value is lost to the >>> intermediate expression calculation, which was not con- >>> sumed in this form. >> >> This is very odd. Why would you chose the temporary to be the lvalue to >> use? And of you are using the temporary to get the ordinary (r)value, >> why do even permit (a >< b) >< c? It should be a constraint violation >> in the same what that 2 = b is. > > Because >< is an operator. It is evaluated left-to-right as if > you had used a + b + c. But >< is not like +. It is more like = where one side must be an lvalue, except with >< both side must be. Thus (a >< b) >< c only makes sense if the expression a >< b is itself an lvalue. You can't assign to the result of an expression that yields an ordinary value (like (a + b) = c) and you should not be able to swap c with the result of an expression that yields an ordinary value. That's why I pointed out that a >< b should really be an lvalue expression, not an ordinary one. >> Note that with my suggestion the associativity of >< makes no >> difference. (a >< b) >< c gives the same result as a >< (b >< c). > > I didn't realize you were suggesting something new. I started out with "If a swap expression were to be an lvalue..." and as far as I know that had not been proposed up to that point. I don't see how you could think I was not introducing a new idea. You weren't talking about lvalue expressions where you? > I thought > you were misunderstanding what had already been discussed. My > reply was given relative to the prior discussion between myself > and Bart. Ah. It should have been given relative to what I wrote which was clearly introducing the notion that a swap should be an lavlue so that expressions like a >< b >< c would be useful. I had nothing to say about what you are Bart were discussing. I replied to *Malcolm* when he said that the expression's result is not useful. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 20:44 -0700 |
| Message-ID | <d6eae0d7-cc2d-43d0-aa94-c9629f357b92@googlegroups.com> |
| In reply to | #136166 |
On Wednesday, October 3, 2018 at 11:26:07 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > Because >< is an operator. It is evaluated left-to-right as if > > you had used a + b + c. > > But >< is not like +. It is more like = where one side must be an > lvalue, except with >< both side must be. Thus (a >< b) >< c only makes > sense if the expression a >< b is itself an lvalue. It's an arbitrary choice. >< returns the left side, ><= returns the right side, but apart from moving data in two directions, it's otherwise identical to other operators. > You can't assign to the result of an expression that yields an ordinary > value (like (a + b) = c) and you should not be able to swap c with the > result of an expression that yields an ordinary value. That's why I > pointed out that a >< b should really be an lvalue expression, not an > ordinary one. I understand your point. I disagree. I think >< and ><= are special case operators, but traditional in all other ways. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 11:53 +0100 |
| Message-ID | <877eiyq8y9.fsf@bsb.me.uk> |
| In reply to | #136167 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, October 3, 2018 at 11:26:07 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > Because >< is an operator. It is evaluated left-to-right as if
>> > you had used a + b + c.
>>
>> But >< is not like +. It is more like = where one side must be an
>> lvalue, except with >< both side must be. Thus (a >< b) >< c only makes
>> sense if the expression a >< b is itself an lvalue.
>
> It's an arbitrary choice. >< returns the left side, ><= returns
> the right side, but apart from moving data in two directions, it's
> otherwise identical to other operators.
I don't think you know what an lvalue is. "returns the left side" is
ambiguous in a context where you seem to be talking about ordinary
values and I am talking about lvalues.
>> You can't assign to the result of an expression that yields an ordinary
>> value (like (a + b) = c) and you should not be able to swap c with the
>> result of an expression that yields an ordinary value. That's why I
>> pointed out that a >< b should really be an lvalue expression, not an
>> ordinary one.
>
> I understand your point.
No, I really don't think you do. Can you at least see how a >< b >< c
rotates the contents of a, b and c if >< is an lvalue expression? If
not (and you certainly claimed before that it doesn't) then you are not
seeing what I am suggesting.
> I disagree. I think >< and ><= are
> special case operators, but traditional in all other ways.
I am not sure what it is you disagree with. Why, if you favour having a
swap operator, would you not want a >< b >< c to have a useful meaning?
You can still use a >< b in other expressions (since lvalues "decay" to
ordinary values).
If you also make ><= be an lvalue expression you get a ><= b ><= c being
a rotate in the other direction. What is there to disagree with here?
(By the way, if I were going to provide both operators I'd make them
mirrors of each other, for example =>< and ><=. However, I don't think
there is much value in having both.)
Here it is in C++ using << and >> for the two versions of swap. You can
do it with a swap function in C, but (a) I wanted to illustrate it with
operators, (b) in C you have to use pointers so there is no direct
analogue of the lvalue.
template <class T> class Swappable {
T content;
public:
Swappable(T v) : content(v) {}
operator T (){ return content; }
Swappable &operator<<(Swappable &s) {
T tmp = content; content = s.content; s.content = tmp;
return *this;
}
Swappable &operator>>(Swappable &s) {
T tmp = content; content = s.content; s.content = tmp;
return s;
}
};
#include <iostream>
int main()
{
Swappable<int> a = 1, b = 2, c = 3;
std::cout << a << " " << b << " " << c << "\n";
a << b << c;
std::cout << a << " " << b << " " << c << "\n";
a << b << c;
std::cout << a << " " << b << " " << c << "\n";
a << b << c;
std::cout << a << " " << b << " " << c << "\n";
a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
a >> b >> c;
std::cout << a << " " << b << " " << c << "\n";
}
Do you see what I mean now?
Note that the only difference is which "side" is referenced in the
return. Note also that you get the same results, in both cases, if you
bracket the expression the "other" way: a << (b << c).
Since this is comp.lang.c, here it is in C. But with no operators and
using explicit pointers to "fake" the lvalue, it's all much less clear.
int *swapl(int *a, int *b) { int t = *a; *a = *b; *b = t; return a; }
int *swapr(int *a, int *b) { int t = *a; *a = *b; *b = t; return b; }
#include <stdio.h>
int main(void)
{
int a = 1, b = 2, c = 3;
printf("%d %d %d\n", a, b, c);
swapl(swapl(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
swapl(swapl(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
swapl(swapl(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
swapr(swapr(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
swapr(swapr(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
swapr(swapr(&a, &b), &c);
printf("%d %d %d\n", a, b, c);
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-04 05:15 -0700 |
| Message-ID | <4c752ee6-5c30-4e8c-8d50-32a42554bb50@googlegroups.com> |
| In reply to | #136176 |
On Thursday, October 4, 2018 at 6:53:43 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > It's an arbitrary choice. >< returns the left side, ><= returns > > the right side, but apart from moving data in two directions, it's > > otherwise identical to other operators. While shaving this morning I had the thought ><= should return the right side value, and =>< should return the left side value, and these should be called "dance" operators when they affect both sides. > I don't think you know what an lvalue is. "returns the left side" is > ambiguous in a context where you seem to be talking about ordinary > values and I am talking about lvalues. Both sides are being updated. The normal nomenclature does not lend well to this type of dual target. > >> You can't assign to the result of an expression that yields an ordinary > >> value (like (a + b) = c) and you should not be able to swap c with the > >> result of an expression that yields an ordinary value. That's why I > >> pointed out that a >< b should really be an lvalue expression, not an > >> ordinary one. > > > > I understand your point. > > No, I really don't think you do. Oh I really do. > Can you at least see how a >< b >< c > rotates the contents of a, b and c if >< is an lvalue expression? Yes, but it isn't, nor can it be. > If > not (and you certainly claimed before that it doesn't) then you are not > seeing what I am suggesting. I see what you're suggesting, and did see before also. I think you are wrong in your thinking. > Why, if you favour having a > swap operator, would you not want a >< b >< c to have a useful meaning? It does (as I demonstrated). > You can still use a >< b in other expressions (since lvalues "decay" to > ordinary values). > > If you also make ><= be an lvalue expression you get a ><= b ><= c being > a rotate in the other direction. What is there to disagree with here? It doesn't work that way. The result would be an rvalue with a required special consideration due to the dual target updates. > (By the way, if I were going to provide both operators I'd make them > mirrors of each other, for example =>< and ><=. My same thought this morning. > However, I don't think > there is much value in having both.) One returns the right hand value, the other the left. Much value. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 13:48 +0100 |
| Message-ID | <T_ntD.539744$Hv.229556@fx27.am4> |
| In reply to | #136180 |
On 04/10/2018 13:15, Rick C. Hodgin wrote:
> One returns the right hand value, the other the left. Much value.
Do you have real code that could improved using a value-returning swap?
I'd looked through a very old codebase today of 120,000 lines (when I
used to use ":=:"), and found 15 instances. Most of them were associated
with sort routines, but also with code for shuffling or scrambling.
Four of them were found in just one Quicksort routine [scripting code]:
function quicksort(a,cmpfn,ll,rr)=
if ll>=rr then return fi
a[ll] :=: a[(ll+rr)%2] # % is integer division
lastx:=ll
for i:=ll+1 to rr do
if cmpfn.defined then
if cmpfn^(a,i,ll) then
a[++ll] :=: a[i]
fi
else
if a[i]<a[ll] then
a[++ll] :=: a[i]
fi
fi
od
a[ll]:=:a[lastx]
quicksort(a,cmpfn,ll,lastx-1)
quicksort(a,cmpfn,lastx+1,rr)
end
Four uses of :=: (swap), and none of then need a return value. So, do
you have any similar examples where the need for swap with a return
value is clear? (I don't mean contrived ones that no one can make any
sense of.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-04 10:56 -0400 |
| Message-ID | <pp59nf$tai$2@dont-email.me> |
| In reply to | #136183 |
On 10/4/2018 8:48 AM, Bart wrote:
> On 04/10/2018 13:15, Rick C. Hodgin wrote:
>> One returns the right hand value, the other the left. Much value.
>
> Do you have real code that could improved using a value-returning swap?
I don't know how to search for such a thing. From my memory,
there have been a dozen times over the years I've had to do
the t = a, a = b, b = t swap, and it would've been nice to
have an operator to do it.
But, I've also never had an operator to do it. So, if I had
that tool, how differently might I have written some of my
code.
On the x86 it's very efficient too, using only one register:
mov eax,a
xchg eax,b
mov a,eax
> Four uses of :=: (swap), and none of then need a return value. So, do you
> have any similar examples where the need for swap with a return value is
> clear? (I don't mean contrived ones that no one can make any sense of.)
I cannot recall any specific instances off the top of my
head which stand out. I just remember needing that ability
at various times, and doing it the long way.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 17:47 +0100 |
| Message-ID | <878t3dpsl6.fsf@bsb.me.uk> |
| In reply to | #136180 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Thursday, October 4, 2018 at 6:53:43 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > It's an arbitrary choice. >< returns the left side, ><= returns >> > the right side, but apart from moving data in two directions, it's >> > otherwise identical to other operators. > > While shaving this morning I had the thought ><= should return > the right side value, and =>< should return the left side value, > and these should be called "dance" operators when they affect both > sides. > >> I don't think you know what an lvalue is. "returns the left side" is >> ambiguous in a context where you seem to be talking about ordinary >> values and I am talking about lvalues. > > 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. >> >> You can't assign to the result of an expression that yields an ordinary >> >> value (like (a + b) = c) and you should not be able to swap c with the >> >> result of an expression that yields an ordinary value. That's why I >> >> pointed out that a >< b should really be an lvalue expression, not an >> >> ordinary one. >> > >> > I understand your point. >> >> No, I really don't think you do. > > Oh I really do. Then what was that long detailed post showing that a >< b >< c did not do as I said? 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? >> Can you at least see how a >< b >< c >> rotates the contents of a, b and c if >< is an lvalue expression? > > Yes, but it isn't, nor can it be. I'm sorry, but this makes it clear that you don't know what I'm taking about. Can you give a short summary of what you think I mean by an expression being a lvalue expression? Even if you just gave a few example of lvalue expressions in C, I'd have some idea where the confusion lies. >> If >> not (and you certainly claimed before that it doesn't) then you are not >> seeing what I am suggesting. > > I see what you're suggesting, and did see before also. I think > you are wrong in your thinking. > >> Why, if you favour having a >> swap operator, would you not want a >< b >< c to have a useful meaning? > > It does (as I demonstrated). If you think what you posted was useful, but a circular three-way swap is not, then we simply have very different metrics of useful and I don't see any point in debating that. If you've got some code that makes use of your proposed semantics, then we can discuss that. >> You can still use a >< b in other expressions (since lvalues "decay" to >> ordinary values). >> >> If you also make ><= be an lvalue expression you get a ><= b ><= c being >> a rotate in the other direction. What is there to disagree with here? > > It doesn't work that way. The result would be an rvalue with a required > special consideration due to the dual target updates. What does that mean? >> (By the way, if I were going to provide both operators I'd make them >> mirrors of each other, for example =>< and ><=. > > My same thought this morning. > >> However, I don't think >> there is much value in having both.) > > 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? With pre- and post-increment there is a clear and useful difference. In languages that have assignment expressions and displacement expressions (assignments that return the old value) again, there is a clear advantage to having both, but swap is not like either of these. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-04 11:01 -0700 |
| Message-ID | <3f3b2fe4-5729-432c-889e-2f016b52dc45@googlegroups.com> |
| In reply to | #136204 |
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. I think the same can be said with something like
++x. It is a unary value that's computed, then stored.
> > 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. I misunderstood your post. My reply was to
correct what I thought was your misunderstanding.
> 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.
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.
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;
If you take the same general logic applied to the >< in this
case, and extend it to the = family (=, *=, += ...), then you
could have it work that way:
2 *= d;
3 += c;
In such a case, if either side could be a valid solid target,
then why not? I was thinking about this on the drive in to
work today. It really opens up a whole new ball game for C.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-04 22:15 +0200 |
| Message-ID | <pp5scn$ugm$1@dont-email.me> |
| In reply to | #136210 |
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? 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.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-04 16:19 -0400 |
| Message-ID | <pp5sjp$v8g$1@dont-email.me> |
| In reply to | #136221 |
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. > 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. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 21:42 +0100 |
| Message-ID | <IWutD.284123$cw.210820@fx39.am4> |
| In reply to | #136223 |
On 04/10/2018 21: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.
So it means the same as:
d = (a + b + c);
? Yes, very handy, it'll save loads of typing, and you'll be able to do
this:
0 = a;
What you are saying is that, if an assignment doesn't have a legal
lvalue on the left, but the RHS happens to be one, then you will just
quietly reverse the assignment order, rather than raise an error.
> 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.
Suppose both LHS and RHS are complicated; the reader of the code now has
to do a careful analysis of the line to see if it's doing this assignment:
LHS <= RHS;
or this one:
RHS <= LHS;
What happens with:
(a + b + c) += d; ?
Sorry, I'm having some fun, but this is truly terrible idea.
>> 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 sounds like that deadline is going to get longer and longer. Can you
do this right now:
int a, b, c;
a = 2;
b = 3;
c = a + b;
printf("%d",c);
and get a result of 5? If not, perhaps pay that some attention first. (I
think even fir has passed this stage.)
And if you have, then make it available for people to try out.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-04 15:01 -0700 |
| Message-ID | <9d5c4ae9-47ef-4da0-9b39-e7dbc96ab1be@googlegroups.com> |
| In reply to | #136227 |
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, adding in features that exist so why not have them available, and the like? I'm trying to build an all-time tool for people to use. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 23:59 +0100 |
| Message-ID | <AXwtD.11298$PI.11041@fx25.am4> |
| In reply to | #136232 |
On 04/10/2018 23:01, 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, adding in features that exist so
> why not have them available, and the like?
>
> I'm trying to build an all-time tool for people to use.
This particular feature would be a nightmare to explain to anyone else.
And I can't see the point:
d += (a + b + c);
(a + b + c) += d;
Both use the same selection and number of characters. Why would anyone
need to do it the other way?
My language used ":=" for right-to-left assignment, so why not "=:" for
left-to-right? So you can choose between:
a := b
b =: b
The idea is that now someone can choose a LTR or RTL assignment style,
and stick to it.
But imagine reading through source code, and some assignments use :=,
some use =:, all mixed up. And what is:
a =: b := c
supposed to mean?
You proposal would have all these issues, plus one very important one:
you use the same "=" operator for both RTL and LTR assignments! So
people will have to stop and analyse the code to even see what is being
assigned to what. And what would this mean:
0 = a = 1;
It's not clear whether you are serious about creating a language, or are
just interesting in inventing a big bunch of wacky ideas. If it's the
latter, then it's OK, it's quite entertaining. But it doesn't sound like
the language will ever get off the ground.
What I remember so far are loads of mysterious new symbols which never
work quite the obvious way you might expect, there's always something
off-kilter about them. Then you have those strange casks, which I see as
another pile of punctuation that I haven't a clue what they do.
The whole thing sounds terrible, it will look terrible and it will be
impossible to understand.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 09:54 +0200 |
| Message-ID | <pp75cb$3ef$1@dont-email.me> |
| In reply to | #136235 |
On 05/10/18 00:59, Bart wrote: > On 04/10/2018 23:01, 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, adding in features that exist so >> why not have them available, and the like? >> >> I'm trying to build an all-time tool for people to use. > > This particular feature would be a nightmare to explain to anyone else. > And I can't see the point: > > d += (a + b + c); > (a + b + c) += d; > > Both use the same selection and number of characters. Why would anyone > need to do it the other way? > > My language used ":=" for right-to-left assignment, so why not "=:" for > left-to-right? So you can choose between: > > a := b > b =: b > > The idea is that now someone can choose a LTR or RTL assignment style, > and stick to it. > > But imagine reading through source code, and some assignments use :=, > some use =:, all mixed up. And what is: > > a =: b := c > > supposed to mean? If I were making a new programming language, assignment would be a statement - not an expression. So that would mean "syntax error". (I know not everyone agrees with me on this point.) That would make assignment unambiguous whether it is written "a := b;" or "b =: a;". While it is more common to have "assign to the left", it is entirely possible to have "assign to the right" (I have seen that written with an arrow, "b -> a", rather than "b =: a" - read as "b goes to a"). But as you say, if the two styles are mixed it becomes extremely difficult to read the code. > > You proposal would have all these issues, plus one very important one: > you use the same "=" operator for both RTL and LTR assignments! So > people will have to stop and analyse the code to even see what is being > assigned to what. And what would this mean: > > 0 = a = 1; > > It's not clear whether you are serious about creating a language, or are > just interesting in inventing a big bunch of wacky ideas. If it's the > latter, then it's OK, it's quite entertaining. But it doesn't sound like > the language will ever get off the ground. > > What I remember so far are loads of mysterious new symbols which never > work quite the obvious way you might expect, there's always something > off-kilter about them. Then you have those strange casks, which I see as > another pile of punctuation that I haven't a clue what they do. > > The whole thing sounds terrible, it will look terrible and it will be > impossible to understand. > Agreed 100%. (I hope that doesn't shock you too much!)
[toc] | [prev] | [next] | [standalone]
Page 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web