Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28006 > unrolled thread
| Started by | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| First post | 2014-01-22 13:52 -0800 |
| Last post | 2014-01-26 01:59 +0100 |
| Articles | 20 on this page of 412 — 34 participants |
Back to article view | Back to comp.lang.forth
CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 13:52 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-22 21:57 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:10 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:11 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 00:14 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 14:28 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-23 20:22 +1100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 12:34 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-25 22:44 +1100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-25 08:49 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 19:40 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 23:01 +1100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 03:43 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:10 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 10:31 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 11:35 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 13:27 +0000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 15:50 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:51 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:00 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:08 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:26 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:23 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:41 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 00:49 +1100
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 03:01 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 08:21 -0600
Re: CASE mis-understanding? BF <foxaudioresearch@gmail.com> - 2014-01-23 06:54 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-01-23 16:00 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:21 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:33 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:33 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:14 +0000
Re: CASE mis-understanding? Ron Aaron <rambamist@gmail.com> - 2014-01-24 10:49 +0200
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 03:26 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:25 -0500
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 22:09 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 22:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 03:22 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 06:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 16:03 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 10:14 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:42 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 10:42 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:01 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 12:16 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 07:16 -0600
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:43 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-24 10:57 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 03:58 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:24 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-27 19:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-28 03:34 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:50 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:15 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-24 21:00 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 20:47 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:36 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-24 00:44 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:20 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:02 +0000
Re: CASE mis-understanding? Elizabeth D Rather <erather@forth.com> - 2014-01-23 09:05 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 00:43 +1100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-26 18:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-26 11:27 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-26 22:09 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-26 15:35 -0600
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 01:57 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-28 13:46 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-28 12:12 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 17:19 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:40 +1100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-31 06:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-31 12:13 -0600
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:36 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 00:06 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-31 15:34 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 16:18 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-01 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-02 13:10 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-02 16:06 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-02 10:43 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-02 18:39 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:18 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:49 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:35 +0000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-03 09:56 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-03 02:50 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-03 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 14:31 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:17 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-04 12:23 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:26 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-04 08:05 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 19:07 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:59 +0000
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:34 +0100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:38 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-30 15:51 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 15:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-09 10:56 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 15:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-10 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:22 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-11 05:23 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-12 10:54 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-10 18:12 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 05:13 -0600
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 15:44 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 10:40 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-10 17:47 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 16:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 11:09 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 17:20 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 12:14 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-10 22:38 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 03:46 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:30 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:24 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 15:02 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 11:23 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:54 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:41 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 14:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 08:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 15:29 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 12:07 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 16:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:22 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:28 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-17 14:05 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 09:49 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:06 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 12:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 22:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:36 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 09:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 05:01 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:19 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 08:28 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 17:14 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 11:46 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:20 -0500
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-19 17:10 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-19 23:17 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-20 09:55 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:15 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:08 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 14:45 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:29 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:29 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:33 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:13 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 17:30 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 14:38 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-26 20:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 04:54 -0600
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 12:56 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 06:30 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 05:29 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 15:48 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:13 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-28 11:21 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 16:20 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 01:51 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 23:36 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 12:45 +0000
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-01 13:59 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 13:03 +0000
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-03-01 07:53 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:12 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:46 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:56 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 10:08 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 11:01 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:12 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 19:53 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 07:48 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 16:05 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:27 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:45 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 20:51 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 08:46 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-03-01 16:53 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-01 15:06 -1000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:50 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-03 17:18 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-04 03:20 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-04 19:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-05 03:51 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 10:11 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-05 14:09 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 15:43 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 22:16 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-02 04:56 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-02 14:07 +0000
Re: CASE mis-understanding? Mark Wills <markwills1970@gmail.com> - 2014-03-03 00:59 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-02 08:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 03:03 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:09 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:26 -0600
WITHIN (was: CASE mis-understanding?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:51 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-07 12:13 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 05:07 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 15:43 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 08:23 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:37 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 10:18 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 10:48 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:02 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-09 01:24 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-09 18:16 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 21:46 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:28 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 19:36 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:25 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 23:52 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 10:15 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 08:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 09:36 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-03-02 20:16 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:18 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:26 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:37 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:31 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:18 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 11:17 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-03-09 20:49 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:22 -0500
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 15:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 18:32 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 03:39 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:19 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 13:03 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-24 01:25 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:36 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 02:04 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:15 +0100
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-22 21:09 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:55 -0800
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-23 00:47 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 01:45 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-20 17:07 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-20 16:03 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:11 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-21 03:26 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:49 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-22 13:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:13 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:45 -0500
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-21 20:18 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-22 15:24 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:37 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 03:20 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:15 -0400
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-12 00:10 -0700
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:28 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 08:56 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 01:27 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:33 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 08:11 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 21:44 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:48 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:23 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 16:05 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 18:15 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 18:45 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 19:18 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:40 +0000
Re: CASE mis-understanding? Tristan Plumb <st@trstn.net> - 2014-02-26 15:27 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:31 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 16:30 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 11:48 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-22 18:28 -0800
Re: CASE mis-understanding? Gary Bergstrom <forthprgrmr@gmail.com> - 2014-02-24 08:39 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-24 21:29 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:44 +0000
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:45 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:35 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 12:31 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:19 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:06 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 12:51 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:40 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 08:17 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:48 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 13:56 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:15 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:24 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-19 03:46 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:10 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 13:09 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 15:03 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 15:53 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 00:39 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-14 06:38 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 15:37 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:33 -0600
Re: CASE mis-understanding? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-11 10:50 +0100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:57 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-11 02:35 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:47 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 13:08 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:42 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 10:54 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 05:31 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 10:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:27 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:49 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:54 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:26 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:41 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-07 01:08 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:56 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-07 12:15 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:39 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-31 07:29 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-04 23:45 +1100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-31 16:31 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 12:35 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:32 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:31 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:40 -1000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 22:03 -0800
Re: CASE mis-understanding? julian.fondren@gmail.com - 2014-01-29 17:19 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-30 11:15 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 13:57 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:01 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:49 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 10:07 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 21:54 -0800
Re: CASE mis-understanding? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-01-29 00:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-29 03:37 -0600
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-30 21:51 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-31 18:44 -0500
Re: CASE mis-understanding? David Thompson <dave.thompson2@verizon.net> - 2014-02-09 00:34 -0500
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-09 22:14 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:25 +0000
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-01-31 17:44 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 16:03 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 01:55 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-01 11:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-01 08:11 -1000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-02 14:28 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:28 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:34 +1100
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-07 03:52 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:41 +1100
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-07 18:33 -0500
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-08 00:31 +0100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:21 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-08 15:03 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-08 19:58 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 08:33 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-09 19:50 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 08:42 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 16:32 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-14 02:36 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:04 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:40 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-14 04:37 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:42 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-15 16:52 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-16 07:46 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 08:11 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-16 16:15 -0800
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-17 09:03 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 22:12 -1000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-17 02:29 -0800
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 04:27 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:36 -1000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:22 -1000
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 12:06 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-17 20:18 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:48 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:10 -0400
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-14 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-06 17:03 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:39 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-07 20:12 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 21:33 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:38 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 16:17 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 08:54 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:25 -1000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 20:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 11:13 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:39 -0500
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:05 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-25 11:46 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-25 16:15 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:59 +0100
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-24 16:05 +0000 |
| Message-ID | <2014Feb24.170538@mips.complang.tuwien.ac.at> |
| In reply to | #28718 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andrew Haley wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> You want a language similar to C but with most undefined behaviour
>> replaced by either well-defined or system-defined behaviour.
>
>Yes, please! Well, I actually don't want a language similar to C,
Maybe PAF (portable assembly Forth) fits the bill?
> but if it
>must be similar to C for popularity reasons, that's the way to go.
C is more than its standardized subset; it may not be standardized,
but that does not mean that it is just "similar to C"; it is C.
Terminology aside, C has a huge established code base (whereas the
standardized subset of C probably consists of nothing but a few
example programs), and the infrastructural significance of C means
that it is not very practical to avoid it.
E.g., if we implement PAF or Gforth as a native-code compiler written
in itself, we still need to interface to the OS and the interfaces are
typically defined in C.
We also need some way to bootstrap our code; generating an executable
is platform-specific and changes over time. Several Forth systems
have a small C program that loads the Forth system as an image, and
executes it; that leaves the job of dealing with executable formats
and such to the C compiler, but it fails to get rid of the adversarial
component in the system.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Tristan Plumb <firth@trstn.net> |
|---|---|
| Date | 2014-02-24 18:15 +0000 |
| Message-ID | <slrnlgn32u.36d.st@tumtum.plumbweb.net> |
| In reply to | #28746 |
> E.g., if we implement PAF or Gforth as a native-code compiler written > in itself, we still need to interface to the OS and the interfaces are > typically defined in C. My second foray into forth involved bootstrapping a forth varient from assembly. It's now written in itself, and touches no C at all, just a bunch of inline assembly for the core words. All the kernel interfaces involve passing data and pointers to data in registers. Not even C-like. Maybe you're using different operating systems than me, or mean something different by operating system...? Tristan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-24 18:45 +0000 |
| Message-ID | <2014Feb24.194507@mips.complang.tuwien.ac.at> |
| In reply to | #28750 |
Tristan Plumb <firth@trstn.net> writes:
>> E.g., if we implement PAF or Gforth as a native-code compiler written
>> in itself, we still need to interface to the OS and the interfaces are
>> typically defined in C.
>
>My second foray into forth involved bootstrapping a forth varient from
>assembly. It's now written in itself, and touches no C at all, just a
>bunch of inline assembly for the core words. All the kernel interfaces
>involve passing data and pointers to data in registers. Not even C-like.
>
>Maybe you're using different operating systems than me, or mean something
>different by operating system...?
If you want to run on just one OS, that approach is ok. If you want
to run on many, it becomes quite messy, because the machine-level
interfaces are different, and even the functions are different
(something that's a system call on one OS may be a library call on
another). The only commonality they have is POSIX, which is defined
through C (and Windows does not even have that).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Tristan Plumb <firth@trstn.net> |
|---|---|
| Date | 2014-02-24 19:18 +0000 |
| Message-ID | <slrnlgn6o1.36d.st@tumtum.plumbweb.net> |
| In reply to | #28752 |
> If you want to run on just one OS, that approach is ok. If you want to > run on many, it becomes quite messy, because the machine-level > interfaces are different, and even the functions are different > (something that's a system call on one OS may be a library call on > another). I was targeting Plan 9 and Linux. > The only commonality they have is POSIX, which is defined through C > (and Windows does not even have that). So you're saving the work of implementing an abstraction from what all the different kernels provide by using POSIX (and then whatever Windows does) which is already implemented by C libraries. I can see the advantages to that for transitioning programmers, familiarity with the interfaces and so on. Tristan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-26 12:40 +0000 |
| Message-ID | <2014Feb26.134048@mips.complang.tuwien.ac.at> |
| In reply to | #28753 |
Tristan Plumb <firth@trstn.net> writes:
>So you're saving the work of implementing an abstraction from what all
>the different kernels provide by using POSIX (and then whatever Windows
>does)
Actually on Windows we are also using POSIX (through Cygwin).
> I can see the
>advantages to that for transitioning programmers
What do you mean by that?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Tristan Plumb <st@trstn.net> |
|---|---|
| Date | 2014-02-26 15:27 +0000 |
| Message-ID | <slrnlgs1u9.36d.st@tumtum.plumbweb.net> |
| In reply to | #28784 |
On 2014-02-26, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> I can see the advantages to that for transitioning programmers > > What do you mean by that? I mean people who are used to working with POSIX in the C world will already have the concepts down. The hesitence in that statement is that while some parts of POSIX are very good, there is significant foolishness too. (Sockets come to mind.) Tristan
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-03-04 01:31 +0100 |
| Message-ID | <lf36tp$lva$1@online.de> |
| In reply to | #28746 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Yes, please! Well, I actually don't want a language similar to C, > > Maybe PAF (portable assembly Forth) fits the bill? Well, if we do the compiler ourself, I'd rather go the full way, i.e. Gforth as a native compiler. The whole "trusted stuff" you need for secure communication like net2o involves the compiler, as well, and I'd rather trust a compiler with a few thousand lines of Forth code than GCC. >> but if it >>must be similar to C for popularity reasons, that's the way to go. > > C is more than its standardized subset; it may not be standardized, > but that does not mean that it is just "similar to C"; it is C. > > Terminology aside, C has a huge established code base (whereas the > standardized subset of C probably consists of nothing but a few > example programs), and the infrastructural significance of C means > that it is not very practical to avoid it. > > E.g., if we implement PAF or Gforth as a native-code compiler written > in itself, we still need to interface to the OS and the interfaces are > typically defined in C. Actally, you can use SWIG to extract the call requirements, and generate the ABI calls yourself. There's no need for a full-blown C compiler. > We also need some way to bootstrap our code; generating an executable > is platform-specific and changes over time. Several Forth systems > have a small C program that loads the Forth system as an image, and > executes it; that leaves the job of dealing with executable formats > and such to the C compiler, but it fails to get rid of the adversarial > component in the system. I've written this loader in assembler for Atari ST and DOS. The good thing about small loaders is that you can even get the binary right out of a Forth program (I did this on the Atari), because a small loader doesn't need many of the more complicated features, and if you have options, you can use the simplest binary format available (a.out is completely sufficient). It mmaps some memory, opens and reads a file, and performs the relocation if necessary. That's all. You can do that all by direct calls to e.g. the Linux kernel, and bypass all the libc stuff. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-03-04 16:30 +0000 |
| Message-ID | <2014Mar4.173035@mips.complang.tuwien.ac.at> |
| In reply to | #28891 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> E.g., if we implement PAF or Gforth as a native-code compiler written
>> in itself, we still need to interface to the OS and the interfaces are
>> typically defined in C.
>
>Actally, you can use SWIG to extract the call requirements, and generate the
>ABI calls yourself. There's no need for a full-blown C compiler.
The calling conventions are complicated enough by themselves. There
is even a paper out there that proposed a specification language for
calling conventions
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.8166>.
But ok, I guess the calling conventions will not blow up the
retargeting effort by more than a factor of 10 or so (and in cases
with only one calling convention per architecture, it's probably much
less).
>I've written this loader in assembler for Atari ST and DOS. The good thing
>about small loaders is that you can even get the binary right out of a Forth
>program (I did this on the Atari), because a small loader doesn't need many
>of the more complicated features, and if you have options, you can use the
>simplest binary format available (a.out is completely sufficient). It mmaps
>some memory, opens and reads a file, and performs the relocation if
>necessary. That's all. You can do that all by direct calls to e.g. the
>Linux kernel, and bypass all the libc stuff.
And do one such loader for each combination of architecture and OS.
But there is still a missing link in this concept: We have a loader
written in machine language that does not know anything about C, and a
way to call C functions, but we have no way to load and link the
libraries containing these functions. How do we do that?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-05 11:48 +0000 |
| Message-ID | <53170f2b$0$25268$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #28922 |
In article <2014Mar4.173035@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: <SNIP> > >And do one such loader for each combination of architecture and OS. > >But there is still a missing link in this concept: We have a loader >written in machine language that does not know anything about C, and a >way to call C functions, but we have no way to load and link the >libraries containing these functions. How do we do that? You touch upon an important point. If shared object libraries are fundamental to executable, their manipulation should be in the Linux kernel not in some external library. That is one thing Microsoft Windows does correct over Linux: LoadLibrary and GetProcAddress are in the system. The way Linux works now, C has an unfair advantage over other languages, a kind of vendor lock in as you may. > >- anton >-- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-02-22 18:28 -0800 |
| Message-ID | <ecf192da-dd07-4b60-ac80-2914ca0c3262@googlegroups.com> |
| In reply to | #28643 |
On Friday, February 21, 2014 3:34:43 AM UTC-7, Stephen Pelc wrote: > Large Forth programs tend to be well layered, e.g. by OOP > layers. Large programs tend to be old. It takes a lot of > time to write a million lines of code. Good large Forth > applications change the notation. The application > programmers use a language designed for their application > domain. Application programmers then write very simple code > using this language. It's the gurus writing the middle > layers who are dangerous. Forth originated in the 1970s. There were no local variables, there was no heap, there was maybe 8KB of memory. Quite a lot of Charles Moore's design decisions were work-arounds for the limited hardware platforms that he was working on. This was true for other languages too, but those other languages have moved on and adapted to the new hardware --- Forth remains stymied in the past. DO loops are an atrocity! The I and J are a weird half-step toward local variables. DO seems to work differently going up or down (the rule for how the loop terminates is actually consistent whether the step is positive or negative, but it is very unintuitive). Also, the way that >R data conflicts with DO loops is rather jarring and difficult to teach. All of this use of the return-stack comes off as being a clumsy hack to deal with a shortage of registers --- which is exactly what it was! The ANS-Forth committee, as usual, took a bad situation and made it worse. This is what the ANS-Forth document (13.3.3.) says: "The storage resource may be the return stack or may be implemented in other ways, such as in registers." This is absurd!!! You can't have local variables on the return stack because this will conflict with the use of >R etc.. It won't conflict with DO loops because the offset to the locals can be adjusted inside of the DO loop, but it will conflict with >R because there is no way to know how many >R data are on the return stack (at compile-time). DO loops should have been slam-dunked into the trashcan of history, but the ANS-Forth committee just lacked the backbone to make decisions like this. What is the point of having two ways to do iteration (DO loops and BEGIN loops)? This seems to imply that BEGIN loops are inadequate (either in terms of efficiency or convenience) and so DO loops were needed. That was true in the old days because we didn't have local variables and so BEGIN loops had to hold their index and limit on the data-stack or the return-stack, where they got in the way of other data. Now that we have local variables though, there is no more need for DO loops and their I and J localish variables. My language is going to be a lot simpler than ANS-Forth. The language will be very minimal, which makes it easy to learn. ANS-Forth is just a complicated mess of rules, many of which are contradictory. There is too much "may or may not" nonsense. I will provide a document similar to the ANS-Forth document that describes my language, but it will make sense. A compiler-writer will be able to read it and know exactly what is necessary for compliance. A programmer will be able to read it and not be utterly confused about what is allowed and what isn't allowed, which is the typical result of reading the ANS-Forth document. It should be easily possible to determine if a program is correct or not, which isn't possible with either ANS-Forth or C. Most of these threads on comp.lang.forth devolve into tedious arguments about what is ANS-Forth compliant and what isn't, which tend to totally baffle novice Forth programmers who initiated the thread by asking what they thought would be a simple question (in this case, Mark asking about CASE). There seems to be as many interpretations of the ANS-Forth document as there are interpretations of the Book of Revelation --- anybody's guess is as good as Anton Ertl's, and sometimes better (for example, Anton recently became confused and thought that >BODY could be used on VALUE words, which will only work in some Forths but is not guaranteed to work on all of them). Forth can be drastically simplified --- that is my aim. Jeff Fox told me that Charles Moore had once commented that ANS-Forth is 100 times more complicated than necessary. When Forth-200x came out, both him and Jeff thought the name was a reference to Charles' remark and meant that the new standard would be 200 times more complicated than necessary, which would be the logical next step. Really! No joke; that is what they thought. Although it is a bit of an exaggeration, it is not that far off the mark. P.S. for Stephen --- Since when is OOP a typical aspect of Forth programs, either small or large? I've never used OOP in Forth --- at least, not beyond the crude inheritance system that I have in the novice package --- I have no intention of supporting OOP in my language except for that same inheritance system. My aim is simplicity, and OOP is grossly complicated. If people want OOP, there are many OOP languages available, but my Forth won't be one of them --- they deserve to be C++ programmers!
[toc] | [prev] | [next] | [standalone]
| From | Gary Bergstrom <forthprgrmr@gmail.com> |
|---|---|
| Date | 2014-02-24 08:39 -0800 |
| Message-ID | <c916600f-965d-4352-a6fe-b60085e681b3@googlegroups.com> |
| In reply to | #28700 |
On Saturday, February 22, 2014 9:28:04 PM UTC-5, hughag...@yahoo.com wrote: > On Friday, February 21, 2014 3:34:43 AM UTC-7, Stephen Pelc wrote: > > > Large Forth programs tend to be well layered, e.g. by OOP > > layers. Large programs tend to be old. It takes a lot of > > time to write a million lines of code. Good large Forth > > applications change the notation. The application > > programmers use a language designed for their application > > domain. Application programmers then write very simple code > > using this language. It's the gurus writing the middle > > layers who are dangerous. > > Forth originated in the 1970s. There were no local variables, there was no heap, there was maybe 8KB of memory. Quite a lot of Charles Moore's design decisions were work-arounds for the limited hardware platforms that he was working on. This was true for other languages too, but those other languages have moved on and adapted to the new hardware --- Forth remains stymied in the past. > So how many readers of this are working on systems with: no local variable, no heap, and 8kB of memory? 8kB of ROM is pretty easy to get, but 8kB of RAM is quite a lot for what I do. My most common processor is an MSP430. Most of the discussions here on CLF deal with BIG parts which hold little to no interest for me. So don't forget the rest of us. Forth still works really well on small embedded systems, especially with a good optimizing compiler. gary
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-02-24 21:29 -0800 |
| Message-ID | <e161bb85-9c58-4e49-9e36-f7026e8abf28@googlegroups.com> |
| In reply to | #28747 |
On Monday, February 24, 2014 9:39:03 AM UTC-7, Gary Bergstrom wrote: > On Saturday, February 22, 2014 9:28:04 PM UTC-5, hughag...@yahoo.com wrote: > > Forth originated in the 1970s. There were no local variables, there was no heap, there was maybe 8KB of memory. Quite a lot of Charles Moore's design decisions were work-arounds for the limited hardware platforms that he was working on. This was true for other languages too, but those other languages have moved on and adapted to the new hardware --- Forth remains stymied in the past. > > So how many readers of this are working on systems with: > no local variable, no heap, and 8kB of memory? > 8kB of ROM is pretty easy to get, but 8kB of RAM is quite a lot for what I do. > My most common processor is an MSP430. Most of the discussions here on CLF deal with BIG parts which hold little to no interest for me. > > So don't forget the rest of us. Forth still works really well on small embedded systems, especially with a good optimizing compiler. As a practical matter (practical as in paying the rent), micro-controllers are the only thing that matters --- desktop-computer software is almost always given away for free. The two times that I've made money as a Forth programmer, it was either directly or indirectly related to CNC machines. The MSP430 has 16 16-bit registers. That is a lot! The biggest difference between olden processors (68xx series, for example) and modern processors is how many registers they have. Another big difference is in how much more non-volatile memory is available now. You are right though, that what hasn't changed much is the amount of RAM available, with 2KB being common and 8KB being quite a lot. The MSP430 has 16 registers (twice as many registers as the 32-bit x86), so the MSP430 can easily support local variables. My plan to discard ANS-Forth's hokey use of the return-stack (>R etc., and DO loops) will work fine on the MSP430. OTOH, a heap is not going to work on a typical MSP430 configuration with maybe 8KB or RAM (the MSP430 can address up to 1MB, but I'm not aware of this ever being done in practice). Be aware that I am actually writing TWO Forth languages. The 1st is for desktop-computers and it requires the processor to be 64-bit. The 2nd is for micro-controllers and it will work with any size of cell: 16-bit, 24-bit (the eZ80 has this) or 32-bit. The first will be used for CAM and other numerical programming, and will also be the platform that the cross-compiler for the 2nd will be written in. There will be some similarity between the two languages, such as both discarding return-stack stuff, and so forth. There will be differences though, such as the 2nd only supporting a heap as an option, but not using the heap as an integral part of the language. Porting programs between the two Forths will be difficult, and rarely done anyway as they are completely different kinds of programs. I think that it is a huge mistake for ANS-Forth to be for both desktop computers and micro-controllers --- it really makes more sense to have two Forth languages, a big and a small, rather than one jack-of-all-trades. Originally I was just going to write the Forth for micro-controllers, and I was going to use ANS-Forth (specifically, Gforth) as the Forth for desktop computers --- that is to say, I was going to write my cross-compiler in ANS-Forth. I was just going to port my MFX (MiniForth cross-compiler) from UR/Forth over to ANS-Forth, and retarget it for some common micro-controller such as the MSP430 or PIC24. There are a lot of problems in ANS-Forth though (for example, no way to determine what word-list a word is in by examining its xt, which is important for error-checking in a cross-compiler) --- because of this I have abandoned ANS-Forth and I'm just writing both Forths big and small myself.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2014-03-11 00:44 +0000 |
| Message-ID | <lflm5e$c8i$1@dont-email.me> |
| In reply to | #28700 |
hughaguilar96@yahoo.com wrote: > DO loops are an atrocity! The I and J are a weird half-step > toward local variables. DO seems to work differently going up > or down (the rule for how the loop terminates is actually > consistent whether the step is positive or negative, but it is > very unintuitive). Also, the way that >R data conflicts with > DO loops is rather jarring and difficult to teach. All of this > use of the return-stack comes off as being a clumsy hack to > deal with a shortage of registers --- which is exactly what it > was! Very true.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2014-03-11 00:45 +0000 |
| Message-ID | <lflma3$d4g$1@dont-email.me> |
| In reply to | #28700 |
hughaguilar96@yahoo.com wrote: > DO loops are an atrocity! The I and J are a weird half-step > toward local variables. DO seems to work differently going up > or down (the rule for how the loop terminates is actually > consistent whether the step is positive or negative, but it is > very unintuitive). Also, the way that >R data conflicts with > DO loops is rather jarring and difficult to teach. All of this > use of the return-stack comes off as being a clumsy hack to > deal with a shortage of registers --- which is exactly what it > was! Very true.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-23 04:35 -0600 |
| Message-ID | <Uq2dnQKHa9VsU5TOnZ2dnUVZ_s-dnZ2d@supernews.com> |
| In reply to | #28643 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > Good large Forth applications change the notation. The application > programmers use a language designed for their application domain. This seems to be an appeal to the high priesthood model of compter programming: quite the opposite from traditional Forth, I would have thought. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 12:31 -0600 |
| Message-ID | <E7ednW6u9e97O57OnZ2dnUVZ_sadnZ2d@supernews.com> |
| In reply to | #28529 |
Paul Rubin <no.email@nospam.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> It's not just what the hardware does. It's what gcc does, unless the >> "optimizer" comes into play. On MIPS it compiles + of signed integers >> into addu, not add (which produces an exception on overflow); on Alpha >> into add, not addv (again exception on overflow). On IA32 into add >> without following it with into. When I rearrange the code so that the >> "optimizer" does not see everything together, gcc does what I intend >> the code to do. A proper optimizer does not change that. > > Are you seriously saying that the optimized program always has to do the > exact same thing as the unoptimized one, even when the standard > explicitly says the behavior is undefined? Yes, he is. Except in some cases. And those cases are defined by him, using reasoning that he cannot (or will not) explain, which has something to do with intuition. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-18 18:19 -0500 |
| Message-ID | <op.xbh2120o5zc71u@localhost> |
| In reply to | #28529 |
On Tue, 18 Feb 2014 11:28:26 -0500, Paul Rubin <no.email@nospam.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> It's not just what the hardware does. It's what gcc does, unless the >> "optimizer" comes into play. On MIPS it compiles + of signed integers >> into addu, not add (which produces an exception on overflow); on Alpha >> into add, not addv (again exception on overflow). On IA32 into add >> without following it with into. When I rearrange the code so that the >> "optimizer" does not see everything together, gcc does what I intend >> the code to do. A proper optimizer does not change that. > > Are you seriously saying that the optimized program always has to do the > exact same thing as the unoptimized one, [...] It should, yes. It should do exactly what I told it to do. That's our expectations as a programmer, well, definately my expectation. However, all high-level code must be converted to assembly or binary and the correlation is not always one-to-one. > Are you seriously saying an optimizer should preserve that behavior? Of course, it's impractical to preserve boundary effects during optimization. This affects evenly lowly languages like Brainfuck. The sequence: [] will continue if the current cell is zero, but is an infinite loop if non-zero. [] occurs *frequently* in Brainfuck code, especially so if the code is generated by program. The questions that arise are: 1) Did someone intentionally code an infinite loop to halt the program, or does the code always continue? 2) Even though an infinite loop is valid code in Brainfuck, can it be assumed to be useless, i.e., generated by program not a person, and safely be optimized away? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 11:06 -0600 |
| Message-ID | <07qdndj_37WIDp7OnZ2dnUVZ_tmdnZ2d@supernews.com> |
| In reply to | #28525 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>>>> If you take GCC's approach on ANS Forth, you would deliberately >>>>> miscompile all code that wouldn't produce identical results on mixed >>>>> and separate FP stacks, because that code "is obviously >>>>> non-standard" and therefore broken. This is your attitude. >>>> >>>>No, it's not. If the code is well-defined and has an environmental >>>>dependency on separate FP stacks, and the system has a separate >>>>stacks, the everything is fine. You know why? Because that's what >>>>the standard says. And that's the only reason. >>> >>> What Forth-94 says about the floating-point stack is an exercise in >>> weasel-wording and Forth-2012 is not much better. For Forth-2012 >>> that's because the committee did not find a consensus on the right >>> approach, and I guess that's also true for Forth-94. >>> >>> Given that weasel-wording, it would be easy for someone so inclined to >>> justify the miscompilation (possibly after some course in language >>> lawyering given by C compiler writers). >> >>I don't believe so. > > I'll have a try at such a justification: > > "You know why? Because that's what the standard says. And that's the > only reason." I don't follow your reasoning here. I can't see anywhere that the standard that would permit such behaviour. >>>>It's very easy to pick extreme cases and say "GCC shouldn't do this". >>>>It much harder to specify around the boundaries exactly what it is >>>>allowed to do. >>> >>> That's were "be conservative" comes in. When in doubt, better don't >>> change the behaviour. >> >>But where exactly is that "in doubt" boundary? And who is to be in >>doubt? > > The compiler writer. And the doubt cases are whenever they are in > doubt of what the programmer intended. How can you have any idea of what the programmer intended? That's the problem I'm trying to get at. >>> For >>> >>> if (x<x-1) ... >>> >>> every single target of gcc does have wrap-around 2's-complement >>> arithmetics (and this would even work for wraparound 1s-complement and >>> wraparound sign-magnitude arithmentics, if they exist; and "if >>> (x<=x-1)" would even work for saturating arithmetics, but that's not >>> used for ordinary ints on any platform I know). >>> >>> But actually, some piece of code may be intended to only work on IA32 >>> (or x86 as people with little knowledge of computer architecture call >>> it), so even if it would not work on some other architecture targeted >>> by gcc (the only thing that comes to my mind is alignment issues), the >>> compiler should preserve the behaviour by default when compiling for >>> IA32. >> >>This is just a restatement of your previous opinion. There's no >>"...because" other than "that's what the hardware does." > > It's not just what the hardware does. It's what gcc does, unless the > "optimizer" comes into play. On MIPS it compiles + of signed integers > into addu, not add (which produces an exception on overflow); on Alpha > into add, not addv (again exception on overflow). On IA32 into add > without following it with into. When I rearrange the code so that the > "optimizer" does not see everything together, gcc does what I intend > the code to do. A proper optimizer does not change that. So it is what the hardware does. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-18 12:51 +0000 |
| Message-ID | <5303575f$0$25264$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #28503 |
In article <waidnb0UgsHox5_OnZ2dnUVZ_uKdnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
<SNIP>
>
>Having said that, there have been cases of behaviour that was allowed
>by the C standard but was so dangerous that it shouldn't ever be
>implemented: one example I remember was speculative stores into
>conditionals. So I'm not totally opposed to the "it shouldn't do that
>even if it's allowed to in theory" argument in some specific cases,
>when there is an extremely good argument. But that argument needs to
>be better than "x86 does do it".
The safe languages (Algol, Ada, Pascal) 2] generate an overflow that
terminates the program, if you add 1 to the largest possible int. 1]
It is not fair to Intel to say that the x86 doesn't accomodate
that. There is an overflow flag and the one byte INTO instruction
to trap on overflow. That is about as good as it gets.
>
>Andrew.
1] It is highly unexpected for a c-compiler to do the same,
but it is within specifications.
The correct way to do the intended
x<x-1
is using
try { ..
} on overflowtrap do { .. } .
This could even be done in c (using longjump() ) and extreme
discipline.
2] No Java isn't safe.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 14:40 +0000 |
| Message-ID | <2014Feb18.154003@mips.complang.tuwien.ac.at> |
| In reply to | #28519 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <waidnb0UgsHox5_OnZ2dnUVZ_uKdnZ2d@supernews.com>,
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
><SNIP>
>>
>>Having said that, there have been cases of behaviour that was allowed
>>by the C standard but was so dangerous that it shouldn't ever be
>>implemented: one example I remember was speculative stores into
>>conditionals. So I'm not totally opposed to the "it shouldn't do that
>>even if it's allowed to in theory" argument in some specific cases,
>>when there is an extremely good argument. But that argument needs to
>>be better than "x86 does do it".
>
>The safe languages (Algol, Ada, Pascal) 2] generate an overflow that
>terminates the program, if you add 1 to the largest possible int.
Yes, I have experienced such language implementations, and in my
experience that's a bad idea: I had a Modula-2 program that did a
computation on CARDINALs (unsigned numbers) like 2-3+5, and the
program crashed. Integer arithmetic in such languages does not obey
the associative law. Fortunately, the spiritual descendent of these
languages, Java, did not repeat this mistake and defined wraparound
arithmetic for integers. The other viable alternative is to use
bigints.
>The correct way to do the intended
> x<x-1
>is using
>
>try { ..
>
>} on overflowtrap do { .. } .
That's not C. What is it? But let's assume Forth (to come back to
on-topic):
The two variants are
dup 1 - < if ...
and
1 ' - catch if drop ... then drop
Neither is standard, but the first one works everywhere and the second
one nowhere.
BTW, I just thought whether the standard MAX-N ENVIRONMENT? query
could be used here, but there is no standard way to get from MAX-N to
MIN-N.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web