Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #35035 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2014-12-19 15:59 -0800 |
| Last post | 2014-12-23 15:16 +0000 |
| Articles | 20 on this page of 340 — 34 participants |
Back to article view | Back to comp.lang.forth
FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-19 15:59 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-20 08:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-20 03:40 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-20 13:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-21 04:38 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-21 21:38 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-21 16:32 -0600
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-22 03:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2014-12-22 00:53 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-22 13:43 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 03:38 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-22 11:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-22 07:51 -0500
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-22 15:59 +0000
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-23 11:17 -0500
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 02:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 06:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2014-12-23 12:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 13:12 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 07:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 10:31 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 15:04 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 19:28 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-25 02:43 -0600
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-25 20:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:43 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-25 20:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 13:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2014-12-26 11:40 -1000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:33 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-05 21:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 21:33 -1000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 10:24 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:13 -1000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 00:41 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 14:59 -1000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-06 11:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:16 -1000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 18:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 18:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2014-12-25 12:46 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 14:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2014-12-27 09:48 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 12:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-29 13:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 20:13 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 20:21 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 12:39 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-23 15:16 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 17:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-24 05:34 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 21:12 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 12:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 09:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 08:52 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 09:18 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:14 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 12:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 09:15 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 12:07 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 11:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-24 03:26 -0600
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 19:45 +0100
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-24 05:31 +0100
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-24 03:28 -0600
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-24 11:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 22:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 14:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-23 22:58 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-23 15:38 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 02:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 19:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 06:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 22:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 07:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 23:32 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:39 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 01:21 +0100
Re: FORTH on the Advanced Placement Computer Science ! mix <mix@test.net> - 2014-12-25 09:06 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 09:39 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 21:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-25 23:34 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 17:09 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 02:22 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 17:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 05:22 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 14:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-26 16:13 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 09:50 +0000
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-27 04:41 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 10:21 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-30 11:50 -0800
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2014-12-31 15:02 +0100
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-26 03:28 -0600
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-26 10:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-26 14:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-26 16:36 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-26 21:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-27 10:17 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 12:09 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-01 21:07 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-02 11:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2015-01-02 12:45 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-02 23:42 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-04 14:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-06 03:51 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-05 20:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 19:25 -1000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 14:52 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-09 08:04 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:14 -1000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-09 16:25 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 09:10 -1000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 14:35 +0300
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-10 20:51 -1000
Re: FORTH on the Advanced Placement Computer Science ! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-11 11:29 +0100
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-11 03:46 -0800
Re: FORTH on the Advanced Placement Computer Science ! Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-11 15:58 +0100
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 23:01 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-11 16:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-11 16:50 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 08:53 +0300
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-12 08:28 +0000
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-12 11:10 +0000
Re: FORTH on the Advanced Placement Computer Science ! stephen@mpeforth.com (Stephen Pelc) - 2015-01-11 11:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-11 16:56 +0300
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 19:47 +0000
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 08:03 +0300
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-11 23:44 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 09:05 +0300
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-12 10:56 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-31 10:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-09 23:01 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 14:43 +0300
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2015-01-11 23:45 +0100
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-12 09:09 +0300
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 10:52 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 15:31 +0300
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-05 23:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-05 22:22 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 08:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 10:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 13:37 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 13:02 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 15:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 01:15 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 15:23 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 19:25 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 17:52 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 21:15 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-06 19:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 05:07 -0600
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 15:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 12:41 -0600
Re: FORTH on the Advanced Placement Computer Science ! Elizabeth D Rather <erather@forth.com> - 2015-01-07 11:09 -1000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 08:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-07 11:52 +0000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-09 14:14 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-09 20:04 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-10 20:57 -1000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-11 08:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-11 19:59 +0000
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-11 22:51 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-15 22:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! humptydumpty <ouatubi@gmail.com> - 2015-01-16 08:56 -0800
Re: FORTH on the Advanced Placement Computer Science ! Mark Wills <markwills1970@gmail.com> - 2015-01-07 01:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! stephen@mpeforth.com (Stephen Pelc) - 2015-01-07 12:33 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 14:25 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-07 16:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 15:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 06:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 08:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 10:06 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-07 18:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-07 10:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Alexander Skobelev <al.skobelev@gmail.com> - 2015-01-10 16:48 +0300
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 16:25 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 08:50 -1000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2015-01-07 10:37 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 16:32 +0000
Re: FORTH on the Advanced Placement Computer Science ! Doug Hoffman <glidedog@gmail.com> - 2015-01-09 18:28 -0500
Re: FORTH on the Advanced Placement Computer Science ! Doug Hoffman <glidedog@gmail.com> - 2015-01-07 07:31 -0500
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 16:24 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 14:02 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 09:26 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 17:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 11:01 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-07 17:18 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-07 09:44 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 09:31 +0000
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 03:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 15:21 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-07 18:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 09:40 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-08 14:49 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-08 17:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:42 -0600
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-06 08:13 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 02:52 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-08 18:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-08 20:29 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:30 -1000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 11:14 -0800
Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-09 22:18 +0000
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-10 03:15 +0100
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-09 20:56 -0800
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-12 03:02 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-12 10:14 +0000
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-10 11:39 -0800
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-13 18:08 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-13 20:04 +0000
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-14 02:43 +0100
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-14 13:34 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-15 02:03 +0000
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-15 12:03 +0000
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-15 06:47 -0800
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-10 19:15 +0000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-10 12:52 -0800
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-10 19:05 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-11 09:28 -0800
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-11 14:45 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-12 18:28 -0800
Re: Standards (was FORTH on the ...) Elizabeth D Rather <erather@forth.com> - 2015-01-12 17:12 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-12 20:55 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 03:48 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 06:05 -0800
Re: Standards (was FORTH on the ...) Julian Fondren <julian.fondren@gmail.com> - 2015-01-13 06:34 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 06:51 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 08:03 -0800
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 19:18 -0800
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-13 08:26 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-13 09:54 -0800
Re: Standards (was FORTH on the ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-13 17:35 +0000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 18:19 -0800
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-14 21:03 +0000
Re: Standards (was FORTH on the ...) "WJ" <w_a_x_man@yahoo.com> - 2015-01-14 21:07 +0000
Re: Standards (was FORTH on the ...) "Alex McDonald" <blog@rivadpm.com> - 2015-01-15 01:06 +0000
Re: Standards (was FORTH on the ...) Mark Wills <markwills1970@gmail.com> - 2015-01-15 00:52 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-15 01:17 -0800
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-15 17:35 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-15 20:38 -0800
Re: Standards (was FORTH on the ...) Alex McDonald <blog@rivadpm.com> - 2015-01-16 10:47 -0800
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-16 20:47 +0100
Re: Standards (was FORTH on the ...) krishna.myneni@ccreweb.org - 2015-01-16 14:37 -0800
Re: Standards (was FORTH on the ...) krishna.myneni@ccreweb.org - 2015-01-16 17:26 -0800
Re: Standards (was FORTH on the ...) Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 03:03 +0100
Re: Standards (was FORTH on the ...) "Elizabeth D. Rather" <erather@forth.com> - 2015-01-13 10:40 -1000
Re: Standards (was FORTH on the ...) hughaguilar96@gmail.com - 2015-01-13 19:04 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-11 23:24 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 18:09 +0100
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-09 09:31 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-09 11:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 22:38 +0100
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2015-01-16 13:44 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 02:39 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-17 13:37 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 18:44 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 12:57 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-18 22:48 +0100
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-19 03:10 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-18 18:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-17 11:45 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-17 17:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-18 14:57 -0800
Re: FORTH on the Advanced Placement Computer Science ! awegel@arcor.de (Alexander Wegel) - 2015-01-19 00:49 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-19 15:04 +0000
Re: FORTH on the Advanced Placement Computer Science ! beeflo <beeflobill@gmail.com> - 2015-01-19 16:24 -0800
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 03:26 +0100
Re: FORTH on the Advanced Placement Computer Science ! Melzzzzz <mel@zzzzz.com> - 2015-01-20 04:23 +0100
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-23 21:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-20 07:10 +0000
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-20 12:04 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-20 16:11 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:40 -0800
Re: FORTH on the Advanced Placement Computer Science ! Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-01-20 23:29 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-20 20:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-21 01:55 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-22 00:05 -0800
Re: FORTH on the Advanced Placement Computer Science ! Mark Wills <markwills1970@gmail.com> - 2015-01-19 07:42 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-06 09:50 +0000
Re: FORTH on the Advanced Placement Computer Science ! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:38 -0600
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-09 21:34 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2015-01-09 23:28 -0800
Re: FORTH on the Advanced Placement Computer Science ! "hughaguilar96@yahoo.com" <hughaguilar96@gmail.com> - 2015-01-10 11:10 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2015-01-11 00:49 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-12 22:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-12 17:33 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-12 19:17 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-12 21:06 -0800
Re: FORTH on the Advanced Placement Computer Science ! Julian Fondren <julian.fondren@gmail.com> - 2015-01-13 04:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-13 15:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-13 18:45 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-13 21:12 -0800
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-16 20:41 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-21 20:42 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2015-01-21 23:19 -0800
Re: FORTH on the Advanced Placement Computer Science ! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-26 20:20 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-05 10:31 +0000
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-27 07:16 -0800
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-27 13:08 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-27 10:54 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-27 11:01 -0800
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-27 21:25 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2014-12-29 05:20 -0800
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 11:53 +0000
Re: FORTH on the Advanced Placement Computer Science ! mhx@iae.nl - 2015-01-04 05:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! krishna.myneni@ccreweb.org - 2015-01-04 08:00 -0800
Re: FORTH on the Advanced Placement Computer Science ! Coos Haak <chforth@hccnet.nl> - 2014-12-26 15:00 +0100
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-26 13:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 10:55 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 07:08 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-24 23:27 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 10:34 +0000
Re: FORTH on the Advanced Placement Computer Science ! Paul Rubin <no.email@nospam.invalid> - 2014-12-25 09:47 -0800
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 19:44 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 11:00 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 12:01 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-25 16:03 +0000
Re: FORTH on the Advanced Placement Computer Science ! Tom O'Donnell <tod@nospam.com> - 2014-12-25 17:20 +0000
Re: FORTH on the Advanced Placement Computer Science ! hughaguilar96@gmail.com - 2014-12-26 21:53 -0800
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2015-01-08 22:30 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 20:00 +0100
Re: FORTH on the Advanced Placement Computer Science ! "WJ" <w_a_x_man@yahoo.com> - 2014-12-25 08:36 +0000
Re: FORTH on the Advanced Placement Computer Science ! Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-25 19:36 +0100
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:09 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-23 15:35 +0000
Re: FORTH on the Advanced Placement Computer Science ! "Alex McDonald" <blog@rivadpm.com> - 2015-01-05 19:16 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:51 +0000
Re: FORTH on the Advanced Placement Computer Science ! Michael Barry <barrym95838@yahoo.com> - 2014-12-21 16:02 -0800
Re: FORTH on the Advanced Placement Computer Science ! visualforth@rocketmail.com - 2014-12-22 10:51 -0800
Re: FORTH on the Advanced Placement Computer Science ! JUERGEN <epldfpga@aol.com> - 2014-12-22 05:47 -0800
Re: FORTH on the Advanced Placement Computer Science ! rickman <gnuarm@gmail.com> - 2014-12-22 09:10 -0500
Re: FORTH on the Advanced Placement Computer Science ! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-22 15:23 +0000
Re: FORTH on the Advanced Placement Computer Science ! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-23 15:16 +0000
Page 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-15 06:47 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <b6f3707d-c42a-4a09-b3b3-aac0dc59caad@googlegroups.com> |
| In reply to | #35822 |
On Thursday, 15 January 2015 12:57:11 UTC, Anton Ertl wrote: > "Alex McDonald" <blog@rivadpm.com> writes: > [Anton Ertl:] > >> The standard that Ted Ts'o referred to to justify making ext3 less > >> crash-resistant is POSIX; this is a standard on Unix file systems in > >> general, not just for ext3 or ext4. It does (or did, at the time) not > > > >Some history. http://lwn.net/Articles/351422/ on POSIX. > > Any particular part of that long page that you want to point out? > Maybe one of my (anton's) comments? In any case, among other things > Val Aurora states what I stated: > > |Fortunately for the file systems developers, the POSIX specification > |is so very minimal that it doesn't even mention the topic of file > |system behavior after a system crash. After all, the original > |FFS-style file systems (e.g., ext2) can theoretically lose your entire > |file system after a crash, and are still POSIX-compliant. No, I included it as background information, since we are probably at the edges of most people's knowledge about the history of this topic, but they might just be interested. > > >(Slightly off the subject, but if you're arguing for soft updates as an > >option -- which you mention without commment -- then see > >http://lwn.net/Articles/339337/; "Overall, soft updates is a > >sophisticated, insightful, clever idea - and an evolutionary dead end. > >Journaling and copy-on-write systems are easier to implement, require > >less special-purpose code, and demand far less of the programmer writing > >to the interface." > > Soft updates are only one of the approaches I mentioned. There are > interesting insights that can be gained from them: > > Originally there was a design (FFS/UFS) that does not meet the > requirement of keeping a consistent snapshot of the data on crashes, > as demonstrated in my story. > > Soft updates tried fulfill the requirement by keeping the on-disk > structure the same and ordering the writes; apparently that led to > complications in the code, so that other solutions won out: > > Journaling puts (part of) the data in a journal, but keeps the on-disk > data structure the same otherwise, and writes the data there later. > The buffering offered by the journal relaxes the ordering constraints > to some extent. > > Log-structured/copy-on-write file systems write the data to > unallocated places all the time, relaxing the ordering constraints > even more. > > Lesson: It may be easier to redesign from scratch to meet a certain > requirement than to try to work the requirement into the existing > design, even if you find a way to do it. Agreed. > > >> And here's a guarantee that a high-quality file system should give: > >> > >> http://www.complang.tuwien.ac.at/papers/czezatke%26ertl00/#tth_sEc3.2 > > > >Ordered writes really don't make for decent performance > > I am much more interested in a file system that keeps my data than in > one that excels on benchmarks. > > And the guarantee I ask for can be satisfied with very few ordering > constraints. E.g., if I want one commit per minute (i.e., I am > prepared to lose up to a minute of work on a crash), I need two disk > write barriers per minute (and having only one is almost as good). I > doubt that you can measure the perfomance impact of these write > barriers. If a minute is too much, I can do a commit every 10s, and > the overhead will still be hardly noticable. > > You should not believe people who try to sell you on their misdesigned > file systems, and justify it with performance. Sure, fixing the > misdesigned file system in a cheap way by making all writes > synchronous (if that even works as a fix for ext4) will make it very > slow, but if you design a file system for the requirement, it will > cost relatively little. I don't believe people who try to sell me on their misdesigned file systems regardess of performance. Believe me. > > > and write thru > >caching on disks can mess up even the most well behaved IO stream. > > I guess you mean write(back) caching. Disk drives have stuff like > write barriers to allow to combine the performance advantages of write > caching while still giving enough guarantees about the order of > writes. You're right. I meant ordered writes through cached /virtualised/ disks and mis-spoke. It was late. I'm meaning the behaviour of file systems running in VMs where the disks are virtualized and are required to be cached by design (since performance is one of the design criteria, but not at the expense of crash consistency & the requirement for no lost writes). Any guarantees given by the file system or the OS require VM cooperation, and there's a lot of (as yet incomplete) work being done on that; for example, where cache hints & decisions are being pushed out to the storage system so that it has visibility. There's work currently on this (vvol) taking place in T10.org. > > >> The problem with Ted Ts'o, like with the GCC maintainers, is that he > >> values benchmark results above real-user concerns like keeping data > >> across crashes. > > > >Is this what you are referring to? > >http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/. > > He expressed his attitude in serveral places. I might have read this, > or might have read it somewhere else. > > >I'd agree that there's perhaps too much "it's good enough" in this 2009 > >blog when it patently isn't good enough today; and it probably wasn't > >good enough then either. > > It certainly was not good enough in 2009; it never was. I have > written the first version of the page linked above in 1997 or earlier > <http://web.archive.org/web/19971016211234/http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html> > and yet Ted Ts'o developed ext4 in 2009 or so to have the same > problem, and at about the same time "optimized" ext3 so that it > acquired the same problem, and apologized for not making ext3 as bad > as he designed ext4 to be. > > - 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-10 19:15 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m8rtnb$kmd$1@dont-email.me> |
| In reply to | #35682 |
on 10/01/2015 02:15:38, Bernd Paysan wrote: > Alex McDonald wrote: > >> on 09/01/2015 19:14:44, wrote: >>> Avoiding decisions is actually worse than making bad decisions because >>> the worst-case scenario allowed becomes the standard. If a person >>> wants his pro gram to run on any ANS-Forth compiler, he has to assume >>> the worst-case ever y time --- because SwiftForth is always the >>> worst-case, then SwiftForth eff ectively becomes the standard. >> >> Nonsense. Avoiding decisions is normally because (a) no-one recognises >> that a decision needs to be made (b) making a decision would create >> issues for existing products (c) uniformity is not required or is >> undesirable. > > I must say, I've some sympathy with Hugh's argument, let's say with > the first half of it - as usual, he starts reasonable and then his > hate at Forth Inc. takes over... What he describes is what happened in > the C world: the standard team left something open to be > implementation defined, and the implementers think that entitles them > to start games, or format the hard disk, or eat your cat, because they > don't understand that they have a responsibility to let common > practice emerge, but think the standard is a specification which they > simply have to implement, and over which they don't have control. The C standard may be a pathological example, but my experience and that of others I work with doesn't match up to Hugh's claim that "avoiding decisions is actually worse than making bad decisions because the worst-case scenario allowed becomes the standard." Avoiding decisions and bad decisions bite everyone, and hard. This is commercial hard-nosed pragmatism at work, and even though these bodies are made up of competitors, there is no sense in a bad, defective or incomplete standard. So given grey or accidentally or even deliberately undefined areas, the market does its imperfect sifting and a de jure standard appears. If the standards body is still active, the issue get recognised, and there's an informal to formal agreement process. There is sometimes the tendency to think that parts of standards that you find difficult or impossible or even stupid aren't seen that way by others. This is where Hugh would be a complete nightmare. Ranting and raving like a swivel eyed loon generally gets you nowhere. Standards processes requires pragmatism and a willingness to compromise. Your competitors might see a commercial advantage in having it his way rather than yours. You get to vote, but you can't dictate. In summary, I can't think of an example in my area of expertise where it has been the worst-case scenario becomes the standard. No-one wants that. > > This is why the Forth 20xx team has some "tighten up the standard" > tasks ongoing - and allows people to participate, so that people don't > feel like the standard is out of their control (won't help on people > like Hugh who choose to insult people so much that they don't want to > work with him). That is good. There might be a criticism or two about the slowness of the process, and the method by which the Forth200x committee does its work and reaches consensus. Hugh's problem is not the committee's concern however. > I've to check the notes, but we want to at least make > 1 CHARS equals 1 (because most systems already do that, most programs > rely on thatn, and the few with 1 CHARS != 1 byte could be fixed), and > to make two's complement number representation standard. Yes. That would make sense. > > The latter would remove some ambiguous conditions, the former would > make common practice actually standardized. We all learned from the > misinterpretation of the C standard, and want to avoid that. We > probably should also write that if the standard allows implementers > choice, a high quality implementation is one that makes the best > possible choice, and if consensus emerges (because "best possible" can > only be one thing, can't it?), we will standardize on that. There can be more than one "best possible". Technical goodness and commercial success sometimes don't reside in the same end product. > > Of course, if you want to have a portable program, the attitude of > expecting the worst is the right attitude. Stephen Pelc said to me > that the way I port my programs (by putting pressure on the vendor to > implement all the things I need in a reasonable way), my programs will > never really become portable. He's right, but I'm doing that with > everybody I cooperate with, and in turn make their systems more > uniform and more similar to each other, which means that not only *my* > programs become more portable (within the set of implementers I > cooperate), but those of other people as well. > > When we are discussion "egoistic programming", my style certainly is > egoistic. Writing portable programs, as Stephen puts it, is an egoless > discipline, because apparently writing Forth systems is an egoistic > discipline, which is why if you know one Forth, you know one Forth. > > I don't like it that way. The implementers provide a service to the > application and library developers, and we would certainly have more > libraries if it was easier to write a library that did run on more > than one single Forth system, without a lot of painful porting effort. > That's beyond my current professional experience, but I take your word for it. Regretably, I no longer code for a living.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-10 12:52 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <a6d73bf0-397a-4a57-bc12-d8fd48cb7ff2@googlegroups.com> |
| In reply to | #35678 |
On Friday, January 9, 2015 at 3:18:13 PM UTC-7, Alex McDonald wrote: > > Avoiding decisions is actually worse than making bad decisions because > > the worst-case scenario allowed becomes the standard. If a person > > wants his pro gram to run on any ANS-Forth compiler, he has to assume > > the worst-case ever y time --- because SwiftForth is always the > > worst-case, then SwiftForth eff ectively becomes the standard. > > Nonsense. Avoiding decisions is normally because (a) no-one recognises > that a decision needs to be made (b) making a decision would create > issues for existing products (c) uniformity is not required or is > undesirable. Your (a) doesn't make any sense, as people can't avoid a decision without first recognizing that the decision needs to be made --- that would be like avoiding pot-holes in the road while insisting that pot-holes don't exist. Your (b) implies that those existing products (SwiftForth) are immutable --- the standard conforms to SwiftForth, rather than SwiftForth conforming to the standard. Your (c) is just absurd --- uniformity is actually the purpose of having a standard --- what other purpose could there be? > > Adding a lot of "defined waffles" to ANS-Forth is worse than just > > declaring the worst-case scenario to be the standard because all of > > these "defined waffles" confuse the heck out of the programmers and > > nobody is really sure w hat is standard and what isn't standard. > > > > This brings to mind Rush's "Free Will" song: "If you choose not to > > decide, you still have made a choice." > > > > I said this to John Hart of Testra when I visited recently, and he > > replied: "[The ANS-Forth committee] should have just declared > > SwiftForth to be the standard." Note however, that he didn't say that > > he would follow the ANS-Forth standard by buying a copy of > > SwiftForth. LOL > > Then he, like you, doesn't understand how standards are developed, how > committees work, nor what they mean in practice. I suspect he was > humouring you. I think that he was saying that it would have been more *honest* if the ANS-Forth committee just declared SwiftForth to be the standard. As it is we have a lot of waffling in the standard: (3.2.3.2) The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. The brave ANS-Forth programmer is going to read this and say: "WTF???" He is baffled as to whether he can pass data into colon words at compile-time or not. If the control-flow stack is the data-stack, then he can't because the control-flow stuff will be put on top of his data making his data inaccessible. Ultimately, a program is not going to be considered ANS-Forth compliant if it doesn't work under SwiftForth, so this is really the same as declaring SwiftForth to be the standard, but less honest because it involves an intermediate step of total confusion. But wait! A program that runs under SwiftForth is still not going to be considered ANS-Forth compliant unless it also runs under Gforth (because Anton and Bernd are members of the committee). The brave ANS-Forth programmer may have done a tick on various words and gotten an xt --- he is going to be surprised to discover that Gforth doesn't provide an xt for all of the words. Ticking semicolon, for example, will abort Gforth (but not SwiftForth) --- this apparently is because (6.1.0460) "Interpretation semantics for this word are undefined." Another WTF moment! https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ In this thread my original version of MACRO: ticked the words and held onto their xt values, rather than hold onto the source-code (holding onto the source-code, as my MACRO: does now, results in late-binding issues). This was yet another example of me being "wrong from time-to-time:" On Tuesday, November 24, 2009 at 11:37:04 PM UTC-7, ron wrote: > On Nov 25, 7:38Â am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote: > > > I didn't compile your program because it is not ANS-Forth. I don't > > have iForth and I'm not going to spend the $100 to buy it. I really > > need ANS-Forth in order to be able to run programs such as this. > > I suppose "gforth" is not an ANS-Forth? Your version of the program > does not compile under gforth 0.7.0: > > lc53.f:27: Cannot tick compile-only word (try COMP' ... DROP) > over ['] >>>;<<< = if 2drop postpone ; immediate exit > then Ultimately, nobody can be an ANS-Forth programmer without permission from the "leading experts" --- this is because ANS-Forth is a cult. That thread mentioned above is actually very good reading --- I recommend it to everybody who wants to understand ANS-Forth --- this thread was immediately after the symtab fiasco (notice that I ask Elizabeth Rather if I'm "out of the penalty box yet," but don't get any response). Here is fun quote from that thread related to semicolon not having an xt value: On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote: > Hugh Aguilar <hugoaguilar@rosycrew.com> writes: > >I don't understand how a word can not have execution semantics. > > That's quite simple: By not defining execution semantics in the > definition of the word in the standard document. Look up the > definition of ";" in the standard, and you will see that there is no > "Execution:" section there; and there are other labeled sections > there, so the "omitted label" sentence of 3.4.3.1 does not apply. > > >For immediate words (IF, ;, etc.) > > IF and ";" are not immediate words in the standard. A system can > implement them as immediate words, but a program cannot rely on their > immediacy. > > >I looked up ['] in the ANS-Forth document and it says: > > > >"Place name's execution token xt on the stack." > > What's the execution token of a word that has no execution semantics. > > Hmm, since you think that ";" is immediate, I guess you want an > execution token that, when executed, performs the compilation > semantics. You can get that as follows. Before the rest of the > program, define: > > : ; postpone ; ; immediate > > Now you have an immediate ";" with an execution semantics that's the > same as the compilation semantics, and you can tick it. > > >What I am saying is that I didn't have any warning that what I was > >doing in MACRO: was going to be a problem. > > A system that would tell us all non-standard usages would be nice, but > we don't have that. For now the solution is to test on as many > systems as possible.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-10 19:05 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <745673d7-eb4e-43bb-adc3-366cdfa9552a@googlegroups.com> |
| In reply to | #35689 |
On Saturday, January 10, 2015 at 1:52:58 PM UTC-7, hughag...@gmail.com wrote: > > What's the execution token of a word that has no execution semantics? This sounds like a Zen koan: "What is the sound of one hand clapping?" You know, riddling the ANS-Forth students like this might be one reason why nobody is volunteering to be an ANS-Forth student. This was actually before I wrote the novice package, at a time when I had written very little code in ANS-Forth (the LowDraw program and the LC53 encryption cracker) --- I ought to get some credit for being such a diehard that I persevered and learned ANS-Forth --- but instead I'm just told that my code sucks and that I can never be an ANS-Forth programmer no matter how much ANS-Forth code I may write.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-11 09:28 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <e213df4d-5ae1-43d6-8646-b79e8eb46998@googlegroups.com> |
| In reply to | #35689 |
on 10/01/2015 20:52:56, wrote: > On Friday, January 9, 2015 at 3:18:13 PM UTC-7, Alex McDonald wrote: >> > Avoiding decisions is actually worse than making bad decisions because >> > the worst-case scenario allowed becomes the standard. If a person >> > wants his pro gram to run on any ANS-Forth compiler, he has to assume >> > the worst-case ever y time --- because SwiftForth is always the >> > worst-case, then SwiftForth eff ectively becomes the standard. >> >> Nonsense. Avoiding decisions is normally because (a) no-one recognises >> that a decision needs to be made (b) making a decision would create >> issues for existing products (c) uniformity is not required or is >> undesirable. > > Your (a) doesn't make any sense, as people can't avoid a decision > without f irst recognizing that the decision needs to be made --- that > would be like avoiding pot-holes in the road while insisting that > pot-holes don't exist. Standards committees don't avoid making decisions. If it appears that decisions are being avoided, it's normally because no-one realises that there is a decision to be made. > > Your (b) implies that those existing products (SwiftForth) are > immutable -- - the standard conforms to SwiftForth, rather than > SwiftForth conforming to the standard. Yes. There are many standards that work this way. For example, the IETF's http://www.ietf.org/tao.html explains "We believe in rough consensus and running code". However, immutability is not a criteria. > > Your (c) is just absurd --- uniformity is actually the purpose of > having a standard --- what other purpose could there be? Interoperability is the purpose. Uniformity is undesirable. Imagine a recipe for faggots. I'm sure you have a favourite, as I know you've written on the subject of faggots here before. The "standard" (in this case, wikipedia) says "A faggot is traditionally made from pig's heart, liver and fatty belly meat or bacon minced together, with herbs added for flavouring and sometimes bread crumbs; wrapped with caul fat and baked." There are many variations on that basic recipe, and they'd all be considered faggots. Some have lamb, some omit hearts, others don't use caul. But most folks know a faggot when they see one, even though there is variety. In other words, if you and I were to create competing faggots, my faggot would not be the same as your faggot, but they'd both be faggots based on the standard. The purpose of interoperability is served; a faggot customer can be guaranteed a faggot when they order a faggot, and either your faggot or mine meets the requirement they have for a juicy faggot. But uniformity is avoided; I would claim my faggots taste superior to yours. > >> > Adding a lot of "defined waffles" to ANS-Forth is worse than just >> > declaring the worst-case scenario to be the standard because all of >> > these "defined waffles" confuse the heck out of the programmers and >> > nobody is really sure w hat is standard and what isn't standard. >> > >> > This brings to mind Rush's "Free Will" song: "If you choose not to >> > decide, you still have made a choice." >> > >> > I said this to John Hart of Testra when I visited recently, and he >> > replied: "[The ANS-Forth committee] should have just declared >> > SwiftForth to be the standard." Note however, that he didn't say that >> > he would follow the ANS-Forth standard by buying a copy of >> > SwiftForth. LOL >> >> Then he, like you, doesn't understand how standards are developed, how >> committees work, nor what they mean in practice. I suspect he was >> humouring you. > > I think that he was saying that it would have been more *honest* if > the ANS -Forth committee just declared SwiftForth to be the standard. Why? There were several companies and other interested parties. > As it is we h ave a lot of waffling in the standard: But there lies the art of compromise. Our faggot definition doesn't proscribe the recipe, allows interoperability, and multiple faggot products with different recipes can co-exist. Faggot recipes, like standards, are products of evolution not diktat.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-01-11 14:45 -1000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <t4OdnReAIuCJhC7JnZ2dnUU7-LOdnZ2d@supernews.com> |
| In reply to | #35717 |
On 1/11/15 7:28 AM, Alex McDonald wrote: ... >> I think that he was saying that it would have been more *honest* if >> the ANS -Forth committee just declared SwiftForth to be the standard. > > Why? There were several companies and other interested parties. It would have been difficult to "declare SwiftFORTH to be the standard" in 1993, since it wasn't introduced until 1997. Instead, SwiftFORTH was designed to comply with Forth94. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-12 18:28 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2e7cceb2-e3fb-4e11-8027-cba22dc9c706@googlegroups.com> |
| In reply to | #35729 |
On Sunday, January 11, 2015 at 5:45:09 PM UTC-7, Elizabeth D. Rather wrote: > On 1/11/15 7:28 AM, Alex McDonald wrote: > ... > >> I think that he was saying that it would have been more *honest* if > >> the ANS -Forth committee just declared SwiftForth to be the standard. > > > > Why? There were several companies and other interested parties. > > It would have been difficult to "declare SwiftFORTH to be the standard" > in 1993, since it wasn't introduced until 1997. > > Instead, SwiftFORTH was designed to comply with Forth94. I had assumed that SwiftForth was the reference compiler for ANS-Forth. You are saying that there was no reference compiler, and that the ANS-Forth standard was published without being tested in a reference compiler (it would be 4 years after the ANS-Forth standard was written in stone before you managed to write an ANS-Forth compiler, SwiftForth, and your effort was a bug-ridden mess). This is actually much much MUCH worse than using a commercial compiler as the reference compiler, which is what I had been assuming. The correct thing to do, is to write an open-source reference compiler for the new standard, and allow it to be tested by the community BEFORE the standard is written in stone, in order to make sure that the standard makes sense to sober people. If the ANS-Forth standard was published without ever being tested, that would explain why there are so many bugs. For example, if anybody had used LOCALS| even once, they would have noticed that the parameters are backwards --- that is a pretty gross blunder, that can only come from just not testing at all. > Cheers, > Elizabeth When you say, "Cheers," does that mean that you are drinking? Were you drunk when you wrote section 3.2.3.2.? The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2015-01-12 17:12 -1000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <WuidnfXtJ_izECnJnZ2dnUU7-WWdnZ2d@supernews.com> |
| In reply to | #35759 |
On 1/12/2015 4:28 PM, hughaguilar96@gmail.com wrote: > On Sunday, January 11, 2015 at 5:45:09 PM UTC-7, Elizabeth D. Rather wrote: ... >> It would have been difficult to "declare SwiftFORTH to be the standard" >> in 1993, since it wasn't introduced until 1997. >> >> Instead, SwiftFORTH was designed to comply with Forth94. > > I had assumed that SwiftForth was the reference compiler for ANS-Forth. You are saying that there was no reference compiler, and that the ANS-Forth standard was published without being tested in a reference compiler (it would be 4 years after the ANS-Forth standard was written in stone before you managed to write an ANS-Forth compiler, SwiftForth, and your effort was a bug-ridden mess). > > This is actually much much MUCH worse than using a commercial compiler as the reference compiler, which is what I had been assuming. The correct thing to do, is to write an open-source reference compiler for the new standard, and allow it to be tested by the community BEFORE the standard is written in stone, in order to make sure that the standard makes sense to sober people. > > If the ANS-Forth standard was published without ever being tested, that would explain why there are so many bugs. For example, if anybody had used LOCALS| even once, they would have noticed that the parameters are backwards --- that is a pretty gross blunder, that can only come from just not testing at all. ANS Forth was developed over a period of 6 years. The development team included at least 3 vendors (membership varied through the years) and several other independent system implementers, plus quite a few users. They all implemented and tested all technical changes, and reported results. The team decided against publishing an official "reference implementation" because inevitably implementation decisions made in such a development become accepted as norms, and the team didn't want to constrain future implementations in this way. The norm is behavior (semantics), not implementation strategy. Cheers (a standard friendly greeting), Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-12 20:55 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <ad071362-3b4f-4bac-9b70-17234ffd2051@googlegroups.com> |
| In reply to | #35761 |
On Monday, January 12, 2015 at 8:12:48 PM UTC-7, Elizabeth D Rather wrote: > ANS Forth was developed over a period of 6 years. The development team > included at least 3 vendors (membership varied through the years) and > several other independent system implementers, plus quite a few users. > They all implemented and tested all technical changes, and reported > results. What did they implement and test these technical changes on, if there was no reference compiler? They just used a variety of closed-source commercial compilers, so no member of this "development team" could duplicate another team member's test --- you end up with a mish-mash of features that have never been tested together. This mish-mash results in clashes between features, such as locals and >R data: (13.3.3) - Locals shall not be declared until values previously placed on the return stack within the definition have been removed; - After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack; A feature-clash like this is very difficult to explain to Forth students --- this is why nobody is volunteering to be a Forth student! --- Forth is dying, because ANS-Forth is a head-on collision of ignorance and arrogance. > The team decided against publishing an official "reference > implementation" because inevitably implementation decisions made in such > a development become accepted as norms, and the team didn't want to > constrain future implementations in this way. The norm is behavior > (semantics), not implementation strategy. Certainly, it is worthwhile for the standard to standardize behavior rather than implementation. It is well known that the major problem with Forth-83 was that it assumed implementation details (such as ITC) that should have been abstracted out. The problem is that you don't know the difference between behavior and implementation. The ANS-Forth document often says behavior "may be this or may be that" --- resulting in total confusion for the user! --- but you mistakenly believe that this is implementation strategy, despite the fact that it affects the users. (3.2.3.2.) The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. Using the data-stack as the control-flow stack is not an "implementation strategy" decision. This is behavior! The brave ANS-Forth programmer may write code that assumes the control-flow data has its own stack --- this is the best-case scenario in which the programmer can pass data into colon words at compile-time. The programmer puts data on the data-stack prior to the colon, and uses this data inside of the colon-word (typically with LITERAL). This code is not going to work if the programmer switches to another ANS-Forth compliant that uses the data-stack as the control-flow stack --- when the programmer tries to use his data (typically with LITERAL), he likely finds control-flow data on top of his data, and he uses that instead --- chaos will result! The big problem with ANS-Forth, is that it doesn't standardize behavior, and so various compilers (all advertised as being ANS-Forth standard) will behave differently --- code written on one ANS-Forth compiler may or may not work on another ANS-Forth compiler. ANS-Forth is a standard that doesn't standardize. As Anton says: "A system that would tell us all non-standard usages would be nice, but we don't have that. For now the solution is to test on as many systems as possible." Effectively, it is up to the programmer to figure out what the worst-case scenario is --- this is what I did throughout the novice package, which is why the novice package works under every ANS-Forth compiler that I have tested (SwiftForth, Gforth, Win32Forth and VFX), and is also why a lot of the novice-package code is painfully contorted. Effectively, the worst-case has to be assumed to be the standard, but the ANS-Forth document is so wishy-washy that nobody can be sure what the worst-case is, and so all they can do is test their program on as many systems as possible and hope for the best. Even if their program works on all ANS-Forth system available though, there is no guarantee that it will work on future ANS-Forth systems that become available, or even on future releases of the ANS-Forth systems already tested --- but all of those incompatible Forths claim to be ANS-Forth compliant and can prove that there is a valid interpretation of the ANS-Forth standards document that they conform to. ANS-Forth is a complete failure as a standard! Programs aren't portable from one ANS-Forth compiler to another, and almost everybody is gripped by vendor lock-in, which is what the standard was supposed to prevent. This is your fault, because you were the chair of the ANS-Forth committee --- who are we supposed to blame other than you? --- you are the Joseph Hazelwood of ANS-Forth! BTW: This is the first time that you have responded to one of my posts since 2009 --- does this mean that I don't suck any more?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-01-13 03:48 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <734ef202-d3c4-48c8-885b-5a412c98c755@googlegroups.com> |
| In reply to | #35766 |
On Tuesday, 13 January 2015 04:55:08 UTC, hughag...@gmail.com wrote: > (3.2.3.2.) > The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. > Yep. This is a total mess. > Using the data-stack as the control-flow stack is not an "implementation strategy" decision. This is behavior! Here here! >The brave ANS-Forth programmer may write code that assumes the control-flow data has its own stack --- this is the best-case scenario in which the programmer can pass data into colon words at compile-time. The programmer puts data on the data-stack prior to the colon, and uses this data inside of the colon-word (typically with LITERAL). This code is not going to work if the programmer switches to another ANS-Forth compliant that uses the data-stack as the control-flow stack --- when the programmer tries to use his data (typically with LITERAL), he likely finds control-flow data on top of his data, and he uses that instead --- chaos will result! Here here! > > The big problem with ANS-Forth, is that it doesn't standardize behavior, and so various compilers (all advertised as being ANS-Forth standard) will behave differently --- code written on one ANS-Forth compiler may or may not work on another ANS-Forth compiler. ANS-Forth is a standard that doesn't standardize. As Anton says: "A system that would tell us all non-standard usages would be nice, but we don't have that. For now the solution is to test on as many systems as possible." Effectively, it is up to the programmer to figure out what the worst-case scenario is --- this is what I did throughout the novice package, which is why the novice package works under every ANS-Forth compiler that I have tested (SwiftForth, Gforth, Win32Forth and VFX), and is also why a lot of the novice-package code is painfully contorted. Effectively, the worst-case has to be assumed to be the standard, but the ANS-Forth document is so wishy-washy that nobody can be sure what the worst-case is, and so all they can do is test their program on as many systems as possible and hope for the best. Even if their program works on all ANS-Forth system available though, there is no guarantee that it will work on future ANS-Forth systems that become available, or even on future releases of the ANS-Forth systems already tested --- but all of those incompatible Forths claim to be ANS-Forth compliant and can prove that there is a valid interpretation of the ANS-Forth standards document that they conform to. Bravo. Totally agree. It's possible to write a totally standard-compliant Forth program that follows all the guidance in the ANS standard, it will run on system A, and not on System B, where both systems A and B claim to be compliant. That's a failure IMO. It's a worse situation than we find with the C standard (admitedly, I'm no expert in C or the C standard) - from what I've gathered (mostly through following discussions/observations on C compliance between Anton, Andrew, and Bernd, the issues that arise with respect of portability of C programs seem to more centered ambiguity in the standard. That can be fixed (if there's a will) with appropriate clarifications and modification to the standard text. The ANS Forth standard suffers from a more serious problem (IMO): Failure to prescribe. In fact, as witnessed by section 3.2.3.2 above, it goes out of its way to leave the doors so wide open that you could drive a coach and horses through them! I think it's fairly obvious that the standard evolved in the way that it did for two reasons: 1) A desire to carry forward as much backwards compatibility with Forth-83 as possible (perfectly reasonable). 2) Commercial intertia. Vendors and implementors wanted to be able to stamp their systems as ANS compatible with the minimum (preferably none) of work. There's good reasons for this: They don't want to introduce backwards compatibility problems with previous versions of their products - it hurts their customers. Whilst 2 is understandable, I think it's a shame. With hindsight, it would have been better to draw a line in the sand, and declare ANS a completely "forward looking" standard, rather than a backward looking standard. It would have given the freedom to throw away any chains and shackles born from a desire to remain compatible with existing standards and therefore given the committee a 'clean sheet'. A clean-sheet gives much more freedom to explicitly prescribe. Of course, in real-life, I'm sure it wouldn't have been as simple as that. Commercial intertia would have played a big role in people having vested interests in the standard being written in a particulay way. I can only imagine the politics that would have been in play! I would not have like to have been the chairperson on that committee, for sure! > > ANS-Forth is a complete failure as a standard! Programs aren't portable from one ANS-Forth compiler to another, and almost everybody is gripped by vendor lock-in, which is what the standard was supposed to prevent. This is your fault, because you were the chair of the ANS-Forth committee --- who are we supposed to blame other than you? --- you are the Joseph Hazelwood of ANS-Forth! > > BTW: This is the first time that you have responded to one of my posts since 2009 --- does this mean that I don't suck any more?
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-13 06:05 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <fabf9697-d936-416a-b572-ab8298d27ab7@googlegroups.com> |
| In reply to | #35774 |
on 13/01/2015 11:48:28, Mark Wills wrote: > On Tuesday, 13 January 2015 04:55:08 UTC, hughag...@gmail.com wrote: >> (3.2.3.2.) >> The control-flow stack may, but need not, physically exist in an implemen > tation. If it does exist, it may be, but need not be, implemented > using the data stack. The format of the control-flow stack is > implementation defined . Since the control-flow stack may be > implemented using the data stack, ite ms placed on the data stack are > unavailable to a program after items are pl aced on the control-flow > stack and remain unavailable until the control-flo w stack items are > > removed. >> > removed. > > Yep. This is a total mess. Point out the mess. It seems pretty clear to me. If you don't understand it, I'd suggest that you need to think about these questions. What is the control flow stack? What words (potentially) use it? When & how is it used? How do we standardise control flow? Do we always need a control flow stack? . If no, does it need to exist? . If yes, what forces us to require it? Can the requirement be relaxed? Does the control flow stack need to be a separate stack from the data stack? . If no, should the standard force it to be so? What advantages does that have? . If yes, what causes this implementation requirement? Can the requirement be relaxed? If either you or Hugh want to tackle this, be my guest. You will find it hard to do specify, and there will be a huge amount of resistance from Forth system developers to over-specification, prescribing or proscribing, forcing implementation specifics, changing existing practice and so on. > >> Using the data-stack as the control-flow stack is not an "implementation > strategy" decision. This is behavior! > > Here here! This I find confusing. What exactly are you saying "here here!" [sic] to? Hugh saying "behaviour" or "not an implementation strategy"? What does the sentence mean that you're applauding? > >>The brave ANS-Forth programmer may write code that assumes the control-flo > w data has its own stack --- this is the best-case scenario in which > the pr ogrammer can pass data into colon words at compile-time. The > programmer put s data on the data-stack prior to the colon, and uses > this data inside of t he colon-word (typically with LITERAL). This > code is not going to work if t he programmer switches to another > ANS-Forth compliant that uses the data-st ack as the control-flow > stack --- when the programmer tries to use his data (typically with > LITERAL), he likely finds control-flow data on top of his data, and he > uses that instead --- chaos will result! > > Here here! (It's "hear hear".) > >> >> The big problem with ANS-Forth, is that it doesn't standardize behavior, > and so various compilers (all advertised as being ANS-Forth standard) > will behave differently --- code written on one ANS-Forth compiler may > or may no t work on another ANS-Forth compiler. ANS-Forth is a > standard that doesn't standardize. As Anton says: "A system that would > tell us all non-standard u sages would be nice, but we don't have > that. For now the solution is to tes t on as many systems as > possible." Effectively, it is up to the programmer to figure out what > the worst-case scenario is --- this is what I did throug hout the > novice package, which is why the novice package works under every > ANS-Forth compiler that I have tested (SwiftForth, Gforth, Win32Forth > and V FX), and is also why a lot of the novice-package code is > painfully contorte d. Effectively, the worst-case has to be assumed to > be the standard, but th e ANS-Forth document is so wishy-washy that > nobody can be sure what the wor st-case is, and so all they can do is > test their program on as many systems as possible and hope for the > best. Even if their program works on all ANS- Forth system available > though, there is no guarantee that it will work on f uture ANS-Forth > systems that become available, or even on future releases o f the > ANS-Forth systems already tested --- but all of those incompatible Fo > rths claim to be ANS-Forth compliant and can prove that there is a > valid in terpretation of the ANS-Forth standards document that they > conform to. > > Bravo. Totally agree. It's possible to write a totally > standard-compliant Forth program that follows all the guidance in the > ANS standard, it will run on system A, and not on System B, where both > systems A and B claim to be compliant. That's a failure IMO. It's a If you write a standard-compliant Forth program, then any system that can't run it isn't standard compliant. What on earth are you and Hugh on about? > worse situation than we find with the C standard (admitedly, I'm no > expert in C or the C standard) - fro m > what I've gathered (mostly through following discussions/observations > on C compliance between Anton, Andrew, and Bernd, the issues that > arise with respect of portability of C programs seem to more centered > ambiguity in the standard. That can be fixed (if there's a will) with > appropriate clarificat ions > and modification to the standard text. The ANS Forth standard suffers > from a more serious problem (IMO): Failure to prescribe. In fact, as > witnessed by section 3.2.3.2 above, it goes out of its way to leave > the doors so wide open that you could drive a coach and horses through > them! Sigh. Callow youth. > > I think it's fairly obvious that the standard evolved in the way that > it di d > for two reasons: > > 1) A desire to carry forward as much backwards compatibility with > Forth-83 as possible (perfectly reasonable). > > 2) Commercial intertia. Vendors and implementors wanted to be able to > stamp their systems as ANS compatible with the minimum (preferably > none) of work. There's good reasons for this: They don't want to > introduce backwards compatibility problems with previous versions of > their products - it hurts their customers. > Interoperability. Miss that at your peril. It's what drives the evolution of a standard. That and money. > Whilst 2 is understandable, I think it's a shame. With hindsight, it > would have been better to draw a line in the sand, and declare ANS a > completely "forward looking" standard, rather than a backward looking > standard. It would have given the freedom to throw away any chains and > shackles born fro m > a desire to remain compatible with existing standards and therefore > given > > the committee a 'clean sheet'. A clean-sheet gives much more freedom > to explicitly prescribe. > > Of course, in real-life, I'm sure it wouldn't have been as simple as > that. Commercial intertia would have played a big role in people > having vested interests in the standard being written in a particulay > way. I can only imagine the politics that would have been in play! People who know what they're doing hate clean sheet standards. The IESG (Internet Engineering Standards Group) says explicitly; don't make IESG evaluate clean-sheet proposals with no experience. "The requirements for Draft Standard include multiple interoperable implementations to demonstrate document clarity and a requirement for each feature to be implemented to eliminate unused features." And that's just for a *draft* standard. > > I would not have like to have been the chairperson on that committee, > for sure! Elizabeth Rather fulfilled what is often an unrewarding task. Herding cats is easier.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-01-13 06:34 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <0df2f9c6-dc36-4e89-9193-3f8016abbe37@googlegroups.com> |
| In reply to | #35780 |
On Tuesday, January 13, 2015 at 8:05:07 AM UTC-6, Alex McDonald wrote: > If you write a standard-compliant Forth program, then any system that > can't run it isn't standard compliant. What on earth are you and Hugh on > about? The following program is a standard Forth program that has an environmental dependency. It won't run (or won't run as expected) on standard compliant Forth systems that have 16-bit cells. \ An ANS Forth Program with Environmental Dependencies \ Requiring HEX and \ from the Core Extensions word set \ \ * cells must be at least 32 bits. hex 80018001 . Documenting your dependencies is part of how you turn a random Forth program into a standard program. But Hugh's argument here is such that SwiftForth and gforth's varying implementation of non-standard words (SF adds a trailing zero byte to words like PLACE; gforth does not) is 'cruel vendor lock-in' and an example of the failure of ANS Forth. Hugh's argument is such that gforth's providing SAVE-MEM is vendor lock-in, because gosh it's documented and you might use it and then your program might fail with SAVE-MEM ? on another system! This is madness. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-13 06:51 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <647928f0-04b9-4583-b9eb-7d04c1a69476@googlegroups.com> |
| In reply to | #35782 |
on 13/01/2015 14:34:22, Julian Fondren wrote: > > On Tuesday, January 13, 2015 at 8:05:07 AM UTC-6, Alex McDonald wrote: >> If you write a standard-compliant Forth program, then any system that >> can't run it isn't standard compliant. What on earth are you and Hugh on >> about? > > The following program is a standard Forth program that has an > environmental dependency. It won't run (or won't run as expected) on > standard compliant Forth systems that have 16-bit cells. > > \ An ANS Forth Program with Environmental Dependencies > \ Requiring HEX and \ from the Core Extensions word set > \ > \ * cells must be at least 32 bits. > hex 80018001 . > > Documenting your dependencies is part of how you turn a random Forth > program into a standard program. Good point, and one I had forgotten. Although it's not the crux of Kim Jong Hugh's argument from what I can see. > > But Hugh's argument here is such that SwiftForth and gforth's varying > implementation of non-standard words (SF adds a trailing zero byte to > words like PLACE; gforth does not) is 'cruel vendor lock-in' and an > example of the failure of ANS Forth. > > Hugh's argument is such that gforth's providing SAVE-MEM is vendor > lock-in, because gosh it's documented and you might use it and then > your program might fail with SAVE-MEM ? on another system! > > This is madness. > The supreme leader of the Democratic People's Republic of Straight Forthistan, No Poofters Allowed is not on any standards groups I'm on, which is a relief.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-01-13 08:03 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <f1a17018-1d42-4401-81e0-5d63177951f2@googlegroups.com> |
| In reply to | #35782 |
On Tuesday, 13 January 2015 14:34:19 UTC, Julian Fondren wrote: > On Tuesday, January 13, 2015 at 8:05:07 AM UTC-6, Alex McDonald wrote: > > If you write a standard-compliant Forth program, then any system that > > can't run it isn't standard compliant. What on earth are you and Hugh on > > about? > > The following program is a standard Forth program that has an > environmental dependency. It won't run (or won't run as expected) on > standard compliant Forth systems that have 16-bit cells. > > \ An ANS Forth Program with Environmental Dependencies > \ Requiring HEX and \ from the Core Extensions word set > \ > \ * cells must be at least 32 bits. > hex 80018001 . > > Documenting your dependencies is part of how you turn a random Forth > program into a standard program. > > But Hugh's argument here is such that SwiftForth and gforth's varying > implementation of non-standard words (SF adds a trailing zero byte to > words like PLACE; gforth does not) is 'cruel vendor lock-in' and an > example of the failure of ANS Forth. > > Hugh's argument is such that gforth's providing SAVE-MEM is vendor > lock-in, because gosh it's documented and you might use it and then > your program might fail with SAVE-MEM ? on another system! > > This is madness. > > > -- Julian Hugh is simply pointing that one may develop a completely compliant Forth program, and it may run on one system, and not on another, yet both systems are actually 100% compliant with the standard. So, the code is compliant, the host systems are compliant, yet the code fails on one of the systems. Or maybe it fails both of the systems. For all practical purposes, when this happens, what has been "standardised"?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-13 19:18 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2c0af39f-6219-4418-bbee-d039caffa050@googlegroups.com> |
| In reply to | #35782 |
On Tuesday, January 13, 2015 at 7:34:19 AM UTC-7, Julian Fondren wrote: > The following program is a standard Forth program that has an > environmental dependency. It won't run (or won't run as expected) on > standard compliant Forth systems that have 16-bit cells. > > \ * cells must be at least 32 bits. > hex 80018001 . > > Documenting your dependencies is part of how you turn a random Forth > program into a standard program. In my own desktop-computer language, I'm requiring the cell size to be 64-bits, so we can get rid of this chronic problem --- this will make mathematical programs much more portable, as almost all of them depend upon some cell size. In the micro-controller language however, I will still support having various cell sizes similar to what ANS-Forth does now --- what this actually means in practice, is that there will be a 16-bit version of the language, and a 32-bit version of the language (and maybe a 24-bit version if somebody wants to support the eZ80) --- these versions of the language are actually distinct languages because most programs can't be ported directly from one to the other. Every time that the programmer has to document a dependency, the language has effectively forked --- ANS-Forth requires so many choices to be made, each of which has to be documented, that it is really a tree of loosely related languages rather than a single language. If there is only one choice that has to be made (such as 16-bit or 32-bit), then there are two related languages. If there are two choices that have to be made, then there are four related languages. This is called exponential growth --- computer programmers, of all people, should be familiar with the concept --- don't let exponential growth get out of control!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-01-13 08:26 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2dd6fab0-081b-47e4-b045-ffbaa01d19cb@googlegroups.com> |
| In reply to | #35780 |
On Tuesday, 13 January 2015 14:05:07 UTC, Alex McDonald wrote: > on 13/01/2015 11:48:28, Mark Wills wrote: > > On Tuesday, 13 January 2015 04:55:08 UTC, hughag...@gmail.com wrote: > >> (3.2.3.2.) > >> The control-flow stack may, but need not, physically exist in an implemen > > tation. If it does exist, it may be, but need not be, implemented > > using the data stack. The format of the control-flow stack is > > implementation defined . Since the control-flow stack may be > > implemented using the data stack, ite ms placed on the data stack are > > unavailable to a program after items are pl aced on the control-flow > > stack and remain unavailable until the control-flo w stack items are > > > removed. > >> > > removed. > > > > Yep. This is a total mess. > > Point out the mess. It seems pretty clear to me. If you don't understand > it, I'd suggest that you need to think about these questions. I understand. It's just that it's too permissive. There's one could write compliant code the runs on one system, but not on another, because the standard has granted what amounts to (in this particular case) too much freedom to the implementor. > > What is the control flow stack? > What words (potentially) use it? > When & how is it used? > > How do we standardise control flow? > > Do we always need a control flow stack? > . If no, does it need to exist? > . If yes, what forces us to require it? Can the requirement be relaxed? > Does the control flow stack need to be a separate stack from the data > stack? . If no, should the standard force it to be so? What advantages > does that have? . If yes, what causes this implementation requirement? > Can the requirement be relaxed? > > If either you or Hugh want to tackle this, be my guest. You will find it > hard to do specify, and there will be a huge amount of resistance from > Forth system developers to over-specification, prescribing or > proscribing, forcing implementation specifics, changing existing practice > and so on. > > > > >> Using the data-stack as the control-flow stack is not an "implementation > > strategy" decision. This is behavior! > > > > Here here! > > This I find confusing. What exactly are you saying "here here!" [sic] to? > Hugh saying "behaviour" or "not an implementation strategy"? What does > the sentence mean that you're applauding? > > I'm agreeing with Hugh. More specifically, deciding on a particular implementation strategy absolutely *will* lead to a particular *behaviour*. If your "control flow stack" is the data stack, then you can't pass data into a colon defintion (see Hugh's specific objection for the details) because the system *may* have put non-specific (colon-sys stuff) entries on the stack, above your data. My system might work like that. Yours may not. Both would be compliant. The coder pulls his hair out. > > > >>The brave ANS-Forth programmer may write code that assumes the control-flo > > w data has its own stack --- this is the best-case scenario in which > > the pr ogrammer can pass data into colon words at compile-time. The > > programmer put s data on the data-stack prior to the colon, and uses > > this data inside of t he colon-word (typically with LITERAL). This > > code is not going to work if t he programmer switches to another > > ANS-Forth compliant that uses the data-st ack as the control-flow > > stack --- when the programmer tries to use his data (typically with > > LITERAL), he likely finds control-flow data on top of his data, and he > > uses that instead --- chaos will result! > > > > Here here! > > (It's "hear hear".) > (Thanks, I always wondered!) ;-) > > > >> > >> The big problem with ANS-Forth, is that it doesn't standardize behavior, > > and so various compilers (all advertised as being ANS-Forth standard) > > will behave differently --- code written on one ANS-Forth compiler may > > or may no t work on another ANS-Forth compiler. ANS-Forth is a > > standard that doesn't standardize. As Anton says: "A system that would > > tell us all non-standard u sages would be nice, but we don't have > > that. For now the solution is to tes t on as many systems as > > possible." Effectively, it is up to the programmer to figure out what > > the worst-case scenario is --- this is what I did throug hout the > > novice package, which is why the novice package works under every > > ANS-Forth compiler that I have tested (SwiftForth, Gforth, Win32Forth > > and V FX), and is also why a lot of the novice-package code is > > painfully contorte d. Effectively, the worst-case has to be assumed to > > be the standard, but th e ANS-Forth document is so wishy-washy that > > nobody can be sure what the wor st-case is, and so all they can do is > > test their program on as many systems as possible and hope for the > > best. Even if their program works on all ANS- Forth system available > > though, there is no guarantee that it will work on f uture ANS-Forth > > systems that become available, or even on future releases o f the > > ANS-Forth systems already tested --- but all of those incompatible Fo > > rths claim to be ANS-Forth compliant and can prove that there is a > > valid in terpretation of the ANS-Forth standards document that they > > conform to. > > > > Bravo. Totally agree. It's possible to write a totally > > standard-compliant Forth program that follows all the guidance in the > > ANS standard, it will run on system A, and not on System B, where both > > systems A and B claim to be compliant. That's a failure IMO. It's a > > If you write a standard-compliant Forth program, then any system that > can't run it isn't standard compliant. What on earth are you and Hugh on > about? > Incorrect. See 3.2.3.2. It's just not the case. > > worse situation than we find with the C standard (admitedly, I'm no > > expert in C or the C standard) - fro m > > what I've gathered (mostly through following discussions/observations > > on C compliance between Anton, Andrew, and Bernd, the issues that > > arise with respect of portability of C programs seem to more centered > > ambiguity in the standard. That can be fixed (if there's a will) with > > appropriate clarificat ions > > and modification to the standard text. The ANS Forth standard suffers > > from a more serious problem (IMO): Failure to prescribe. In fact, as > > witnessed by section 3.2.3.2 above, it goes out of its way to leave > > the doors so wide open that you could drive a coach and horses through > > them! > > Sigh. Callow youth. Perhaps. I'm trying to reflect on why the standard is like it is in as fair a manner as I can. I did state, and have stated before that I'm sure it's a terribly miserable, un-rewarding process to ratify a standard. > > > > > I think it's fairly obvious that the standard evolved in the way that > > it di d > > for two reasons: > > > > 1) A desire to carry forward as much backwards compatibility with > > Forth-83 as possible (perfectly reasonable). > > > > 2) Commercial intertia. Vendors and implementors wanted to be able to > > stamp their systems as ANS compatible with the minimum (preferably > > none) of work. There's good reasons for this: They don't want to > > introduce backwards compatibility problems with previous versions of > > their products - it hurts their customers. > > > > Interoperability. Miss that at your peril. It's what drives the evolution > of a standard. That and money. I agree. Where we disagree is the degree to which the ANS standard guarantees interoperability. > > > Whilst 2 is understandable, I think it's a shame. With hindsight, it > > would have been better to draw a line in the sand, and declare ANS a > > completely "forward looking" standard, rather than a backward looking > > standard. It would have given the freedom to throw away any chains and > > shackles born fro m > > a desire to remain compatible with existing standards and therefore > > given > > > > the committee a 'clean sheet'. A clean-sheet gives much more freedom > > to explicitly prescribe. > > > > Of course, in real-life, I'm sure it wouldn't have been as simple as > > that. Commercial intertia would have played a big role in people > > having vested interests in the standard being written in a particulay > > way. I can only imagine the politics that would have been in play! > > People who know what they're doing hate clean sheet standards. The IESG > (Internet Engineering Standards Group) says explicitly; don't make IESG > evaluate clean-sheet proposals with no experience. "The requirements for > Draft Standard include multiple interoperable implementations to > demonstrate document clarity and a requirement for each feature to be > implemented to eliminate unused features." And that's just for a *draft* > standard. > I find this view rather strange. I'm not saying you're wrong. I'm actually sure your observation is correct. However, it's not really necessary to continue to evolve a standard. A clean sheet does allow solutions to issues discovered in a previous standard to be offered, without fear of breaking compatibility, because there's no requirement to be backward compatible. It's a new standard. The old/previous standard doesn't vanish in a puff of smoke when the new one is published. They can live side-by-side. Darwinian theory will prevail: The best standard will eventually win and other will die off. It might be that the new standard doesn't gain traction because of the inertia of the old one. C'est la vie. Perhaps the new standard will gain traction over the old one because it fixes problems in the old one. C'est la vie. > > > > I would not have like to have been the chairperson on that committee, > > for sure! > > Elizabeth Rather fulfilled what is often an unrewarding task. Herding > cats is easier. I'm sure that's true. Hat's off to the entire committee. A standard is better than no standard. That's worth bearing in mind, too.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-01-13 09:54 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <a812af65-28ca-42a2-ada3-1bbf4ca78191@googlegroups.com> |
| In reply to | #35787 |
on 13/01/2015 16:26:06, Mark Wills wrote: > On Tuesday, 13 January 2015 14:05:07 UTC, Alex McDonald wrote: >> People who know what they're doing hate clean sheet standards. The IESG >> (Internet Engineering Standards Group) says explicitly; don't make IESG >> evaluate clean-sheet proposals with no experience. "The requirements for >> Draft Standard include multiple interoperable implementations to >> demonstrate document clarity and a requirement for each feature to be >> implemented to eliminate unused features." And that's just for a *draft* >> standard. >> > > I find this view rather strange. I'm not saying you're wrong. I'm > actually sure your observation is correct. However, it's not really > necessary to continue to evolve a standard. A clean sheet does allow > solutions to issues discovered in a previous standard to be offered, > without fear of breaking compatibility, because there's no requirement > to be backward compatible. It's a new standard. The old/previous > standard doesn't vanish in a puff of smoke when the new one is > published. They can live side-by-side. Darwinian theory will prevail: > The best standard will eventually win and other will die off. It might > be that the new standard doesn't gain traction because of the inertia > of the old one. C'est la vie. Perhaps the new standard will gain > traction over the old one because it fixes problems in the old one. > C'est la vie. The flaw in this whole argument is that standards don't compete. Products compete.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-01-13 17:35 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <2015Jan13.183537@mips.complang.tuwien.ac.at> |
| In reply to | #35787 |
Mark Wills <markwills1970@gmail.com> writes:
>On Tuesday, 13 January 2015 14:05:07 UTC, Alex McDonald wrote:
>> on 13/01/2015 11:48:28, Mark Wills wrote:
>> > On Tuesday, 13 January 2015 04:55:08 UTC, hughag...@gmail.com wrote:
>> >> (3.2.3.2.)
>> >> The control-flow stack may, but need not, physically exist in an implemen
>> > tation. If it does exist, it may be, but need not be, implemented
>> > using the data stack. The format of the control-flow stack is
>> > implementation defined . Since the control-flow stack may be
>> > implemented using the data stack, ite ms placed on the data stack are
>> > unavailable to a program after items are pl aced on the control-flow
>> > stack and remain unavailable until the control-flo w stack items are
>> > > removed.
>> >>
>> > removed.
>> >
>> > Yep. This is a total mess.
>>
>> Point out the mess. It seems pretty clear to me. If you don't understand
>> it, I'd suggest that you need to think about these questions.
>
>I understand. It's just that it's too permissive. There's one could write
>compliant code the runs on one system, but not on another, because the
>standard has granted what amounts to (in this particular case) too much
>freedom to the implementor.
What compliant code could one write? Give an example.
Concerning the control flow stack, the standard is quite explicit that
control flow stack items may reside on the data stack or on a separate
stack, and may be of any size, so code that relies on a particular
location and size of control-flow stack items is not compliant.
And in this particular case a number of systems even detect and report
it in many cases if your program is not compliant in this respect.
E.g., Gforth says:
5 : bla literal ;
*the terminal*:1: unstructured
5 : bla literal ;
^
You might want to wish for a more explicit description of compliant
programs instead of having to infer it from the description of what
system implementations are allowed, but that would be a redundant specification, which leads to potential problems:
1) If the explicit description is too wide, it makes programs
compliant that don't work on compliant systems, i.e., exactly the
problem you are worried about.
2) If the explicit description is too narrow, it makes programs
non-compliant that are compliant in the current standard. E.g.,
someone pointed out to the Forth200x committee that you can access
stuff on the data stack below a control-flow stack item with the help
of DEPTH and PICK/ROLL. If we had explicitly said that a compliant
program cannot access data stack items below a control-flow stack
item, it would have ruled that out. I don't know if that's really a
useful technique or a mere curiosity, but anyway, it's there.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-01-13 18:19 -0800 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <0f1a1663-6ff1-4ba2-a40e-ab5b6bf951af@googlegroups.com> |
| In reply to | #35789 |
On Tuesday, January 13, 2015 at 11:06:02 AM UTC-7, Anton Ertl wrote: > 2) If the explicit description is too narrow, it makes programs > non-compliant that are compliant in the current standard. This is totally not true!!! Lets go back to the infamous 3.2.3.2.: The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. This means that X ANS-Forth compiler can use the data-stack as the control-flow stack, and Y ANS-Forth compiler can have a control-flow stack that is independent of the data-stack or any other stack, and both X and Y are ANS-Forth compliant. Hypothetically speaking, lets say that we have a new standard with a more narrow definition: "The control-flow stack must be its own stack, independent of the data-stack or any other stack." The current users of X and Y are going to respond like this: X: "Yay! Now my programs will work on ALL standard-compliant compilers, not just those that currently have an independent control-flow stack." Y: "Whatever. My programs have always worked on all standard-compliant compiler, and they will continue to do so." Tightening up the standard actually makes MORE legacy code become fully standard-compliant (by "fully" I mean, that they will work on ALL standard-compliant compilers) --- this truth is the exact opposite of what you said. The compiler-writers of the X and Y compilers are going to say: X: "Whatever. I'm already there, so this doesn't have any direct affect on me." Y. "Drat! Now I'll have to spend time in rewriting my compiler to make the control-flow stack its own stack --- there goes the weekend!" Both X and Y compiler-writers should be okay with the change though, as an improved standard will attract more users, and a rising tide lifts all boats.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-01-14 21:03 +0000 |
| Subject | Re: Standards (was FORTH on the ...) |
| Message-ID | <m96lj6$hr6$1@dont-email.me> |
| In reply to | #35798 |
hughaguilar96@gmail.com wrote: > Tightening up the standard actually makes > MORE legacy code become fully > standard-compliant (by "fully" I mean, that > they will work on ALL standard-compliant > compilers) --- this truth is the exact > opposite of what you said. > > The compiler-writers of the X and Y > compilers are going to say: X: "Whatever. > I'm already there, so this doesn't have any > direct affect on me." Y. "Drat! Now I'll > have to spend time in rewriting my compiler > to make the control-flow stack its own stack > --- there goes the weekend!" Anton wants to keep things easy for meciocre implementors of Forth. He doesn't want the harridan to kick him out of the committee. He doesn't want to make things easy for users of Forth.
[toc] | [prev] | [next] | [standalone]
Page 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web