Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97546 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-11-26 12:49 -0800 |
| Last post | 2016-12-01 12:33 +0800 |
| Articles | 20 on this page of 567 — 30 participants |
Back to article view | Back to comp.lang.c
absence of max fir <profesor.fir@gmail.com> - 2016-11-26 12:49 -0800
absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-26 15:34 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 00:21 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-27 04:25 -0800
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-11-27 13:54 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 13:54 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 07:33 -0800
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:06 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:47 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 15:35 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:48 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:53 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:14 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:36 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:03 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:23 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 21:05 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 16:53 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 08:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:37 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:26 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:42 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:16 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 09:31 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 10:38 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 10:59 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 12:09 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 13:05 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:50 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:52 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 05:44 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 15:12 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 06:54 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:37 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 03:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 13:28 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 05:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 18:57 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 11:33 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 20:09 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:55 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:06 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:18 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:28 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 10:49 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 11:40 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 12:17 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 15:18 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-29 18:30 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 18:49 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 14:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 10:56 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 11:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 20:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 20:31 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:45 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 12:54 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 16:21 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:47 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:30 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 14:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 22:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 22:33 +0000
Re: absence of max jameskuyper@verizon.net - 2016-11-29 14:52 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 15:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 23:51 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 02:08 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 18:10 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 21:30 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:47 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 14:59 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 15:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:12 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 01:11 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 18:01 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:19 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-29 13:26 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 17:09 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:01 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:29 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:02 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 01:21 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:53 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:11 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:12 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 11:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 09:46 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 17:04 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 07:21 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:50 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 00:19 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:43 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 01:51 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 22:26 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:25 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 09:07 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 14:22 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-30 09:03 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:38 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 15:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 00:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 17:22 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 01:40 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 18:03 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 17:25 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:29 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:55 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:05 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:20 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:41 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 13:48 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:23 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 09:39 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:35 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 14:51 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 15:05 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 20:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 01:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:57 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:38 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 13:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 00:06 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 20:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 02:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 21:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 01:56 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:25 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:33 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 15:20 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:40 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-02 21:57 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:46 -0500
Re: absence of max asetofsymbols@gmail.com - 2016-11-30 06:36 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 16:41 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-11-30 20:50 +1300
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:11 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 12:00 +0000
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 11:32 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 19:25 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 20:45 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-30 14:17 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:14 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 07:37 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 17:05 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 10:06 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-12-01 13:53 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-01 12:22 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:02 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 10:05 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 11:01 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 17:28 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:13 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 11:51 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 14:28 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 15:00 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:28 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:30 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:50 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 09:39 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 10:17 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-02 11:46 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 15:02 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 11:58 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 13:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:31 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 13:34 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:32 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 01:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:50 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:45 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 11:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 13:46 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:29 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 18:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:59 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:51 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:19 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-04 01:28 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-04 14:34 +1300
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 00:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 10:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 08:38 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 15:52 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:03 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 19:19 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 11:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 11:33 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-04 00:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:23 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 10:32 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 17:15 +0100
Re: absence of max jameskuyper@verizon.net - 2016-12-03 08:33 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-03 11:08 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 21:31 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-04 08:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 19:39 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 07:15 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 13:38 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-05 14:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:21 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:05 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 09:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:33 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 15:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:48 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 14:43 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:26 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 11:32 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:56 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 20:28 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:10 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:01 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 20:00 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:51 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:44 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:49 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-05 15:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:24 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:47 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:51 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:30 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 01:44 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:54 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:05 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 11:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:16 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:45 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:07 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:58 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 17:49 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:46 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:04 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 08:45 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:54 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:02 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:38 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:43 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:00 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:58 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:48 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-18 16:51 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:54 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-19 21:24 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:38 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 15:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 19:12 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 17:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 21:41 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-17 09:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:49 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-18 08:26 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-19 19:19 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:40 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 18:03 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:44 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:19 -0600
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:12 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:44 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 06:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:58 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:21 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:34 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 06:58 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:15 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 12:30 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:25 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 13:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 13:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:03 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:50 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:44 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:00 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:28 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:29 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 16:24 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 17:04 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:29 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:37 -0800
Re: absence of max me <crisdunbar@gmail.com> - 2016-12-07 14:25 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:19 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:36 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-08 16:22 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:52 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 08:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:08 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:50 -0800
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:14 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:17 +0100
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:21 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:24 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:06 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:15 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:05 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:22 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 15:12 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:57 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-12 00:13 -0600
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:48 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:11 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:48 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:39 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:01 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-17 11:27 -0800
People who confuse and jumble up the difference between past, present, and future (Was: absence of max) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 20:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:15 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:40 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:19 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:29 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 14:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:24 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:58 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:09 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-11 20:56 +1300
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:35 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 13:42 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:54 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:54 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:14 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-11 18:11 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:18 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:55 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:11 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:21 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:48 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:02 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:39 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:37 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:13 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 22:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:19 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 19:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:38 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 07:52 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:37 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-08 14:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-08 15:46 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:04 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-13 13:38 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 14:07 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 22:51 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-14 08:17 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-14 11:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-14 16:53 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 05:14 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 15:02 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-15 08:54 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 19:55 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-15 14:20 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 15:32 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 23:44 +0100
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 07:00 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:21 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-16 13:24 -0800
Re: absence of max "D. Aaron Sawyer" <aaron@110.net> - 2016-12-16 18:51 -0400
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-20 09:03 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:21 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-14 19:05 +0100
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-08 15:58 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 00:18 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-09 07:25 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 11:29 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:07 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 14:20 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:31 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:15 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 22:11 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 15:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:21 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:19 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:31 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:14 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:05 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:58 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:20 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:29 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:53 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:58 +0000
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-12 19:11 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-13 10:31 +0100
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:38 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 12:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:06 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:44 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:23 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:23 -0800
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:32 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:42 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:40 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:33 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 15:02 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 13:01 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:11 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:59 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 20:56 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:04 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-11 16:18 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:38 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:35 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:22 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:35 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:54 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:17 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:01 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 13:16 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:05 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:21 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:09 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-12 13:12 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:01 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:03 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 12:58 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:11 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:53 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:46 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:07 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:53 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:11 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:32 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:26 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 19:39 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-12 11:31 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 19:01 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:06 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:19 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:13 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-12 15:38 +0000
Re: absence of max jameskuyper@verizon.net - 2016-12-02 08:54 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 17:20 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:35 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 09:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-02 10:44 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 16:52 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:15 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:49 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:35 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-27 09:39 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:35 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:10 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 22:07 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:55 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:46 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 13:16 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 14:52 +0100
Re: absence of max jadill33@gmail.com - 2016-11-28 09:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:04 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 18:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:52 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:31 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:09 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 14:14 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:02 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:26 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:43 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:46 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:56 +0100
Re: absence of max jameskuyper@verizon.net - 2016-11-27 16:21 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 10:10 -0800
Re: absence of max Tim Prince <tprince@computer.org> - 2016-11-27 07:40 -0500
absence of max asetofsymbols@gmail.com - 2016-11-27 08:46 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:18 -0800
Re: absence of max asetofsymbols@gmail.com - 2016-11-27 09:22 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:27 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 17:33 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-27 17:51 +0000
Re: absence of max Ken Brody <kenbrody@spamcop.net> - 2016-11-30 13:15 -0500
Re: absence of max "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-01 12:33 +0800
Page 2 of 29 — ← Prev page 1 [2] 3 4 … 29 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 10:37 +0100 |
| Message-ID | <o1ji78$cl0$1@dont-email.me> |
| In reply to | #97645 |
On 28/11/16 17:07, Rick C. Hodgin wrote:
> On Monday, November 28, 2016 at 10:54:00 AM UTC-5, David Brown wrote:
>> On 28/11/16 16:13, Rick C. Hodgin wrote:
>>> On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
>>>> On 27/11/16 13:25, Rick C. Hodgin wrote:
>>>>> I wrote a reply last night, but I guess it was lost somehow. It basically said
>>>>> Python's a weakly-typed language, isn't it? If so it would have to have its
>>>>> own built-in min() and max() functions to be able to reliably compare
>>>>> disparate types. I see you also mention this as a need in C, but I would
>>>>> argue to a lesser degree because of casting. We can create a macro with
>>>>> a trinary operator and generate code for every case. The compiler may
>>>>> complain here or there so you apply the appropriate cast.
>>>>
>>>> Python is a strongly typed language, not a weakly typed language (such
>>>> as C).
>>>
>>> Are you saying "C is a weakly typed language" or "Python is a strongly
>>> typed language like C?"
>>
>> I don't think there are any clear and non-controversial definitions of
>> strong and weak typing. But I believe C is usually classified as
>> "weakly typed" because it is relatively easy to mess around with types
>> (some conversions are done implicitly, especially via void*, and enums
>> are particularly weak) and a great deal of data is simply "int".
>>
>> Python is classified as strongly typed because every object has a
>> specific type, and type conversions actually change the data (so if you
>> use a number as a string, a formatting function is called to generate a
>> new string from the number - the language does not merely try to
>> re-interpret the number as though it were a string).
>>
>>
>>>
>>>> But Python is a dynamically typed language, with duck-typing.
>>>
>>> How can a dynamically typed language be a strongly typed language?
>>> I was under the impression in Python you could code this:
>>>
>>> n = 5
>>> print n
>>> n = "Hello, world"
>>> print n
>>
>> Yes, you can do that - because Python is dynamically typed. But dynamic
>> typing does not mean weak typing. In the Python code above, "n" is just
>> a name - it is not an object. The objects are 5 and "Hello, world",
>> each of which has very clear and definitive types that do not change.
>> All that changes is the binding of the name "n" to those two objects.
>
> Visual FreePro does the same thing. I have a struct with a discriminating
> union which determines the actual type of the data within. It can be
> reassigned as needed, as in python (or originally as in other xbase
> languages as that's what it's emulating).
>
> The data changes internally, meaning it's weakly typed because the type
> goes back to the thing identified by its token name (in my definition).
>
>>> The token "n" can be used for multiple variable types. I tested this
>>> using the online test page:
>>>
>>> http://mathcs.holycross.edu/~kwalsh/python/
>>>
>>> I see on the Python wiki that it answers this question:
>>>
>>> https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
>>>
>>> I disagree with the way the term "strongly typed" is used there because
>>> I consider C to be a strongly typed language. You type "char c" and
>>> that's all C can ever be within that scope.
>>>
>>> That's a philosophical difference I suppose.
>>
>> C is statically typed, while Python is dynamically typed. Those terms
>> are /not/ synonymous with "strongly typed" and "weakly typed" - I think
>> you can have all combinations (though I can't think of any weakly typed
>> dynamically typed language off hand).
>
> I think they must be. If something is statically typed it cannot be
> altered. It remains that way forever, which means it is strongly typed.
No, "statically typed" means you give things specific known types at
compile-time. A statically typed language can also be strong, meaning
it is hard to change those types or view the data as a different type.
A statically typed language can also be weak, meaning there is little to
hinder you changing the type of an object (as distinct from /converting/
the object to a new object of a different type).
Consider these two functions in C (which is clearly a statically typed
language, although unions allow a certain degree of dynamic typing).
int floatToInt1(float f) {
return f;
}
int floatToInt2(float f) {
void * p = &f;
int * q = p;
return *q;
}
The first function is type-safe, and valid in a strongly-typed language
(or strongly-typed programming), as the floating point value f is
/converted/ to an integer. The second function demonstrates weak typing
- the bit representation of the floating point value is re-interpreted
as an integer with no regard for the actual types involved. It has
implementation-dependent behaviour, but is syntactically valid C that
will be accepted by compilers, usually without warning.
The second function is invalid as C++ code - you need to explicitly cast
the void* pointer to an int* pointer. C++ does not make it impossible
to break the type system, but it makes it a little harder than C, and
that is one of the several reasons why C++ is considered a stronger
typed language than C.
Note that although C allows weak typing like this, programs do not have
to take advantage of it - you can code in a manner that uses stronger
typing.
>
>> Once you have your "char c", it is not hard to make an "int *" pointer
>> to point to it and read the same data as a different type - that is what
>> makes it "weak".
>
> I disagree. "char c" has not changed. It will always still yield the
> char value at its location in memory. The new "int *" (be it a cast, or
> a variable that's set to the &c address) is a new and discrete thing with
> its own ability to act on the thing it's pointing to.
>
> In both cases, both are strongly typed.
See above, for what I hope is a clearer example.
>
>> It is very hard to do something similar in Python.
>>
>> Of course, the terms are not really black and white, and you can
>> reasonably argue that "C with warnings enabled" has stronger typing
>> because it is hard to "cheat" on your types while avoiding warnings.
>
> Even in the case of explicitly added casts, which are fundamental
> operations you've manually injected into an expression to receive a
> particular type, and emit another type, I don't see how it could be
> viewed as anything other than strongly typed.
>
> Everything in C is nailed down categorically and the correct function
> is called based on what is known at compile-time.
>
> In python (and Visual FreePro) it does a test on variable types to
> determine which branch to flow to in order to process a particular
> type.
>
It is this run-time test that is key to making Python a much stronger
typed language. No matter how you try to cheat the type system,
operations on objects check the actual type of the object. You cannot
tell Python "I know I said this object was a floating point variable,
but now I want you to treat it as an integer".
(For /really/ advanced usage, it is possible to force changes to Python
types by fiddling with metaclasses. There is always a way to cheat!)
>>>> This means that in effect, every function in Python is a bit like a
>>>> template in C++. And writing a new "max" function in Python is as
>>>> simple as:
>>>>
>>>> def my_max(a, b) :
>>>> if (a > b) return a
>>>> return b
>>>>
>>>> When the implementation is so simple, there is very little reason /not/
>>>> to put it into the standard library - just as C++ has std::max with a
>>>> very simple implementation as a template.
>>>
>>> Python is required, within its own internal processing engine, to compare
>>> disparate types, such as a floating point value to another integer value,
>>> and return correct results, without any custom/fancy casting or other
>>> things required in C.
>>>
>>> That's what I was referring to. Python needs this type of built-in
>>> ability because it's weakly typed. A and B come in and they can be
>>> anything. The nuances of the comparison logic has to be able to
>>> handle comparing type x to type y generically, and with correct
>>> results in each case.
>>
>> No, it is /strongly/ typed. When Python needs to convert an operand (or
>> both operands) in order to carry out an operation like "a > b", it uses
>> well-defined conversion functions.
>
> Of course. But, they are not known at compile-time.
Correct. Python is dynamically typed and strongly typed. Languages
(and to some extent programs written in the language) can be classified
in many ways, with attributes on different axes. Strong-weak typing is
one axis, static-dynamic is another. (And you can have many others axes
for language classification, of course.)
> They are known
> only at runtime with internal tests being made on each type to determine
> what internal logic path to flow to.
>
> The same input names "n" and "m" could flow through different paths
> based on their internal values at runtime. It's not known at compile-
> time, and has no ability to be known outside of a static program with
> no variables like:
>
> (pseudo code)
> function x() {
> if (current_millisecond % 7 == 0)
> return "Hello world";
> else
> return 5;
> }
>
Yes, but that is /dynamic/ typing.
If you write "y = x()", then "print y.len()", the validity of taking the
length of y depends on the actual type of y - that is /strong/ typing.
> Any python app calling a function like that (in its proper syntax form)
> will have variable types being returned, but stored in the same token
> name. When you later do a comparison to another, it will flow through
> to the proper handler based on the runtime peculiarities of the data,
> and not due to anything known at compile time.
What is returned is not a variable - you have no direct access to
variables in Python. (And in this case, there are no variables - both
the string and the number are constant objects.) The return is a
/reference/ that is set to point at either the constant number object 5,
or the constant string object "Hello world". At compile time, it is not
known what type of object will be referred to by the returned reference.
>
> At each use / reference, it must be manually examined and then branched
> to.
Yes, that is dynamic typing.
>
> In C, that's not the case. The entire program is completely known at
> compile time and there is no ability to change anything. You must use
> something like custom logic and variadic functions in order to do those
> variable things. But even then, in each case, every flow through every
> possible type is already known, with only manual tests on data, not
> variable types, determining where flow goes.
>
> I view that as very strongly typed.
I know you think that means strongly typed. You are wrong - it means
/statically/ typed. It is a very common mixup, and can be hard to get
your head around - I hope my posts here make things a little clearer for
you.
>
>> These exist for built-in types - if
>> you are using your own types, you need to define these functions or you
>> will get a run-time error. C is weakly typed, because it will happily
>> (well, maybe unhappily, with a warning) do what you ask here in many
>> cases, even if it makes no sense.
>>
>>>
>>> Visual FreePro has to do this as well and it was complex to write all
>>> of the code which does this as there are many possible comparisons.
>>>
>>>> C, on the other hand, has /no/ possible implementation of a max function
>>>> or macro that works on all numeric types until C11 _Generic - and even
>>>> then, the implementation is more than a little ugly.
>>>>
>>>>> Another thought this morning. Python moves by people needs. C
>>>>> moves by committee choices. If something is not deemed desirable
>>>>> by the committee, it will never officially be added. But, I think
>>>>> that era of fixedness in those maintaining the C Standard will have to
>>>>> change, lest it be ignored as people move on past it.
>>>>
>>>> C moves by people needs as well, just a lot more slowly - it needs a lot
>>>> of people, and a very clear need, to make changes happen. "max" is not
>>>> needed that much.
>>>
>>> Python is an open project. If I desire to have x, y, or z added I can
>>> do it, it goes into the main line, and is then available to all.
>>
>> No, you can't. Python is an open source project - you can download the
>> source, make all the changes you want, and use it yourself. You can
>> publish the modified version as you want. But it will only get back to
>> the mainline if it is approved by the project maintainers, which
>> involves going through a formal process of "Python Enhancement
>> Proposals" to give the main Python developers and the Python community a
>> chance to consider the change and its implications. The change must
>> meet the approval of Python's Benevolent Dictator For Life, Guido van
>> Rossum, before it has a chance to become part of the official mainline
>> Python.
>
> Roughly, how many changes have been allowed since python came about,
> compared to how many changes have been allowed to the C Standard?
Oh, lots - and between major versions there have always been seriously
incompatible changes. But these do not come about simple because
someone writes a bit of code and checks it in to the project's
repository. Changes pass through a serious formal process with a lot of
consideration - it is simply that this process is more continual than C
(no need to wait for a new version of the standard), more open than C
(discussions are public and everyone can be involved), and faster than C.
>
>> Still, you have a far better chance of getting a change into Python than
>> getting a change into C :-)
>
> My point exactly.
I just wanted to correct the impression you were giving of pure anarchy
in the development of the Python language.
>
>>> I
>>> can't do that with C. I can do that with GCC or CLANG or some instance
>>> of a C compiler, but not C, not to the standard.
>>>
>>> I would argue it doesn't move by people needs, but by committee needs.
>>> Otherwise a lot would've been introduced that, because it wasn't,
>>> spawned off many other languages.
>>>
>>> It's why I've more or less ditched C and am proceeding with CAlive. I
>>> will provide support through C99 eventually however. And other people
>>> are free to add additional newer support.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 08:26 -0800 |
| Message-ID | <7ddbb42d-0e6c-44b2-af4c-a78123c6924f@googlegroups.com> |
| In reply to | #97643 |
On Monday, November 28, 2016 at 9:54:00 AM UTC-6, David Brown wrote: > Once you have your "char c", it is not hard to make an "int *" pointer > to point to it and read the same data as a different type - that is what > makes it "weak". It is very hard to do something similar in Python. It's easy syntactically to write code whose only sensible meaning is that the bits at some address should be written as a particular type. It's also easy to write code whose only sensible meaning is that the bits at some address should be read as a particular type. In a truly-weakly-typed language, combining the two operations should be a simple way to take the bit pattern used for one type and reinterpret it as another. Some dialects of C are weakly-typed by that definition, but the Standard does not describe such semantics except to note that some implementations happen to offer them (but not defining a means by which code can test for such implementations).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 10:42 +0100 |
| Message-ID | <o1jif1$dev$1@dont-email.me> |
| In reply to | #97648 |
On 28/11/16 17:26, supercat@casperkitty.com wrote: > On Monday, November 28, 2016 at 9:54:00 AM UTC-6, David Brown wrote: >> Once you have your "char c", it is not hard to make an "int *" pointer >> to point to it and read the same data as a different type - that is what >> makes it "weak". It is very hard to do something similar in Python. > > It's easy syntactically to write code whose only sensible meaning is that > the bits at some address should be written as a particular type. It's also > easy to write code whose only sensible meaning is that the bits at some > address should be read as a particular type. > > In a truly-weakly-typed language, combining the two operations should be > a simple way to take the bit pattern used for one type and reinterpret it > as another. Some dialects of C are weakly-typed by that definition, but > the Standard does not describe such semantics except to note that some > implementations happen to offer them (but not defining a means by which > code can test for such implementations). > Certainly C is not as weak as it gets - assembly and Forth are examples of untyped languages. C is merely /weaker/ than Python, C++, and many other languages. When people classify languages in a black-and-white fashion (which I think is a very bad idea), C is usually called a "weakly typed, statically typed language", while C++ is "strongly typed, statically typed" and Python is "strongly typed, dynamically typed". But these should really be sliding scales. C++ is more strongly typed than C, but Python is more strongly typed than C++. And C++ has more dynamic typing than C but less dynamic than Python.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 08:16 -0800 |
| Message-ID | <436aadfe-20e5-4349-bdf4-9bac145b0d7e@googlegroups.com> |
| In reply to | #97639 |
On Monday, November 28, 2016 at 9:13:24 AM UTC-6, Rick C. Hodgin wrote:
> On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> > Python is a strongly typed language, not a weakly typed language (such
> > as C).
>
> Are you saying "C is a weakly typed language" or "Python is a strongly
> typed language like C?"
C has all the dangers associated with loosely-typed languages; some dialects
expose the programmer to the semantic power of loosely-typed languages, while
others only expose the dangers.
In Python, one can have an array which is capable of holding things of any
type, but *the system will always know what types of things it holds*. In
some dialects of C, heap storage is nothing more nor less than a bunch of
bits that can be interpreted as the programmer sees fit, but the
implementation will neither know nor care what types they represent. In
other dialects, however, an implementation might behave as though it attaches
type information to an arbitrary subset of information on the heap, and may
behave in arbitrary fashion if information is used in a fashion contrary to
its right type.
I would describe Python as being strongly typed since the implementation
always knows the type of every object. I would describe dialects of C which
allow storage to be freely reinterpreted as weakly-typed. I'm not sure
what adjective would be appropriate for the dialects which don't allow
programmers to exploit the semantics of loose typing but don't provide the
protections associated with strong typing.
> > But Python is a dynamically typed language, with duck-typing.
>
> How can a dynamically typed language be a strongly typed language?
> I was under the impression in Python you could code this:
>
> n = 5
> print n
> n = "Hello, world"
> print n
You can, but if you tried e.g.
n = 5
n = n-3;
print n
n = "Hello world"
n = n-3;
print n
you'd get a type mismatch error on the second subtract since it's not
possible to subtract a number from a string. An analogous situation in
C to your first example would be:
void *p = malloc(8);
*(uint32_t*)p = 5;
printf("%d", *(uint32_t**)p);
*(char const*)p = "Hello there!";
printf("%s", *(char const**)p);
and the second example:
void *p = malloc(4 + sizeof (char*));
*(uint32_t*)p = 5;
*(uint32_t*)p -= 3;
printf("%d", *(uint32_t*)p);
*(char const**)p = "Hello there!";
*(uint32_t*)p -= 3;
printf("%s", *(char const**)p);
The second code example in C would not likely yield a type mismatch error
at runtime. The malloc storage would be capable of holding either an integer
or a character pointer, but an implementation would not typically keep track
of which one it held.
> I disagree with the way the term "strongly typed" is used there because
> I consider C to be a strongly typed language. You type "char c" and
> that's all C can ever be within that scope.
Things that are statically typed in C are strongly typed. In Python,
things are strongly dynamically typed.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 09:31 -0800 |
| Message-ID | <e22bbfbe-249b-44e8-806d-f29802be04c6@googlegroups.com> |
| In reply to | #97646 |
On Monday, November 28, 2016 at 11:17:00 AM UTC-5, supe...@casperkitty.com wrote:
> On Monday, November 28, 2016 at 9:13:24 AM UTC-6, Rick C. Hodgin wrote:
> > On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> > > Python is a strongly typed language, not a weakly typed language (such
> > > as C).
> >
> > Are you saying "C is a weakly typed language" or "Python is a strongly
> > typed language like C?"
>
> C has all the dangers associated with loosely-typed languages; some dialects
> expose the programmer to the semantic power of loosely-typed languages, while
> others only expose the dangers.
>
> In Python, one can have an array which is capable of holding things of any
> type, but *the system will always know what types of things it holds*. In
> some dialects of C, heap storage is nothing more nor less than a bunch of
> bits that can be interpreted as the programmer sees fit, but the
> implementation will neither know nor care what types they represent. In
> other dialects, however, an implementation might behave as though it attaches
> type information to an arbitrary subset of information on the heap, and may
> behave in arbitrary fashion if information is used in a fashion contrary to
> its right type.
>
> I would describe Python as being strongly typed since the implementation
> always knows the type of every object. I would describe dialects of C which
> allow storage to be freely reinterpreted as weakly-typed. I'm not sure
> what adjective would be appropriate for the dialects which don't allow
> programmers to exploit the semantics of loose typing but don't provide the
> protections associated with strong typing.
>
> > > But Python is a dynamically typed language, with duck-typing.
> >
> > How can a dynamically typed language be a strongly typed language?
> > I was under the impression in Python you could code this:
> >
> > n = 5
> > print n
> > n = "Hello, world"
> > print n
>
> You can, but if you tried e.g.
>
> n = 5
> n = n-3;
> print n
> n = "Hello world"
> n = n-3;
> print n
>
> you'd get a type mismatch error on the second subtract since it's not
> possible to subtract a number from a string. An analogous situation in
> C to your first example would be:
>
> void *p = malloc(8);
> *(uint32_t*)p = 5;
> printf("%d", *(uint32_t**)p);
> *(char const*)p = "Hello there!";
> printf("%s", *(char const**)p);
>
> and the second example:
>
> void *p = malloc(4 + sizeof (char*));
> *(uint32_t*)p = 5;
> *(uint32_t*)p -= 3;
> printf("%d", *(uint32_t*)p);
> *(char const**)p = "Hello there!";
> *(uint32_t*)p -= 3;
> printf("%s", *(char const**)p);
>
> The second code example in C would not likely yield a type mismatch error
> at runtime. The malloc storage would be capable of holding either an integer
> or a character pointer, but an implementation would not typically keep track
> of which one it held.
If this is your position regarding C being a weakly typed language,
then I disagree with you completely.
In each of those cases, the void* p value is being used in a way
which requires the explicit use of a cast. Each explicit use of
a cast creates a new strongly typed form which is expressly known
to the compiler, and is used only as the compiler is able to use
it. The fact that the cast operation is taking input and putting
it through to something improperly is not a feature of language
typing. It's a feature of the misuse of language typing.
> > I disagree with the way the term "strongly typed" is used there because
> > I consider C to be a strongly typed language. You type "char c" and
> > that's all C can ever be within that scope.
>
> Things that are statically typed in C are strongly typed. In Python,
> things are strongly dynamically typed.
All things in C are statically typed. There are no exceptions. Even
in the case of unions, every reference to each member is totally and
completely known top-to-bottom as to what it is. Whether or not it's
been misapplied through the nuances of the application is another
matter.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 10:38 -0800 |
| Message-ID | <0101fa6e-5a5a-4600-b28f-e956a8cc79fb@googlegroups.com> |
| In reply to | #97655 |
On Monday, November 28, 2016 at 11:31:40 AM UTC-6, Rick C. Hodgin wrote: > All things in C are statically typed. There are no exceptions. Even > in the case of unions, every reference to each member is totally and > completely known top-to-bottom as to what it is. Whether or not it's > been misapplied through the nuances of the application is another > matter. That depends upon whether the contents of heap storage are considered a "thing", and whether one expects type violations to have some effect other than Undefined Behavior. If one allows a language to be called "strongly typed" without requiring any deterministic enforcement of typing rules, then heap storage would qualify as "strongly typed" under such a definition. Otherwise, heap storage isn't strongly typed; whether it would qualify as "weakly-typed" would depend upon the implementation.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 10:59 -0800 |
| Message-ID | <d99b8857-238e-44d3-b7a0-62f249efc364@googlegroups.com> |
| In reply to | #97675 |
On Monday, November 28, 2016 at 1:38:18 PM UTC-5, supe...@casperkitty.com wrote: > On Monday, November 28, 2016 at 11:31:40 AM UTC-6, Rick C. Hodgin wrote: > > All things in C are statically typed. There are no exceptions. Even > > in the case of unions, every reference to each member is totally and > > completely known top-to-bottom as to what it is. Whether or not it's > > been misapplied through the nuances of the application is another > > matter. > > That depends upon whether the contents of heap storage are considered a > "thing", and whether one expects type violations to have some effect other > than Undefined Behavior. If one allows a language to be called "strongly > typed" without requiring any deterministic enforcement of typing rules, > then heap storage would qualify as "strongly typed" under such a definition. > Otherwise, heap storage isn't strongly typed; whether it would qualify as > "weakly-typed" would depend upon the implementation. I don't consider the heap to be a typeable quantity. I consider access to the heap to be done only through strongly typed variables. I consider the heap to be a load/store mechanism which populates into/out of typed things by the application's protocol (bitmaps accessed as bitmaps, rtf files as rich text, etc.). Same with remote data loaded into the heap (disk, network). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 12:09 -0800 |
| Message-ID | <77816453-bfb0-4aa9-9451-5439dec4c810@googlegroups.com> |
| In reply to | #97677 |
On Monday, November 28, 2016 at 12:59:31 PM UTC-6, Rick C. Hodgin wrote:
> I don't consider the heap to be a typeable quantity. I consider access
> to the heap to be done only through strongly typed variables. I consider
> the heap to be a load/store mechanism which populates into/out of typed
> things by the application's protocol (bitmaps accessed as bitmaps, rtf
> files as rich text, etc.).
Until C99, I don't think most programmers considered the bytes in there as
having types only in an ephemeral sense; if `*p` happens to identify address
0x12345678, then "*(uint32_t*)p = 0xCAFEBABE;" would on most machines set four
bytes starting at address 0x12345678 to [0xCA,0xFE,0xBA,0xBE] or else
[0xBE,0xBA,0xFE,0xCA], and once that was done the system would cease knowing
or caring about any relationship between those bytes and the type "uint32_t".
C99 authorizes the compiler to treat the heap as strongly-typed storage at
its leisure, but without providing the programmer with anything like the
safety net that is promised in strongly-typed languages. Modern compilers
can make things more dangerous than they would be in even a weakly-typed
system, since in a weakly-typed system storage which has been formerly used
as an unknown type may be treated as holding an arbitrary unknown set of bit
values. If code does something like:
unsigned index = itemLookup[itemValue];
if ((index < numItems) && (itemValues[index] == itemValue))
...handle found item
else
...item not in collection
the values of bits in itemLookup[] will only matter for items which are
in the collection. If an item is not in the collection, then
itemLookup[itemValue] will either yield a value which is too big to
identify a valid item within itemValues, or else it will identify an item
that doesn't match the one of interest. Since the value of the bits in
itemLookup[value] won't matter, there should be no need to clear out that
storage before use.
In C99, however, reading storage as the wrong type invokes UB even in cases
where code would work equally well with any bit pattern the storage in
question might hold. C99 will thus create new failure modes that would not
have existed if heap storage were weakly typed.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 12:46 -0800 |
| Message-ID | <0b3f2bbf-8da1-4b26-9bcd-ae0cbeb24463@googlegroups.com> |
| In reply to | #97680 |
On Monday, November 28, 2016 at 3:09:55 PM UTC-5, supe...@casperkitty.com wrote: > On Monday, November 28, 2016 at 12:59:31 PM UTC-6, Rick C. Hodgin wrote: > > I don't consider the heap to be a typeable quantity. I consider access > > to the heap to be done only through strongly typed variables. I consider > > the heap to be a load/store mechanism which populates into/out of typed > > things by the application's protocol (bitmaps accessed as bitmaps, rtf > > files as rich text, etc.). > > Until C99, I don't think most programmers considered the bytes in there as > having types only in an ephemeral sense; if `*p` happens to identify address > 0x12345678, then "*(uint32_t*)p = 0xCAFEBABE;" would on most machines set four > bytes starting at address 0x12345678 to [0xCA,0xFE,0xBA,0xBE] or else > [0xBE,0xBA,0xFE,0xCA], and once that was done the system would cease knowing > or caring about any relationship between those bytes and the type "uint32_t". > > C99 authorizes the compiler to treat the heap as strongly-typed storage at > its leisure, but without providing the programmer with anything like the > safety net that is promised in strongly-typed languages. Modern compilers > can make things more dangerous than they would be in even a weakly-typed > system, since in a weakly-typed system storage which has been formerly used > as an unknown type may be treated as holding an arbitrary unknown set of bit > values. If code does something like: > > unsigned index = itemLookup[itemValue]; > if ((index < numItems) && (itemValues[index] == itemValue)) > ...handle found item > else > ...item not in collection > > the values of bits in itemLookup[] will only matter for items which are > in the collection. If an item is not in the collection, then > itemLookup[itemValue] will either yield a value which is too big to > identify a valid item within itemValues, or else it will identify an item > that doesn't match the one of interest. Since the value of the bits in > itemLookup[value] won't matter, there should be no need to clear out that > storage before use. > > In C99, however, reading storage as the wrong type invokes UB even in cases > where code would work equally well with any bit pattern the storage in > question might hold. C99 will thus create new failure modes that would not > have existed if heap storage were weakly typed. Maybe the issue is I don't understand the definitions of strongly and weakly typed. :-) I view strongly typed as anything that can only be one thing, only used as one thing, and that's its type. I view weakly typed as anything that can be more than one thing, can be used as one thing now, another thing later, and its type is instance-by- instance determined, rather than being known at compile time. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 13:05 -0800 |
| Message-ID | <89fb0938-1110-43b6-84d6-9f7c02893a57@googlegroups.com> |
| In reply to | #97682 |
On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: > I view strongly typed as anything that can only be one thing, only used > as one thing, and that's its type. > > I view weakly typed as anything that can be more than one thing, can be > used as one thing now, another thing later, and its type is instance-by- > instance determined, rather than being known at compile time. Python is strongly dynamically typed. Static typing would imply that the compiler would know about the types of things. Strong typing implies that *something* knows about the types of things and will enforce proper usage. In C, directly-accessed objects are strongly statically typed; storage which is accessed only via pointers are handled in whatever manner the implementation feels like.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 13:50 -0800 |
| Message-ID | <af0cffe3-7c5a-4220-a51b-3e90e746a3de@googlegroups.com> |
| In reply to | #97685 |
On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: > On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: > > I view strongly typed as anything that can only be one thing, only used > > as one thing, and that's its type. > > > > I view weakly typed as anything that can be more than one thing, can be > > used as one thing now, another thing later, and its type is instance-by- > > instance determined, rather than being known at compile time. > > Python is strongly dynamically typed. Static typing would imply that the > compiler would know about the types of things. Strong typing implies that > *something* knows about the types of things and will enforce proper usage. > In C, directly-accessed objects are strongly statically typed; storage > which is accessed only via pointers are handled in whatever manner the > implementation feels like. I can accept that. My use of the term strong and weak referred more to the static condition. I still don't see how something can be weakly typed under that definition. I saw a reference to the possibility of altering the internal type through an operation, such as possibly multiplying an integer by a floating point and changing the resulting type from integer to floating point? Would that be weakly typed? I would argue it's dynamically typed. And I would then argue that there is no dynamic and static typing, but only strong and weak typing. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 10:52 +0100 |
| Message-ID | <o1jj30$fad$1@dont-email.me> |
| In reply to | #97689 |
On 28/11/16 22:50, Rick C. Hodgin wrote: > On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: >> On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: >>> I view strongly typed as anything that can only be one thing, only used >>> as one thing, and that's its type. >>> >>> I view weakly typed as anything that can be more than one thing, can be >>> used as one thing now, another thing later, and its type is instance-by- >>> instance determined, rather than being known at compile time. >> >> Python is strongly dynamically typed. Static typing would imply that the >> compiler would know about the types of things. Strong typing implies that >> *something* knows about the types of things and will enforce proper usage. >> In C, directly-accessed objects are strongly statically typed; storage >> which is accessed only via pointers are handled in whatever manner the >> implementation feels like. > > I can accept that. My use of the term strong and weak referred more to > the static condition. And I hope now you see that this usage is incorrect. Static versus dynamic typing is an important classification for languages - arguably more important than strong or weak typing. But it is a different concept. These terms are not merely words we happen to use in one thread of a newsgroup - these are commonly used terms in discussing programming language characteristics (even though there is plenty of disagreement about exact definitions). > > I still don't see how something can be weakly typed under that definition. > I saw a reference to the possibility of altering the internal type through > an operation, such as possibly multiplying an integer by a floating point > and changing the resulting type from integer to floating point? Would > that be weakly typed? I would argue it's dynamically typed. And I > would then argue that there is no dynamic and static typing, but only > strong and weak typing. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-29 05:44 -0800 |
| Message-ID | <a12acebd-b63b-4b0f-9be4-2877832e0a5a@googlegroups.com> |
| In reply to | #97715 |
On Tuesday, November 29, 2016 at 4:52:51 AM UTC-5, David Brown wrote: > On 28/11/16 22:50, Rick C. Hodgin wrote: > > On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: > >> On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: > >>> I view strongly typed as anything that can only be one thing, only used > >>> as one thing, and that's its type. > >>> > >>> I view weakly typed as anything that can be more than one thing, can be > >>> used as one thing now, another thing later, and its type is instance-by- > >>> instance determined, rather than being known at compile time. > >> > >> Python is strongly dynamically typed. Static typing would imply that the > >> compiler would know about the types of things. Strong typing implies that > >> *something* knows about the types of things and will enforce proper usage. > >> In C, directly-accessed objects are strongly statically typed; storage > >> which is accessed only via pointers are handled in whatever manner the > >> implementation feels like. > > > > I can accept that. My use of the term strong and weak referred more to > > the static condition. > > And I hope now you see that this usage is incorrect. Static versus > dynamic typing is an important classification for languages - arguably > more important than strong or weak typing. But it is a different concept. I disagree with the definition, but I do see what everybody in this thread has been explaining. > These terms are not merely words we happen to use in one thread of a > newsgroup - these are commonly used terms in discussing programming > language characteristics (even though there is plenty of disagreement > about exact definitions). Yep. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 15:12 +0100 |
| Message-ID | <o1k2ah$4vv$1@dont-email.me> |
| In reply to | #97728 |
On 29/11/16 14:44, Rick C. Hodgin wrote: > On Tuesday, November 29, 2016 at 4:52:51 AM UTC-5, David Brown wrote: >> On 28/11/16 22:50, Rick C. Hodgin wrote: >>> On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: >>>> On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: >>>>> I view strongly typed as anything that can only be one thing, only used >>>>> as one thing, and that's its type. >>>>> >>>>> I view weakly typed as anything that can be more than one thing, can be >>>>> used as one thing now, another thing later, and its type is instance-by- >>>>> instance determined, rather than being known at compile time. >>>> >>>> Python is strongly dynamically typed. Static typing would imply that the >>>> compiler would know about the types of things. Strong typing implies that >>>> *something* knows about the types of things and will enforce proper usage. >>>> In C, directly-accessed objects are strongly statically typed; storage >>>> which is accessed only via pointers are handled in whatever manner the >>>> implementation feels like. >>> >>> I can accept that. My use of the term strong and weak referred more to >>> the static condition. >> >> And I hope now you see that this usage is incorrect. Static versus >> dynamic typing is an important classification for languages - arguably >> more important than strong or weak typing. But it is a different concept. > > I disagree with the definition, but I do see what everybody in this > thread has been explaining. > I can quite understand why you might feel that static typing is in a sense "better", "more solid", or "stronger" than dynamic typing (though in truth, each has its pros and cons - and languages are rarely entirely static, or entirely dynamic in their typing). But the term "strong typing" refers to how much you can mess around with the language's type system. It's just the way it is - consistency of terminology is often more important than the particular choice of words. It is also just an unfortunate mix of time zones that meant you had made quite a few posts before you understood that it was your terminology that was incorrect, rather than your understanding of C. >> These terms are not merely words we happen to use in one thread of a >> newsgroup - these are commonly used terms in discussing programming >> language characteristics (even though there is plenty of disagreement >> about exact definitions). > > Yep. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-29 06:54 -0800 |
| Message-ID | <ef094713-9583-4c17-9ade-00a5cd06e883@googlegroups.com> |
| In reply to | #97729 |
On Tuesday, November 29, 2016 at 9:13:01 AM UTC-5, David Brown wrote: > On 29/11/16 14:44, Rick C. Hodgin wrote: > > On Tuesday, November 29, 2016 at 4:52:51 AM UTC-5, David Brown wrote: > >> On 28/11/16 22:50, Rick C. Hodgin wrote: > >>> On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: > >>>> On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: > >>>>> I view strongly typed as anything that can only be one thing, only used > >>>>> as one thing, and that's its type. > >>>>> > >>>>> I view weakly typed as anything that can be more than one thing, can be > >>>>> used as one thing now, another thing later, and its type is instance-by- > >>>>> instance determined, rather than being known at compile time. > >>>> > >>>> Python is strongly dynamically typed. Static typing would imply that the > >>>> compiler would know about the types of things. Strong typing implies that > >>>> *something* knows about the types of things and will enforce proper usage. > >>>> In C, directly-accessed objects are strongly statically typed; storage > >>>> which is accessed only via pointers are handled in whatever manner the > >>>> implementation feels like. > >>> > >>> I can accept that. My use of the term strong and weak referred more to > >>> the static condition. > >> > >> And I hope now you see that this usage is incorrect. Static versus > >> dynamic typing is an important classification for languages - arguably > >> more important than strong or weak typing. But it is a different concept. > > > > I disagree with the definition, but I do see what everybody in this > > thread has been explaining. > > > > I can quite understand why you might feel that static typing is in a > sense "better", "more solid", or "stronger" than dynamic typing (though > in truth, each has its pros and cons - and languages are rarely entirely > static, or entirely dynamic in their typing). But the term "strong > typing" refers to how much you can mess around with the language's type > system. It's just the way it is - consistency of terminology is often > more important than the particular choice of words. I've written a few lengthy responses to this thread and then deleted them. It's not a point I care to argue, though I have specific reasons why I disagree with the view that data is the determination as to how/ when a type access is violated. I plan to create my own ecosystem with CAlive so it won't really be an issue in maintaining legacy terminology. My goals are to take people away from traditional programming regimes, and allow them to more or less ditch the entire ecosystem they grew up in, moving instead to a new platform which is founded upon Jesus Christ, and upon His teachings in how to use the skills He first gave a person to give back to Him and the other people of the Earth. It's a literal planned exodus, out from the old way of slavery and bondage to a system which rejects God, and into the new way of freedom in God, resulting in great benefits for those who will receive and embrace it. That's the plan, and the hope. An entire ecosystem from hardware through user apps, one founded completely in Jesus Christ, in His teachings, in the application of His gifts given back expressly for Him and other people (and not for money or power or control or dominance as by patents or copyrights), but as part of the community He has built and is building through those who will receive Him and work for Him in this world. My area of doing this is software and hardware. Other people have special skills in other areas. Together, we will change the world, because the One we pursue has that authority, power, and ability. > It is also just an unfortunate mix of time zones that meant you had made > quite a few posts before you understood that it was your terminology > that was incorrect, rather than your understanding of C. > > >> These terms are not merely words we happen to use in one thread of a > >> newsgroup - these are commonly used terms in discussing programming > >> language characteristics (even though there is plenty of disagreement > >> about exact definitions). > > > > Yep. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-30 10:37 +0100 |
| Message-ID | <o1m6i5$qg6$1@dont-email.me> |
| In reply to | #97731 |
On 29/11/16 15:54, Rick C. Hodgin wrote: > On Tuesday, November 29, 2016 at 9:13:01 AM UTC-5, David Brown wrote: >> On 29/11/16 14:44, Rick C. Hodgin wrote: >>> On Tuesday, November 29, 2016 at 4:52:51 AM UTC-5, David Brown wrote: >>>> On 28/11/16 22:50, Rick C. Hodgin wrote: >>>>> On Monday, November 28, 2016 at 4:05:27 PM UTC-5, supe...@casperkitty.com wrote: >>>>>> On Monday, November 28, 2016 at 2:46:29 PM UTC-6, Rick C. Hodgin wrote: >>>>>>> I view strongly typed as anything that can only be one thing, only used >>>>>>> as one thing, and that's its type. >>>>>>> >>>>>>> I view weakly typed as anything that can be more than one thing, can be >>>>>>> used as one thing now, another thing later, and its type is instance-by- >>>>>>> instance determined, rather than being known at compile time. >>>>>> >>>>>> Python is strongly dynamically typed. Static typing would imply that the >>>>>> compiler would know about the types of things. Strong typing implies that >>>>>> *something* knows about the types of things and will enforce proper usage. >>>>>> In C, directly-accessed objects are strongly statically typed; storage >>>>>> which is accessed only via pointers are handled in whatever manner the >>>>>> implementation feels like. >>>>> >>>>> I can accept that. My use of the term strong and weak referred more to >>>>> the static condition. >>>> >>>> And I hope now you see that this usage is incorrect. Static versus >>>> dynamic typing is an important classification for languages - arguably >>>> more important than strong or weak typing. But it is a different concept. >>> >>> I disagree with the definition, but I do see what everybody in this >>> thread has been explaining. >>> >> >> I can quite understand why you might feel that static typing is in a >> sense "better", "more solid", or "stronger" than dynamic typing (though >> in truth, each has its pros and cons - and languages are rarely entirely >> static, or entirely dynamic in their typing). But the term "strong >> typing" refers to how much you can mess around with the language's type >> system. It's just the way it is - consistency of terminology is often >> more important than the particular choice of words. > > I've written a few lengthy responses to this thread and then deleted > them. It's not a point I care to argue, though I have specific reasons > why I disagree with the view that data is the determination as to how/ > when a type access is violated. > > I plan to create my own ecosystem with CAlive so it won't really be an > issue in maintaining legacy terminology. You really should try to keep the same terminology as everyone else. That does not mean you need to keep the same sort of type system in your own languages as you find in others. If you want to implement duck-typing on CAlive rather than nominal or structural typing, that would be fine - but call it "duck-typing", not "goat-typing" or "sheep-typing". If you want to implement static typing, call it static typing. If you want strong typing, call it strong typing. It is entirely up to /you/ to decide how you want to implement the type system in your language, considering a variety of possible type system characteristics (not just strong/weak and static/dynamic, but also manifest/inferred, nominal/structural/duck-typing, and perhaps other characteristics). And these are not all-or-nothing choices - usually you can make them sliding scales. For example, you could make code normally strongly typed (no type-punning unions, no void*) but also allow modules or functions to be marked as "unsafe" and have access to type-safety breaking features to make it easier to implement things like memory allocators. But you should understand the terminology, and understand the terms - only then can you make the best choices from an informed position. It is fine to want to create something new and not limited by existing languages - but it is still worth learning from other people's work and experience! And if you start using your own terms, different from everyone else's, then you will just confuse people (not to mention confusing yourself).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-30 03:07 -0800 |
| Message-ID | <66ac3f87-f698-47d9-8f5f-a657ab4b93bf@googlegroups.com> |
| In reply to | #97769 |
David Brown wrote: > [snip] Thank you for offering your advice, David. I will consider it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-30 13:28 +0100 |
| Message-ID | <o1mgj7$qch$1@dont-email.me> |
| In reply to | #97771 |
On 30/11/16 12:07, Rick C. Hodgin wrote: > David Brown wrote: >> [snip] > > Thank you for offering your advice, David. I will consider it. > Just a small thing - I have not made any "offering". I posted some /advice/, not an "offering of advice". It was not an "offering" or a "sacrifice" to you or anyone else - it was advice that I thought might benefit you and perhaps others who read it. Please do not make it look like I am "donating" something to you, or supporting your plans, ideals or visions. I am merely giving help where I can to people in this newsgroup. If you want to know more about typing or type systems, then there are plenty of people in Usenet who can help. There are definitely people in c.l.c. who know a good deal more than me about the subject. But you will probably find it makes more sense to discuss it in a group such as comp.programming - in c.l.c., it is only really on-topic when we are discussing the type system in C or comparisons with other languages. If you want to start a thread in comp.programming on the subject, I will probably join in. That's an /offer/ of advice, but not an /offering/ of advice :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-30 05:12 -0800 |
| Message-ID | <58dd318d-4605-4ced-b0f8-ebb4fa892da4@googlegroups.com> |
| In reply to | #97775 |
On Wednesday, November 30, 2016 at 7:28:44 AM UTC-5, David Brown wrote: > [snip] Thank you for correcting my mistake, David. You are always seeking to help others do better and achieve more. Such efforts are appreciated. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-28 18:57 +0000 |
| Message-ID | <o1hujs$md0$1@dont-email.me> |
| In reply to | #97655 |
On 28/11/2016 17:31, Rick C. Hodgin wrote: > On Monday, November 28, 2016 at 11:17:00 AM UTC-5, supe...@casperkitty.com wrote: >> The second code example in C would not likely yield a type mismatch error >> at runtime. The malloc storage would be capable of holding either an integer >> or a character pointer, but an implementation would not typically keep track >> of which one it held. > > If this is your position regarding C being a weakly typed language, > then I disagree with you completely. C is strongly typed? Even without explicit casts, C allows these expressions, which would raise eyebrows if you are not familiar with the language: (s,t are char[]s containing a string; p is a pointer to one object; a,b are arrays; f is a function; i,j are signed integers) s+5; // add number to string; like my first example s-t; // subtract strings p[i]; // index a pointer *a; // dereference an array s[1]/2; // s[1] is a char; halve a 'char' (*f)(); // dereference a function i[a]; // index i with an array? a+i; // add number to array a-b; // subtract arrays a==0; // compare array with zero (&i)[j]; // index i like an array With casts, type-punning and unions, you can completely bypass the type-system and with very little effort. I can't show the equivalent of the above in Python, as it lacks the ability to do the pointer examples. However my own dynamic language does have them, and all the above expressions are errors**. So, which language is the more strongly, or strictly, typed: the one that allows pretty much anything, whether it makes sense /in the context of the program/ or not, or the one that raises objections? > All things in C are statically typed. There are no exceptions. Even > in the case of unions, every reference to each member is totally and > completely known top-to-bottom as to what it is. Whether or not it's > been misapplied through the nuances of the application is another > matter. That's not a very compelling argument. Is a processor instruction set strictly typed or not? Since you will always be working with machine words containing bit patterns of so many bits. (**Except for the equivalent of (*f)(); now I'll have to find out why!) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 29 — ← Prev page 1 [2] 3 4 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web