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 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-07 15:04 +0100 |
| Message-ID | <eoouD.1348$Do.1024@fx31.am4> |
| In reply to | #136381 |
On 07/10/2018 14:19, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 06/10/2018 19:49, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> Isn't a semicolon statement terminator? That sounds like, without a >>>> semicolon, a statement (including an expression in the correct >>>> context) is still a statement, just not terminated yet. >>> >>> You are welcome to call "x = 1" an unterminated statement but it's >>> simpler to call it what it is (in C) -- we are talking about C, yes? >>> >>>> Anyway, the demarcation I make is much [more] rigid than this >>> >>> In C? >> >> Outside of C, I went from... > > Ah. I'm hope you won't think it rude, but I have no reason to be > interested in what you did in your language. There are hundreds of > programming languages, and many of them are well-documented, stable, and > usable on my system. It would be much better, if you want to illustrate > a point, to pick a publicly documented language to do it. > >> So, strict demarcation in C between statements and expressions? Not >> really. > > Yes, really. I don't want to be rude either. But arguing that it is so because of some wording in the standard, doesn't change the fact that, for all practical purposes, there isn't any, as I showed. Not for using an expression as a statement (and not for using a statement as an expression when using certain extensions). I think that having them strictly separate (properly so not like in C) has certain advantages. For one, you can choose to talk about a new feature such as the ability to exchange the values of two objects, as a new statement rather than an expression, which latter opens up a can of worms as has been seen. And the advantage of /that/ from my POV, is that I have been enjoying the benefits of such a feature for many years. While you lot are still squabbling about what it might mean. (And FWIW, the way statements and expressions worked in my original language was based heavily on Algol68, which is well-documented. For various other reasons, I moved away from that, and the languages are now easier to implement and to explain, and make it easier to catch a range of errors.) >> C /needs/ expressions as statements to be able to do any work. > > C needs expression statements -- statements formed from an expression > and a semicolon -- to work. Ergo, any expression can be a statement - you just use it wherever an executable statement would be allowed. That you need a semicolon after it, is because any such terminal statement needs one. Leaving it out won't give you an expression, more likely a syntax error. > If you dislike expression statements (and, off the top of my head, I > can't think of anything about C that you don't dislike) your time would > be better spent explaining why that is, rather than repeating statements > that are just going to generate "yes it is", "no it isn't" exchanges. I didn't like the overlap between expressions and statements just because some of the former are useful as statements. If it's not possible to have it Algol-68 style with no separation at all, then I prefer that they were completely separate, which also has an elegance of its own. (This means, in my implementation, that each needs its own version of assign, function-call, and increment, but that also helps highlight the real differences: expression-assign always returns a value; statement-assign never returns a value.) -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-07 16:37 +0100 |
| Message-ID | <87efd1hinl.fsf@bsb.me.uk> |
| In reply to | #136385 |
Bart <bc@freeuk.com> writes: > On 07/10/2018 14:19, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 06/10/2018 19:49, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> Isn't a semicolon statement terminator? That sounds like, without a >>>>> semicolon, a statement (including an expression in the correct >>>>> context) is still a statement, just not terminated yet. >>>> >>>> You are welcome to call "x = 1" an unterminated statement but it's >>>> simpler to call it what it is (in C) -- we are talking about C, yes? >>>> >>>>> Anyway, the demarcation I make is much [more] rigid than this >>>> >>>> In C? >>> >>> Outside of C, I went from... >> >> Ah. I'm hope you won't think it rude, but I have no reason to be >> interested in what you did in your language. There are hundreds of >> programming languages, and many of them are well-documented, stable, and >> usable on my system. It would be much better, if you want to illustrate >> a point, to pick a publicly documented language to do it. >> >>> So, strict demarcation in C between statements and expressions? Not >>> really. >> >> Yes, really. > > I don't want to be rude either. But arguing that it is so because of > some wording in the standard, doesn't change the fact that, for all > practical purposes, there isn't any, as I showed. If we go back and forth a few dozen times, maybe we will arrive at wording that neither up will be bother to object to any more. Do you think that is worth you time? I am not sure what purpose would be served by going back and forth like this. > Not for using an expression as a statement (and not for using a > statement as an expression when using certain extensions). > > I think that having them strictly separate (properly so not like in C) > has certain advantages. > > For one, you can choose to talk about a new feature such as the > ability to exchange the values of two objects, as a new statement > rather than an expression, which latter opens up a can of worms as has > been seen. Nonsense. You allow ++x to be a statement because you make it so by fiat. You could do the same for a swap. Anyway, a swap operator is not a can of worms. The fuss was all from one poster who grip on reality is tenuous. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-07 16:58 +0100 |
| Message-ID | <z2quD.50547$px6.46626@fx41.am4> |
| In reply to | #136387 |
On 07/10/2018 16:37, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> For one, you can choose to talk about a new feature such as the >> ability to exchange the values of two objects, as a new statement >> rather than an expression, which latter opens up a can of worms as has >> been seen. > > Nonsense. You allow ++x to be a statement because you make it so by > fiat. You could do the same for a swap. Apparently, if it looks like an operator, then it must have a return value; and if it looks likes a function, then it must behave like a regular function. That's what seemed to come across. That may be erroneous thinking, but it means it can make it harder to put across such features to people familiar with C. > Anyway, a swap operator is not a can of worms. The fuss was all from > one poster who grip on reality is tenuous. There was at least one other poster keen for swap to have a return value. That what the value ought to be isn't at all obvious, is a good reason for there not to be one. -- bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-07 12:17 -0400 |
| Message-ID | <ppdbjm$1am$1@dont-email.me> |
| In reply to | #136388 |
On 10/07/2018 11:58 AM, Bart wrote:
> There was at least one other poster keen for swap to have a return value.
>
> That what the value ought to be isn't at all obvious, is a good reason
> for there not to be one.
If you use the two syntaxes, it lends itself clearly to which
one should be in each case:
=>< // Return left-side after swap
><= // Return right-side after swap
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-10-07 20:37 +0000 |
| Subject | Grammar police! (Was: >< swap operator) |
| Message-ID | <ppdqq7$708$1@news.xmission.com> |
| In reply to | #136387 |
In article <87efd1hinl.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: ... >Anyway, a swap operator is not a can of worms. The fuss was all from >one poster who grip on reality is tenuous. Somebody's grip on grammar is tenuous. Note: I'm not just picking on this one instance. The previous post by this poster (now mostly snipped) was riddled with errors. -- Rich people pay Fox people to convince middle class people to blame poor people. (John Fugelsang)
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-10-07 09:31 -0700 |
| Message-ID | <3d46f51b-bfcf-4966-8528-aa586e5e0cdb@googlegroups.com> |
| In reply to | #136385 |
On Sunday, October 7, 2018 at 10:05:10 AM UTC-4, Bart wrote:
> On 07/10/2018 14:19, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> On 06/10/2018 19:49, Ben Bacarisse wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>
> >>>> Isn't a semicolon statement terminator? That sounds like, without a
> >>>> semicolon, a statement (including an expression in the correct
> >>>> context) is still a statement, just not terminated yet.
Would you refer to a+b in the following statement as an unterminated
statement?
if(a + b == c) continue;
How about "a+b==c"?
If you consider both of those to be "unterminated statements", then you
need to realize that a great many unterminated statements never get
terminated by a semicolon. Many "unterminated statements" occur as sub
expressions of other expressions. Other "unterminated statements" occur
in locations (such as the condition portion of an if() statement) where
it would be a syntax error to terminate them with a ';'. Which make
"unterminated statement" a very odd name to use for such things. I
prefer to call them "expression", and not just because it's shorter.
> >> So, strict demarcation in C between statements and expressions? Not
> >> really.
> >
> > Yes, really.
>
> I don't want to be rude either. But arguing that it is so because of
> some wording in the standard, doesn't change the fact that, for all
> practical purposes, there isn't any, as I showed.
That's funny - for the very practical purpose of getting my programs to
compile, I've always found it very difficult to use an expression in a
location where a statement is required, or vice versa. Is your
experience different? Can you tell us which compilers will accept the
following code without any trouble?
if(a+b+c; == 0) a+b+c
else return;
> > C needs expression statements -- statements formed from an expression
> > and a semicolon -- to work.
>
> Ergo, any expression can be a statement - you just use it wherever an
> executable statement would be allowed.
My code above uses an expression in a location (the if-clause of an if-
statement) where an tatement is required. It doesn't work with any
compiler that I know of. Do you know of any?
> ... That you need a semicolon after
> it, is because any such terminal statement needs one.
Yes, and it doesn't become a statement until that semicolon has been
added to it. If you take a molecule of oxygen, and add two moloecules
of hydrogen and either sufficient heat or a catalyst, it will become two
water molecules. Does that meant that an oxygen molecule IS two water
molecules? No, because you have to combine it with something else before
it qualifies as water. An expression followed by a ';' is an expression-
statement. That does not in any sense mean that the expression itself is
a statement.
> Leaving it out
> won't give you an expression, more likely a syntax error.
Well, of course. In real code, if you find an expression-statement,
replacing it with an expression is always a syntax error, because you
will only find statements in locations where expressions are not
permitted. This does not in any way support your claim - it is solid
proof that an expression is something different from an expression-
statement; if they were the same, the removal of the semicolon wouldn't
matter. Similarly, in most cases where you find an expression, a
statement would be syntax error. One exception: between an expression
and the ';' that together make an expression-statement, you can insert
another ';' before the last one. The net result is to turn the second ';'
into an empty statement - which is perfectly legal in C, but would never
be of any use in such a context (it can be useful for creating a loop
with no body).
However, there are certainly cases where removing a semicolon to make
something an expression will work - they must, inherently, be locations
where an expression-statement would be a syntax error:
if(a+b+c; = 0) exit();
> > If you dislike expression statements (and, off the top of my head, I
> > can't think of anything about C that you don't dislike) your time would
> > be better spent explaining why that is, rather than repeating statements
> > that are just going to generate "yes it is", "no it isn't" exchanges.
>
> I didn't like the overlap between expressions and statements just
Show me one thing that, when parsed according to the C grammar,
qualifies as both an expression and a statement. There is no such thing,
so there is no overlap.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-07 18:09 +0100 |
| Message-ID | <w5ruD.26058$1C7.3383@fx38.am4> |
| In reply to | #136392 |
On 07/10/2018 17:31, jameskuyper@alumni.caltech.edu wrote:
> On Sunday, October 7, 2018 at 10:05:10 AM UTC-4, Bart wrote:
>> Ergo, any expression can be a statement - you just use it wherever an
>> executable statement would be allowed.
>
> My code above uses an expression in a location (the if-clause of an if-
> statement) where an tatement is required. It doesn't work with any
> compiler that I know of. Do you know of any?
>
>> ... That you need a semicolon after
>> it, is because any such terminal statement needs one.
>
> Yes, and it doesn't become a statement until that semicolon has been
> added to it.
So, that applies to 'return' too? In which case there is little difference.
Take this statement:
return;
Now, replace the 'return' with any expression.
Will it still compile? (Assume there is no issue with resolving names
and there is no problem with the types.)
If it does, then the separation from expression to statement is weak.
> if(a+b+c; = 0) exit();
Take a working program. Find a place where a semicolon follows what
could be used as an expression in an expression context. Now remove the
semicolon. If it still compiles, it means it's joined on to the next
statement to form a longer expression. Find the semicolon on the end of
that, and repeat.
Perhaps you've forgotten what I'm trying to show, which is you can take
ANY expression in C, and put it where you would write any other
statement, or use it to replace any other statement.
There is nothing to stop you doing that. Therefore nothing that stops
any expression being used as a statement. Therefore there is no
demarcation between them. At least not in that direction.
(Going the other way, there is, in standard C.)
> Show me one thing that, when parsed according to the C grammar,
> qualifies as both an expression and a statement. There is no such thing,
> so there is no overlap.
Forget the grammar; first show me an expression that can't replace the
'return' here:
return;
For example:
2+2
is a expression, and:
2+2;
is a statement. The only difference is that, without the semicolon, 2+2
can only be used in certain contexts.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-10-07 14:05 -0700 |
| Message-ID | <e44d5b48-970b-4d56-bfff-df85b608d5bf@googlegroups.com> |
| In reply to | #136395 |
On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote:
> On 07/10/2018 17:31, jameskuyper@alumni.caltech.edu wrote:
> > On Sunday, October 7, 2018 at 10:05:10 AM UTC-4, Bart wrote:
>
> >> Ergo, any expression can be a statement - you just use it wherever an
> >> executable statement would be allowed.
> >
> > My code above uses an expression in a location (the if-clause of an if-
> > statement) where an tatement is required. It doesn't work with any
> > compiler that I know of. Do you know of any?
> >
> >> ... That you need a semicolon after
> >> it, is because any such terminal statement needs one.
> >
> > Yes, and it doesn't become a statement until that semicolon has been
> > added to it.
>
> So, that applies to 'return' too? In which case there is little difference.
>
> Take this statement:
>
> return;
Correct. "return" is just a keyword. "return;" is a jump-statement.
"a+b" is an expression, "a+b;" is an expression-statement. This is a
perfect analogy.
The C standard distinguishes 12 kinds of statements. The expression-
statement, null-statement, and the 4 kinds of just statement must end
with a semicolon. The other 6 do not. If you take any type of statement
that ends with a semicolon, and replace the part before the semicolon
with something else that also makes it a statement, then you have shown
us a way to transform statements. What's your point? That doesn't make
the part the precedes the semicolon a statement, and it doesn't make the
full statement an expression.
> If it does, then the separation from expression to statement is weak.
I can't figure out the point of your objection. Would you feel happier
if the syntax for an expression-statement was more obtrusive?:
_Begin_Statement newline tab a = b + c newline _End_Statement
> > if(a+b+c; = 0) exit();
>
> Take a working program. Find a place where a semicolon follows what
> could be used as an expression in an expression context. Now remove the
> semicolon. If it still compiles,
That will never happen. There is no grammar rules that permit two
consecutive expressions to occur with nothing in between them. The
closest you can get is the comma operator.
> Perhaps you've forgotten what I'm trying to show, which is you can take
> ANY expression in C, and put it where you would write any other
> statement, or use it to replace any other statement.
So, I can replace the statement "a+b+c;" in the following code:
if(error) a = b+c;
else printf("Success\n");
and replace it with the expression "d > f"? When I tried it, my compiler objected:
if (error) d > f
else printf("Success\n");
> There is nothing to stop you doing that.
The fact that the semicolon is missing seems to have stopped it cold.
Care to try to describe what you're talking about in terms that don't
fail so trivially?
> > Show me one thing that, when parsed according to the C grammar,
> > qualifies as both an expression and a statement. There is no such thing,
> > so there is no overlap.
>
> Forget the grammar;
I can't. "expression" (6.5.17p1) and "statement" (6.8p1) are key
elements of the C grammar. If you're saying anything about expressions
or statements for which the C grammar is irrelevant, then the meaning
you've attached to those terms is irrelevant to a discussion of C. It
might be that with your personal definitions of expression and
statement, it is true that C expressions and C expression-statements
qualify for both categories - but that means that you're personal
definitions fail to capture a distinction that is vital to writing
syntactically correct C code. Try it: convert anything that the C
parses as an expression-statement in any program you care to
choose, and remove the ';', causing it to parse as an expression
according to the C grammar. Does your program still compile?
> first show me an expression that can't replace the
> 'return' here:
>
> return;
A return statement is a valid statement type. Any place that a empty
return statement is valid, an expression-statement is also valid. If
you replace "return" with an otherwise-valid expression, you form an
expression-statement which would also be allowed in that location. Congratulations! You've shown how to convert a return statement into an
expression-statement. You've not demonstrated any kind of equivalence of
expressions and statements. You could demonstrate such equivalence by
replacing a return statement with an expression:
void func(void) { return ;}
=> void func(void) { f() > g() }
but that doesn't work, so they aren't equivalent.
> For example:
>
> 2+2
>
> is a expression, and:
>
> 2+2;
>
> is a statement. The only difference is that, without the semicolon, 2+2
> can only be used in certain contexts.
How is that a difference? The return keyword can only be used in certain
contexts. Consider the following statements:
if(2+2) {...}
while(2+2) {...}
for(2+2; 2+2; 2+2) {...}
do {...} while(2+2);
switch(2+2) {...}
return 2+2;
If you can get any of those to compile (with suitable replacements
for {...} with any instance of "2+2" replaced by either "return" or
"return;" you'd be much closer to supporting your claim that
expressions are statements.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-07 22:35 +0100 |
| Message-ID | <q_uuD.6638$8g.3902@fx08.am4> |
| In reply to | #136400 |
On 07/10/2018 22:05, jameskuyper@alumni.caltech.edu wrote:
> On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote:
>> If it does, then the separation from expression to statement is weak.
>
> I can't figure out the point of your objection. Would you feel happier
> if the syntax for an expression-statement was more obtrusive?:
>
> _Begin_Statement newline tab a = b + c newline _End_Statement
Maybe.
I can see from the rest of your post that you don't understand what it
is that I'm talking about. So let's try a different tack. I don't like
being able to write lines like the following at statement level:
cond ? f() : g();
1234;
"abcd";
a + b;
puts("one") + puts("two");
f()+1;
10,20,30,40;
puts("three"), puts("four"), puts(five");
A[i];
a == b;
These are all expressions followed by a semicolon. They count as
expressions because if you take each line, and remove the semicolon, it
can be used anywhere an expression is expected.
The reason I don't like them is partly that some just don't make sense,
as they work out a value that is then discarded. And therefore are a
likely a mistake.
And partly because I think they some are bad form to use as statements,
for example using ?: instead of if-else, or comma operators instead of
semicolons.
But C makes it just too easy to do it. To turn any arbitrary expression
as a statement like this, you just write it. And follow it with
semicolon, or a comma if you want a list of them.
So, what is there in C that would stop you doing that?
If the answer is Nothing, (other than some compilers may say something)
then that's what I call a weak demarcation.
BTW, the following kinds of expression terms I consider meaningful for
use as standalone statements:
a = b;
++ a;
a += b;
f();
>> Take a working program. Find a place where a semicolon follows what
>> could be used as an expression in an expression context. Now remove the
>> semicolon. If it still compiles,
>
> That will never happen. There is no grammar rules that permit two
> consecutive expressions to occur with nothing in between them. The
> closest you can get is the comma operator.
Take these two statements:
a = b;(c+b);
if you remove the first semicolon, you get this:
a = b(c+d);
which is syntactically sound, and might still compile if the types of
everything involved are suitable.
Or a simpler example:
"abc"; "def";
becomes:
"abc" "def";
which is now one term.
> I can't. "expression" (6.5.17p1) and "statement" (6.8p1) are key
I'm not interested in grammar. Only in what it means in making it easier
to write nonsense code, as I showed in my examples.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-08 02:56 +0100 |
| Message-ID | <87tvlxfbfb.fsf@bsb.me.uk> |
| In reply to | #136401 |
Bart <bc@freeuk.com> writes:
> I can see from the rest of your post that you don't understand what it
> is that I'm talking about. So let's try a different tack. I don't like
> being able to write lines like the following at statement level:
>
> cond ? f() : g();
> 1234;
> "abcd";
> a + b;
> puts("one") + puts("two");
> f()+1;
> 10,20,30,40;
> puts("three"), puts("four"), puts(five");
> A[i];
> a == b;
That is, indeed, a new tack. If this was your point all along, you
could have saved everyone a lot of trouble.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-08 10:48 +0200 |
| Message-ID | <ppf5lc$u6v$1@dont-email.me> |
| In reply to | #136401 |
On 07/10/18 23:35, Bart wrote:
> On 07/10/2018 22:05, jameskuyper@alumni.caltech.edu wrote:
>> On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote:
>
>>> If it does, then the separation from expression to statement is weak.
>>
>> I can't figure out the point of your objection. Would you feel happier
>> if the syntax for an expression-statement was more obtrusive?:
>>
>> _Begin_Statement newline tab a = b + c newline _End_Statement
>
> Maybe.
>
> I can see from the rest of your post that you don't understand what it
> is that I'm talking about.
I think that applies to more than one reader in this thread. I've not
been convinced /you/ understand what you are talking about. But I think
your post here makes your position a little clearer.
> So let's try a different tack. I don't like
> being able to write lines like the following at statement level:
Let us be entirely clear here. Is the issue simply that you don't
/like/ the way C distinguishes between statements and expressions, and
that any expression can be used in an expression statement?
Opinions are fine. I would entirely agree with you that some kinds of
expressions are unlikely to be appropriate for expression statements,
and are an indication of bugs in code, or at least poor structuring.
But let us first be sure you understand the way C works here - once you
know the rules, it is possible to ask /why/ the rules are that way or to
say why you don't like them.
C has a number of types of statement. These include "return"
statements, "for" statements, and so on. All statement types either end
in a semicolon as part of the statement itself, or are immediately
followed by another statement.
C has a number of types of expression. These evaluate to a value, or to
"void".
One very common type of statement is the "expression statement". The is
formed by taking a valid expression and appending a semicolon. It means
that the expression should be evaluated for its side-effects, and the
result discarded. (The compiler doesn't have to generate any code
beyond the side-effects, but that's just an optimisation issue.)
Common examples of expression statement are assignments and function
calls where the result is void or a return value that is ignored by the
code. So "printf("Hello, world!\n");" is an expression statement.
>
> cond ? f() : g();
> 1234;
> "abcd";
> a + b;
> puts("one") + puts("two");
> f()+1;
> 10,20,30,40;
> puts("three"), puts("four"), puts(five");
> A[i];
> a == b;
>
> These are all expressions followed by a semicolon. They count as
> expressions because if you take each line, and remove the semicolon, it
> can be used anywhere an expression is expected.
True.
>
> The reason I don't like them is partly that some just don't make sense,
> as they work out a value that is then discarded. And therefore are a
> likely a mistake.
In many of these example cases, the expression statements are likely a
mistake - if there are no side-effects, they don't add anything useful
to the code.
>
> And partly because I think they some are bad form to use as statements,
> for example using ?: instead of if-else, or comma operators instead of
> semicolons.
I agree that such coding can make the program harder to read and
understand, and thus it is a bad idea.
>
> But C makes it just too easy to do it. To turn any arbitrary expression
> as a statement like this, you just write it. And follow it with
> semicolon, or a comma if you want a list of them.
(I am not a fan of the comma operator, and won't argue in its favour.
But I appreciate that some people /do/ like it in certain contexts, and
it is part of C regardless.)
C makes it easy to make expression statements from expressions. This is
a matter of convenience and simplicity. That does not mean it is a
/good/ idea to turn any expression into a statement by adding a
semicolon - merely that it is /possible/. It makes the grammar of the
language much simpler than if it tried to have a distinction between
expressions that could be used in expression statements, and expressions
that could not (and perhaps another class for expressions that /had/ to
be used in expression statements and not as sub-expressions).
No language can rule out bad code or people writing silly or meaningless
code. If the language banned "a + b;", people would find other ways to
write nonsense.
The C rules make it easy to have a function like "printf" that returns a
value that people sometimes want, but will often ignore. And since
expressions in C can have side-effects (calling a function, assigning a
value, incrementing, accessing volatile data, etc.) then it is regularly
useful to use these as expression statements.
An effect of this flexibility is the flexibility to write silly code.
That's life in the programming world - with power comes responsibility
to write sensible code.
(Compilers can, and do, offer warnings when they see particularly silly
code in some cases.)
>
> So, what is there in C that would stop you doing that?
>
> If the answer is Nothing, (other than some compilers may say something)
> then that's what I call a weak demarcation.
>
> BTW, the following kinds of expression terms I consider meaningful for
> use as standalone statements:
>
> a = b;
> ++ a;
> a += b;
> f();
>
>>> Take a working program. Find a place where a semicolon follows what
>>> could be used as an expression in an expression context. Now remove the
>>> semicolon. If it still compiles,
>>
>> That will never happen. There is no grammar rules that permit two
>> consecutive expressions to occur with nothing in between them. The
>> closest you can get is the comma operator.
>
> Take these two statements:
>
> a = b;(c+b);
>
> if you remove the first semicolon, you get this:
>
> a = b(c+d);
>
> which is syntactically sound, and might still compile if the types of
> everything involved are suitable.
Take the statement "a += 1;" and change the "+" for a "-". You've made
a tiny little single-character change, but now you are doing something
entirely different and have probably broken the code. And yet the
compiler still accepts it without even a warning! The horror! The
compiler is expecting /you/ to write the code correctly - how selfish of it.
>
> Or a simpler example:
>
> "abc"; "def";
>
> becomes:
>
> "abc" "def";
>
> which is now one term.
>
>
>> I can't. "expression" (6.5.17p1) and "statement" (6.8p1) are key
>
> I'm not interested in grammar. Only in what it means in making it easier
> to write nonsense code, as I showed in my examples.
>
You can /always/ write nonsense code, in any language. There are no
exceptions. You can restrict the level of nonsense by grammar rules -
simultaneously restricting the kind of correct code you can write. At
best, all you can say is that the balance C has picked here does not
suit you. (The balance is not ideal for my tastes either.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 12:09 +0100 |
| Message-ID | <IVGuD.6644$8g.6478@fx08.am4> |
| In reply to | #136418 |
On 08/10/2018 09:48, David Brown wrote:
> On 07/10/18 23:35, Bart wrote:
>> But C makes it just too easy to do it.
> C makes it easy to make expression statements from expressions. This is
> a matter of convenience and simplicity. That does not mean it is a
> /good/ idea to turn any expression into a statement by adding a
> semicolon - merely that it is /possible/. It makes the grammar of the
> language much simpler than if it tried to have a distinction between
> expressions that could be used in expression statements, and expressions
> that could not (and perhaps another class for expressions that /had/ to
> be used in expression statements and not as sub-expressions).
Here's an attempt at a grammar for my latest language (from token level
upwards, not starting at characters):
https://github.com/sal55/mlang/blob/master/msyntax.txt
It's for a syntax that is perhaps twice as rich as C's, in terms of
numbers of statements and expression constructs. But it also doesn't
allow any arbitrary expression as a statement.
I would say it is far easier to follow than C's grammar where you can
get lost in the maze of twisty declarators.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-10-08 16:00 +0000 |
| Message-ID | <slrn3k40prmvoa.ik6.ike@iceland.freeshell.org> |
| In reply to | #136420 |
On 2018-10-08, Bart <bc@freeuk.com> wrote: > Here's an attempt at a grammar for my latest language (from token level > upwards, not starting at characters): > > https://github.com/sal55/mlang/blob/master/msyntax.txt A grammar without constraints is not very useful. For instance, with the grammar rule for an assignment statement assignstmt = term ':=' expr term can be (2+2), and expr can be 3, so the grammar allows (2+2) := 3 I guess there are constraints on the use of a term on the left side of an assignment, but those constraints are not shown. A small nit: the grammar rule op = '\'* (meaning that an operator can be a sequence of 0 or more \ characters) looks like a typo. If it's not a typo, where is the multiplication operator?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 17:44 +0100 |
| Message-ID | <uPLuD.7036$I67.4530@fx15.am4> |
| In reply to | #136428 |
On 08/10/2018 17:00, Ike Naar wrote:
> On 2018-10-08, Bart <bc@freeuk.com> wrote:
>> Here's an attempt at a grammar for my latest language (from token level
>> upwards, not starting at characters):
>>
>> https://github.com/sal55/mlang/blob/master/msyntax.txt
>
>
> A grammar without constraints is not very useful.
Someone asked about a grammar for this language I was always going on
about, and I threw this together earlier this year.
> For instance, with the grammar rule for an assignment statement
>
> assignstmt = term ':=' expr
>
> term can be (2+2), and expr can be 3, so the grammar allows
Actually, term can't be something+something, only expr can be. But yes,
the syntax allows:
2 := 3
This is intended to be a guide to parsing. lvalue-checking is in a later
pass (actually, recently I've moved it up one pass, since the way I did
it made it harder to generate C source because some transformations were
done, unsuitable for a C target).
> A small nit: the grammar rule
>
> op = '\'*
>
> (meaning that an operator can be a sequence of 0 or more \ characters)
> looks like a typo.
> If it's not a typo, where is the multiplication operator?
It's a typo, from when I'd originally attempted to use github markdown,
where actual asterisks need to be escaped (and the quotes were then put
around the \ of \* by mistake).
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-08 10:39 -0700 |
| Message-ID | <lnk1msz6a8.fsf@kst-u.example.com> |
| In reply to | #136431 |
Bart <bc@freeuk.com> writes:
> On 08/10/2018 17:00, Ike Naar wrote:
>> On 2018-10-08, Bart <bc@freeuk.com> wrote:
>>> Here's an attempt at a grammar for my latest language (from token level
>>> upwards, not starting at characters):
>>>
>>> https://github.com/sal55/mlang/blob/master/msyntax.txt
>>
>>
>> A grammar without constraints is not very useful.
>
> Someone asked about a grammar for this language I was always going on
> about, and I threw this together earlier this year.
>
>> For instance, with the grammar rule for an assignment statement
>>
>> assignstmt = term ':=' expr
>>
>> term can be (2+2), and expr can be 3, so the grammar allows
>>
>> (2+2) := 3
>
> Actually, term can't be something+something, only expr can be. But
> yes, the syntax allows:
>
> 2 := 3
>
> This is intended to be a guide to parsing. lvalue-checking is in a
> later pass
[snip]
He didn't say that
2+2 := 3
would be allowed, he said that
(2+2) := 3
would be allowed `2+2` isn't a term, but `(2+2)` is.
Parentheses, like semicolons, are significant, and cannot be ignored
when you're discussing syntax.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 20:08 +0100 |
| Message-ID | <4XNuD.4761$ik6.4142@fx09.am4> |
| In reply to | #136433 |
On 08/10/2018 18:39, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> Actually, term can't be something+something, only expr can be. But >> yes, the syntax allows: >> >> 2 := 3 >> >> This is intended to be a guide to parsing. lvalue-checking is in a >> later pass > He didn't say that > 2+2 := 3 > would be allowed, he said that > (2+2) := 3 > would be allowed `2+2` isn't a term, but `(2+2)` is. Well, OK. I think the C grammar allows the same thing. Syntax can be used for other purposes where the types of the elements involved don't matter. For example, source to source translators. -- bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-09 11:22 +0200 |
| Message-ID | <pphs16$4pk$1@dont-email.me> |
| In reply to | #136440 |
On 08/10/18 21:08, Bart wrote: > On 08/10/2018 18:39, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >>> Actually, term can't be something+something, only expr can be. But >>> yes, the syntax allows: >>> >>> 2 := 3 >>> >>> This is intended to be a guide to parsing. lvalue-checking is in a >>> later pass > >> He didn't say that >> 2+2 := 3 >> would be allowed, he said that >> (2+2) := 3 >> would be allowed `2+2` isn't a term, but `(2+2)` is. > > Well, OK. I think the C grammar allows the same thing. > The C /syntax/ allows "(2 + 2) = 3". But in addition to the syntax rules, C has "constraints", such as "an assignment operator shall have a modifiable lvalue as its left operand". A "constraint violation" is technically different from a "syntax error", but the effect in practice is usually the same as both are invalid code. Whether you split things up, like C does, or put all the rules into the syntax, is a matter of preference. > Syntax can be used for other purposes where the types of the elements > involved don't matter. For example, source to source translators. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-09 09:25 -0700 |
| Message-ID | <ln5zybytnb.fsf@kst-u.example.com> |
| In reply to | #136463 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The C /syntax/ allows "(2 + 2) = 3". But in addition to the syntax
> rules, C has "constraints", such as "an assignment operator shall have a
> modifiable lvalue as its left operand". A "constraint violation" is
> technically different from a "syntax error", but the effect in practice
> is usually the same as both are invalid code.
Yes, I think we had already covered all this.
> Whether you split things up, like C does, or put all the rules into the
> syntax, is a matter of preference.
Not really. How would you enforce the prohibition on
x = 42;
where x is defined as "const" or is an enumeration constant using just
syntax rules?
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-09 20:43 +0200 |
| Message-ID | <ppiss8$nnu$1@dont-email.me> |
| In reply to | #136489 |
On 09/10/18 18:25, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The C /syntax/ allows "(2 + 2) = 3". But in addition to the syntax
>> rules, C has "constraints", such as "an assignment operator shall have a
>> modifiable lvalue as its left operand". A "constraint violation" is
>> technically different from a "syntax error", but the effect in practice
>> is usually the same as both are invalid code.
>
> Yes, I think we had already covered all this.
>
>> Whether you split things up, like C does, or put all the rules into the
>> syntax, is a matter of preference.
>
> Not really. How would you enforce the prohibition on
> x = 42;
> where x is defined as "const" or is an enumeration constant using just
> syntax rules?
>
I am reasonably sure it would be possible - but it would involve a good
deal more complex syntax grammar. You'd have to have something
equivalent to "modifiable lvalues" as a type of term ("non-terminal" may
be the right word in BNF parlance) that is distinct from
"unary-expression" as defined in the C standards. Perhaps it would
easier if you did away with "const" - some people (for reasons I can't
fathom) don't like it anyway.
How would I do this? I don't think I would - I think the way the C
standard defines the language is a reasonable compromise between
BNF-style syntax rules and descriptive constraints. But without putting
a good deal of effort into trying, and either succeeding or failing, I
currently think it should be possible to handle this with syntax rules.
However, if someone tells me they have made syntax rules for languages
and there is no way to cover this sort of thing with such rules, then I
will be easily persuaded.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-09 20:15 +0100 |
| Message-ID | <_67vD.27978$p%6.16371@fx26.am4> |
| In reply to | #136497 |
On 09/10/2018 19:43, David Brown wrote:
> On 09/10/18 18:25, Keith Thompson wrote:
>> Not really. How would you enforce the prohibition on
>> x = 42;
>> where x is defined as "const" or is an enumeration constant using just
>> syntax rules?
>>
>
> I am reasonably sure it would be possible - but it would involve a good
> deal more complex syntax grammar.
Much more complex. I think the Algol68 spec tried to do something along
these lines, with a result that is inaccessible with few people being
able to understand it.
You'd have to have something
> equivalent to "modifiable lvalues" as a type of term ("non-terminal" may
> be the right word in BNF parlance) that is distinct from
> "unary-expression" as defined in the C standards. Perhaps it would
> easier if you did away with "const" - some people (for reasons I can't
> fathom) don't like it anyway.
> How would I do this? I don't think I would - I think the way the C
> standard defines the language is a reasonable compromise between
> BNF-style syntax rules and descriptive constraints.
I really can't see the point. For example, take this simple piece of code:
A = B;
The syntax tells you this has a valid 'shape' for a statement. But
you're talking here about a syntax that would somehow require that A is
a modifiable lvalue.
But what about the fact that A has to have been defined, and be in a
visible scope?
Or what about the fact that A and B need to be of compatible types? For
example, this won't work when A and B are both arrays.
On the other hand, syntax /can/ be used to enforce some things that
would make coding safer and less error prone. For example, this could be
made illegal:
A == B;
So could this:
int const const const typedef T,U,V(int,int),*W;
So much low-hanging fruit, but you disregard all those possibilities by
choosing to keep all that complexity in the set of legal programs, and
suggest adding even more complexity in the grammar.
--
bart
[toc] | [prev] | [next] | [standalone]
Page 9 of 18 — ← Prev page 1 … 7 8 [9] 10 11 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web