Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27495 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2013-12-28 23:39 -0800 |
| Last post | 2014-01-03 14:52 +0000 |
| Articles | 20 on this page of 330 — 25 participants |
Back to article view | Back to comp.lang.forth
PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 23:39 -0800
Re: PICK changed from 1-based to 0-based? Elizabeth D Rather <erather@forth.com> - 2013-12-28 21:52 -1000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 11:28 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-29 23:12 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:45 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:57 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-30 00:25 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:29 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-01 14:18 +0000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:46 +0100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:26 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 13:22 +1100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:54 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 10:57 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 14:07 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:22 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 09:06 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:10 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 11:49 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:14 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:35 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-05 11:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 06:15 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 15:11 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 10:07 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 21:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-06 04:44 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-06 21:51 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-06 22:41 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 03:29 +0100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-01-07 11:48 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-07 12:58 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 15:13 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-07 10:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-08 02:20 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 14:13 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-09 23:19 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 09:02 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 13:28 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 09:05 +0000
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-14 04:05 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 12:36 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 11:37 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 17:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-11 01:40 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 11:21 +1100
Re: PICK changed from 1-based to 0-based? Coos Haak <chforth@hccnet.nl> - 2014-01-13 01:50 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 12:05 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:19 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:36 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-12 19:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 17:09 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 17:06 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:13 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 18:59 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 12:54 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:19 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:32 -0500
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:46 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-30 18:37 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-31 11:53 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:43 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 16:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:32 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:26 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:55 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:45 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-06 22:15 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 08:39 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-05 12:53 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 13:45 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:17 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:43 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:53 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-01 23:57 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-01 13:19 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 19:48 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 19:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 15:44 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:56 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-02 15:43 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 15:34 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:14 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 17:49 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 12:03 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 10:31 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 19:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 09:56 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:18 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-04 12:39 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 21:43 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 13:45 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 23:10 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 15:41 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:05 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:21 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 06:46 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:33 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-07 08:44 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 14:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:41 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:14 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 18:41 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:09 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 20:00 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 12:45 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 00:16 +0100
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:34 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:41 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 23:12 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 23:04 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 22:08 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 02:16 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:19 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:04 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:27 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 11:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 12:47 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 13:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 14:24 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:53 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:50 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:08 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:32 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 20:49 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:10 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:37 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-07 08:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:24 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:50 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:28 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-08 16:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:39 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:28 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:27 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:42 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:41 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:44 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:35 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-10 00:20 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 05:22 -0600
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-10 03:48 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 09:31 -0600
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:40 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:54 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 03:41 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-11 13:33 +0000
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 11:44 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 10:40 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 04:11 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 13:31 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 07:52 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 02:57 -0600
chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 03:12 -0600
Re: chipFORTH Paul Rubin <no.email@nospam.invalid> - 2014-01-12 08:43 -0800
Re: chipFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 10:40 -0600
Re: chipFORTH albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 18:00 +0000
Re: chipFORTH Alex McDonald <blog@rivadpm.com> - 2014-01-12 11:18 -0800
Re: chipFORTH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:03 +0000
Re: chipFORTH "Alex McDonald" <blog@rivadpm.com> - 2014-01-13 17:21 +0000
Re: chipFORTH stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:10 +0000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:28 -0500
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Elizabeth D Rather <erather@forth.com> - 2014-01-12 21:39 -1000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 03:16 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 11:38 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 07:46 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 15:46 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 10:45 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:05 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 20:53 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 03:41 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-14 13:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 17:53 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-14 17:35 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 08:23 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 13:19 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-14 12:31 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 21:37 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 16:12 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 12:18 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-15 04:19 +0100
DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-15 17:52 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-15 21:56 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:30 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-17 12:44 +0100
Re: DOES> and flash oh2aun@gmail.com - 2014-01-17 08:05 -0800
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-17 16:43 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-17 20:37 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 04:40 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 11:56 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 10:54 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:36 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 12:17 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 18:23 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:00 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 20:24 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:05 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 23:12 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 03:38 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 14:03 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:17 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 15:31 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 19:48 +0100
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 18:11 +0100
Re: DOES> and flash Coos Haak <chforth@hccnet.nl> - 2014-01-19 01:12 +0100
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:53 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-20 11:32 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 02:02 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-16 07:19 +0100
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-16 00:22 -0800
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 15:38 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-20 09:45 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:33 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 16:09 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 03:28 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-17 11:39 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 08:16 -0600
Re: DOES> and flash "Alex McDonald" <blog@rivadpm.com> - 2014-01-17 16:06 +0000
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:21 +0000
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 12:32 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:19 -0600
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 18:20 +0000
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-20 01:25 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 08:31 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-14 01:33 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 10:05 +0000
CREATE...DOES> on program-in-flash systems anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 11:58 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 08:43 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:37 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-11 11:28 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 12:24 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 18:19 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 22:03 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:28 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 15:09 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 03:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:16 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 22:58 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:34 -0500
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-29 19:30 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 22:49 -0800
Re: PICK changed from 1-based to 0-based? AKK <akk@nospam.org> - 2013-12-30 08:48 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:24 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:32 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:05 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:02 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 05:48 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:00 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 21:42 +1100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-12-30 09:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 03:35 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:06 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 10:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:50 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 07:08 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:36 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 15:23 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 16:02 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 08:54 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 19:59 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 10:12 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <st@trstn.net> - 2014-01-03 20:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 20:29 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 11:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 12:00 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-04 13:12 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 08:22 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:37 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 16:58 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-02 16:41 +0000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 16:54 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:22 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:20 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:56 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-30 08:14 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:54 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 23:15 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-31 07:05 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 09:26 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:27 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 18:21 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-01 12:12 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 15:59 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-03 00:19 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:25 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-04 19:03 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 14:08 +1100
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-06 01:47 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:43 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:29 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 16:30 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 23:12 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:30 +0000
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 13:57 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 12:17 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-04 15:08 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 04:57 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-05 09:14 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 12:20 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:05 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:55 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:49 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 11:24 -0500
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 16:06 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:47 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2013-12-30 18:29 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 09:34 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:06 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:34 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-03 08:04 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:38 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 15:57 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 14:52 +0000
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 07:19 -0600 |
| Message-ID | <B5WdnbnIg5dJJVvPnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #27630 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>The hope of the Forth94 TC was that after some passage of time the air >>would be sufficiently cleared that a new standard could add NOT with >>whatever emerged as the predominant usage. > > Nobody has made a proposal on that, and discussions here in the last > few years indicate that we probably won't be able to reach a consensus > on NOT. This is true. I last raised the issue a year or so ago in the hope that we could have NOT IF and NOT WHILE back, but no luck. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2013-12-29 22:32 -0500 |
| Message-ID | <op.w8vyss0m5zc71u@localhost> |
| In reply to | #27503 |
On Sun, 29 Dec 2013 08:45:41 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Hans Bezemer <the.beez.speaks@gmail.com> wrote: >> Forth-83 is where Forth IMHO went wrong. [ ... ] >> Turning "true" into an "all bits set" value [...] > > [...] but what possible damage did "all bits set" do? > It doesn't do any damage. In fact, it helps. Using "all bits set" for a TRUE flag allows a high-level language to have both logical and binary operations, while only needing the processor to support simple binary operations, such as AND OR XOR. This, of course, is in the context of zero being logical false and non-zero being logical true. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-12-30 16:46 +0000 |
| Message-ID | <2013Dec30.174628@mips.complang.tuwien.ac.at> |
| In reply to | #27517 |
"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>Using "all bits set" for a TRUE flag allows a high-level language
>to have both logical and binary operations, while only needing the
>processor to support simple binary operations, such as AND OR XOR.
AND OR XOR also work for 0-or-1 flags. Only INVERT (which did not
exist in Forth-79) does not work as a NOT for 0-or-1 flags; but we
have 0= in Forth-79, Forth-83, Forth-94, and Forth-2012.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2013-12-30 18:37 -0500 |
| Message-ID | <op.w8xikxwo5zc71u@localhost> |
| In reply to | #27531 |
On Mon, 30 Dec 2013 11:46:28 -0500, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes: >> Using "all bits set" for a TRUE flag allows a high-level language >> to have both logical and binary operations, while only needing the >> processor to support simple binary operations, such as AND OR XOR. > > AND OR XOR also work for 0-or-1 flags. Yes, for flags, but not for logical true, when true is defined as non-zero. I.e., OR of 2 and 4 will be logical true if true is defined as non-zero, but OR or 2 and 4 will be 0 for 0-or-1 flags instead of logical true. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2013-12-31 11:53 +0100 |
| Message-ID | <52c2a229$0$2918$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27553 |
Rod Pemberton wrote: > Yes, for flags, but not for logical true, when true is defined as > non-zero. I.e., OR of 2 and 4 will be logical true if true is > defined as non-zero, but OR or 2 and 4 will be 0 for 0-or-1 flags > instead of logical true. There is no such concept as "logical true" in ANS AFAIK. Your assumption concerning all-bits-set ONLY works if at least ONE value is a fully qualified flag. And there is the pitfall - you have to keep that in mind all the time. Therefore, I often define those: : ANY OR 0<> ; : BOTH 0<> * 0<> ; These are fully qualified logical operators and return a fully qualified flag. BTW, they work for either -1 (all-bits-set) and 1. I can't remember when I had to use a logical XOR. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-12-30 17:21 +0000 |
| Message-ID | <2013Dec30.182107@mips.complang.tuwien.ac.at> |
| In reply to | #27503 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>>
>> What people essentially did in Forth-83 was to strip most/some/all
>> intuitive concepts of Forth and turn it into a somewhat glorified
>> assembler. "falling through" in a loop concept like
>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>> you could do some obfuscated binary tricks with it. I can forgive
>> them for PICK and ROLL because no Forther in his right mind would
>> use these.
>
>Some of the big changes were essential, though: we couldn't live with
>16-bit threaded code forever.
But according to the Forth-94 document Forth-83 did require threaded
code, so this essential change was not in Forth-83. And Forth-83
certainly assumed 16 bits and did not provide CELLS and CELL+ for
writing code that is portable between cell sizes. These are all
Forth-94 innovations, and Forth-94 achieved them without breaking
existing code.
> The 83-standard DO..LOOP was
>undoubtedly a mistake,
In which way?
> but what possible damage did "all bits set" do?
It broke existing code.
What benefit did it have? A pretty minor one IMO.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-12-30 12:03 -0600 |
| Message-ID | <DsudnRfhlcfmKFzPnZ2dnUVZ_gadnZ2d@supernews.com> |
| In reply to | #27537 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Hans Bezemer <the.beez.speaks@gmail.com> wrote: >>> Forth-83 is where Forth IMHO went wrong. [ ... ] >>> >>> What people essentially did in Forth-83 was to strip most/some/all >>> intuitive concepts of Forth and turn it into a somewhat glorified >>> assembler. "falling through" in a loop concept like >>> DO..LOOP. Turning "true" into an "all bits set" value - just because >>> you could do some obfuscated binary tricks with it. I can forgive >>> them for PICK and ROLL because no Forther in his right mind would >>> use these. >> >>Some of the big changes were essential, though: we couldn't live with >>16-bit threaded code forever. > > But according to the Forth-94 document Forth-83 did require threaded > code, so this essential change was not in Forth-83. > And Forth-83 certainly assumed 16 bits and did not provide CELLS and > CELL+ for writing code that is portable between cell sizes. These > are all Forth-94 innovations, and Forth-94 achieved them without > breaking existing code. It did not. Any existing code which assumed that CELLS = 2* was broken, and there was lots and lots of such code. >>The 83-standard DO..LOOP was undoubtedly a mistake, > > In which way? Surely we've been over this many times before. The 83-standard DO..LOOP is hard to describe and hard to understand, and has hideously bad behaviour with 0 0 DO. It was only accepted because at the time it was easily implemented with a neat trick involving the overflow flag, and it worked equally well for signed and unsigned loops. That neat trick often doesn't help make things faster if a loop uses I once, and if it uses I more than once it's actually a disadvantage. The DO..LOOP used by Forth, Inc was much cleaner, and there were two versions, one for signed and one for unsigned loops. It didn't have the pathological behaviour of the 83-standard loop. >> but what possible damage did "all bits set" do? > > It broke existing code. Sure, but I don't think that matters now. The consensus at the time was that the important thing was to get things right, even if doing so broke code. That was irrelevant anyway because the vendors had incompatible dialects. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-12-30 18:09 +0000 |
| Message-ID | <2013Dec30.190956@mips.complang.tuwien.ac.at> |
| In reply to | #27540 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>>>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>>>>
>>>> What people essentially did in Forth-83 was to strip most/some/all
>>>> intuitive concepts of Forth and turn it into a somewhat glorified
>>>> assembler. "falling through" in a loop concept like
>>>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>>>> you could do some obfuscated binary tricks with it. I can forgive
>>>> them for PICK and ROLL because no Forther in his right mind would
>>>> use these.
>>>
>>>Some of the big changes were essential, though: we couldn't live with
>>>16-bit threaded code forever.
>>
>> But according to the Forth-94 document Forth-83 did require threaded
>> code, so this essential change was not in Forth-83.
>> And Forth-83 certainly assumed 16 bits and did not provide CELLS and
>> CELL+ for writing code that is portable between cell sizes. These
>> are all Forth-94 innovations, and Forth-94 achieved them without
>> breaking existing code.
>
>It did not. Any existing code which assumed that CELLS = 2* was
>broken, and there was lots and lots of such code.
It was not broken, just not compliant. Such code still worked on
Forth-94 systems with 16-bit cells.
In contrast, the changes from Forth-79 to Forth-83 broke existing
code. Code that used, e.g., C@ NOT that worked on Forth-79 did not
work on any Forth-83 compliant system, and no Forth-83 compliant
system can be written to make such Forth-79 compliant code work.
>>> but what possible damage did "all bits set" do?
>>
>> It broke existing code.
>
>Sure, but I don't think that matters now.
It matters for answering the question what damage it did do. And it
matters now because it is an example of how not to standarize, not
then and not now.
>The consensus at the time
>was that the important thing was to get things right, even if doing so
>broke code.
That may have been the consensus among the Forth-83 committee, but it
obviously was not the consensus of the wider community.
>That was irrelevant anyway because the vendors had
>incompatible dialects.
That was also the case in Forth-94 and the Forth-200x effort, and
Forth-94 managed to avoid the mistakes that Forth-83 made, and
Forth-200x followed Forth-94's excellent example.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-12-30 12:43 -0600 |
| Message-ID | <SLGdnYHM25p1I1zPnZ2dnUVZ_u-dnZ2d@supernews.com> |
| In reply to | #27546 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Hans Bezemer <the.beez.speaks@gmail.com> wrote: >>>>> Forth-83 is where Forth IMHO went wrong. [ ... ] >>>>> >>>>> What people essentially did in Forth-83 was to strip most/some/all >>>>> intuitive concepts of Forth and turn it into a somewhat glorified >>>>> assembler. "falling through" in a loop concept like >>>>> DO..LOOP. Turning "true" into an "all bits set" value - just because >>>>> you could do some obfuscated binary tricks with it. I can forgive >>>>> them for PICK and ROLL because no Forther in his right mind would >>>>> use these. >>>> >>>>Some of the big changes were essential, though: we couldn't live with >>>>16-bit threaded code forever. >>> >>> But according to the Forth-94 document Forth-83 did require threaded >>> code, so this essential change was not in Forth-83. >>> And Forth-83 certainly assumed 16 bits and did not provide CELLS and >>> CELL+ for writing code that is portable between cell sizes. These >>> are all Forth-94 innovations, and Forth-94 achieved them without >>> breaking existing code. >> >>It did not. Any existing code which assumed that CELLS = 2* was >>broken, and there was lots and lots of such code. > > It was not broken, just not compliant. Such code still worked on > Forth-94 systems with 16-bit cells. > > In contrast, the changes from Forth-79 to Forth-83 broke existing > code. Code that used, e.g., C@ NOT that worked on Forth-79 did not > work on any Forth-83 compliant system, and no Forth-83 compliant > system can be written to make such Forth-79 compliant code work. Sure, but as I have already explained, Forth code at the time was so vendor-specific that it was going to have to be changed anyway, and people didn't much port code between Forths, so it didn't really matter. >>>> but what possible damage did "all bits set" do? >>> >>> It broke existing code. >> >>Sure, but I don't think that matters now. > > It matters for answering the question what damage it did do. Not really, no. There's no real evidence that it did any damage. Simply saying "it broke code!" doesn't really prove anything. >>The consensus at the time was that the important thing was to get >>things right, even if doing so broke code. > > That may have been the consensus among the Forth-83 committee, but it > obviously was not the consensus of the wider community. "Obviously?" IIRC Forth-83 was widely used, although there remained a vocal minority who didn't accept it. There still is for every Forth standard. >>That was irrelevant anyway because the vendors had incompatible >>dialects. > > That was also the case in Forth-94 and the Forth-200x effort, Not to the same extent, IIRC. Forth-83 was good enough, and widely accepted enough, to be a reasonable basis for Forth-94. > and Forth-94 managed to avoid the mistakes that Forth-83 made, and > Forth-200x followed Forth-94's excellent example. No disagreement there. However, the situation was entirely different. I don't think it has any relevance whatsoever to the current standardization effort. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-02 16:52 +0000 |
| Message-ID | <2014Jan2.175242@mips.complang.tuwien.ac.at> |
| In reply to | #27548 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>> code. Code that used, e.g., C@ NOT that worked on Forth-79 did not
>> work on any Forth-83 compliant system, and no Forth-83 compliant
>> system can be written to make such Forth-79 compliant code work.
>
>Sure, but as I have already explained, Forth code at the time was so
>vendor-specific that it was going to have to be changed anyway, and
>people didn't much port code between Forths, so it didn't really
>matter.
If they did not port code, why have a standard? And why would the
code have to be changed anyway?
When you introduce a standard (for the whole language, or for one
particular feature set, like locals in Forth-94), you always have the
situation that the code is vendor-specific. And a lot of people don't
port their code between language implementations most of the time, so
for them standardization does not matter most of the time. It's only
when they want to or have to change implementations that they notice.
>Not really, no. There's no real evidence that it did any damage.
Knowing you, whatever evidence I present, you will always claim it's
not real, so I won't invest any time in this futile exercise.
>> That may have been the consensus among the Forth-83 committee, but it
>> obviously was not the consensus of the wider community.
>
>"Obviously?" IIRC Forth-83 was widely used, although there remained a
>vocal minority who didn't accept it. There still is for every Forth
>standard.
There was a vocal minority who did not accept Forth-94 and stuck with
Forth-83? Who? I don't remember anyone.
>>>That was irrelevant anyway because the vendors had incompatible
>>>dialects.
>>
>> That was also the case in Forth-94 and the Forth-200x effort,
>
>Not to the same extent, IIRC. Forth-83 was good enough, and widely
>accepted enough, to be a reasonable basis for Forth-94.
Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were
good enough, and widely accepted enough to be a reasonable basis for
these words in Forth-83, but the Forth-83 committee chose to not just
ignore this, but also to use these names for words that behave
differently.
Going forward, vendors had incompatible dialects for locals by the
time the Forth-94 comittee was at work. Following your argument, they
would have been allowed to change all parts of the language
incompatibly. Fortunately, they saw the evidence that you deny, and
wisely refrained from repeating this mistake.
The Forth-200x committee found that the LOCALS| syntax introduced by
Forth-94 was not widely accepted. Following your argument, we would
have been allowed to change all parts of the language incompatibly.
Fortunately, at least some of us saw the evidence that you deny, and
wisely refrained from repeating this mistake.
>> and Forth-94 managed to avoid the mistakes that Forth-83 made, and
>> Forth-200x followed Forth-94's excellent example.
>
>No disagreement there. However, the situation was entirely different.
The only differences I see are not in the starting situation, but what
the committee made from it: Forth-94 and Forth-200x did not change
already-standardized words incompatibly.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-02 08:32 -1000 |
| Message-ID | <qvKdnU6HbKRVLVjPnZ2dnUVZ_t2dnZ2d@supernews.com> |
| In reply to | #27592 |
On 1/2/14 6:52 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> In contrast, the changes from Forth-79 to Forth-83 broke existing >>> code. Code that used, e.g., C@ NOT that worked on Forth-79 did not >>> work on any Forth-83 compliant system, and no Forth-83 compliant >>> system can be written to make such Forth-79 compliant code work. >> >> Sure, but as I have already explained, Forth code at the time was so >> vendor-specific that it was going to have to be changed anyway, and >> people didn't much port code between Forths, so it didn't really >> matter. > > If they did not port code, why have a standard? And why would the > code have to be changed anyway? In order to make it possible. > When you introduce a standard (for the whole language, or for one > particular feature set, like locals in Forth-94), you always have the > situation that the code is vendor-specific. And a lot of people don't > port their code between language implementations most of the time, so > for them standardization does not matter most of the time. It's only > when they want to or have to change implementations that they notice. That effort was successful. By the late 90's we saw a number of people porting whole applications from one Forth to another. Ray Duncan retired from Forth to pursue his career in medicine, and turned over his customer list to FORTH, Inc.. Many of his customers converted their applications, fairly painlessly. >> Not really, no. There's no real evidence that it did any damage. > > Knowing you, whatever evidence I present, you will always claim it's > not real, so I won't invest any time in this futile exercise. > >>> That may have been the consensus among the Forth-83 committee, but it >>> obviously was not the consensus of the wider community. >> >> "Obviously?" IIRC Forth-83 was widely used, although there remained a >> vocal minority who didn't accept it. There still is for every Forth >> standard. > > There was a vocal minority who did not accept Forth-94 and stuck with > Forth-83? Who? I don't remember anyone. The ANS Forth TC did a study in the late 80's. The overwhelming majority of Forths in use at the time were at least close to Forth83. There were a few Forth79 holdouts, and a few ideosyncratic systems that followed no particular standard. By staying as close as possible to Forth83 and presenting compromises for the most contentious issues, Forth94 achieved a very broad consensus. The folks who didn't go with Forth94 were typically Forth79 holdouts, FIGforth advocates, and variants like JonesForth. >>>> That was irrelevant anyway because the vendors had incompatible >>>> dialects. >>> >>> That was also the case in Forth-94 and the Forth-200x effort, >> >> Not to the same extent, IIRC. Forth-83 was good enough, and widely >> accepted enough, to be a reasonable basis for Forth-94. > > Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were > good enough, and widely accepted enough to be a reasonable basis for > these words in Forth-83, but the Forth-83 committee chose to not just > ignore this, but also to use these names for words that behave > differently. Yes. > Going forward, vendors had incompatible dialects for locals by the > time the Forth-94 comittee was at work. Following your argument, they > would have been allowed to change all parts of the language > incompatibly. Fortunately, they saw the evidence that you deny, and > wisely refrained from repeating this mistake. Actually, the only existing implementation of locals we could find was the one in MacForth. That is why its model was adopted, even though a lot of people wanted a different order of arguments. > The Forth-200x committee found that the LOCALS| syntax introduced by > Forth-94 was not widely accepted. Following your argument, we would > have been allowed to change all parts of the language incompatibly. > Fortunately, at least some of us saw the evidence that you deny, and > wisely refrained from repeating this mistake. We felt that designing a whole new locals syntax that was incompatible with the only one in fairly widespread use would have been a mistake. >>> and Forth-94 managed to avoid the mistakes that Forth-83 made, and >>> Forth-200x followed Forth-94's excellent example. >> >> No disagreement there. However, the situation was entirely different. > > The only differences I see are not in the starting situation, but what > the committee made from it: Forth-94 and Forth-200x did not change > already-standardized words incompatibly. And that has been wise. 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 | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-05 13:26 +1100 |
| Message-ID | <laafun$rf7$1@speranza.aioe.org> |
| In reply to | #27598 |
Elizabeth D. Rather wrote: > On 1/2/14 6:52 AM, Anton Ertl wrote: > > ... > > The only differences I see are not in the starting situation, but what > > the committee made from it: Forth-94 and Forth-200x did not change > > already-standardized words incompatibly. > > And that has been wise. I must have a different set of documents ... '83 TYPE takes a signed count. '94 changed it to unsigned. '83 WORD and 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing blank. '94 guarantees only 31 chars and excludes new programs from using the trailing blank. 200x removed the blank altogether. '94 permitted separate and common f/p stack. 200x excluded systems with a common f/p stack. What is notable about these is that they add no new facility to Forth, nor fixed any problem. The only effect of these changes has been the removal features and options Forth users once had, potentially breaking programs in the process.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-04 16:55 -1000 |
| Message-ID | <9KqdnVAlP54sVFXPnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #27678 |
On 1/4/14 4:26 PM, Ed wrote: > Elizabeth D. Rather wrote: >> On 1/2/14 6:52 AM, Anton Ertl wrote: >>> ... >>> The only differences I see are not in the starting situation, but what >>> the committee made from it: Forth-94 and Forth-200x did not change >>> already-standardized words incompatibly. >> >> And that has been wise. > > I must have a different set of documents ... > > '83 TYPE takes a signed count. '94 changed it to unsigned. Were any systems broken that depended on a negative count? I didn't think so. The change allowed twice as long a string. > '83 WORD and > 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing > blank. '94 guarantees only 31 chars and excludes new programs from using > the trailing blank. 200x removed the blank altogether. Not sure what the 31 characters is about. WORD makes a counted string. It did retain the blank but advertised it as "obsolescent" to allow a generation (of programs) to adapt before the blank was removed altogether. Again, I doubt that broke any existing programs. > '94 permitted separate > and common f/p stack. 200x excluded systems with a common f/p stack. The common f/p stack was retained in '94 mainly as a commitment to the Harris team and Chuck. > What is notable about these is that they add no new facility to Forth, nor fixed > any problem. The only effect of these changes has been the removal features > and options Forth users once had, potentially breaking programs in the process. The TYPE change allowed strings twice as long. This was considered important because some people TYPE into a file. The integrated f/p stack was a feature that had to be documented and that one wasn't supposed to depend on. It still is, it's just that instead of being a documented option it's now an environmental restriction. I'm not at all sure about the value of these features or whether any actual programs were broken. 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 | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-07 12:45 +1100 |
| Message-ID | <lafm9p$5tl$2@speranza.aioe.org> |
| In reply to | #27680 |
Elizabeth D. Rather wrote: > On 1/4/14 4:26 PM, Ed wrote: > > ... > > '83 TYPE takes a signed count. '94 changed it to unsigned. > > Were any systems broken that depended on a negative count? I didn't > think so. The change allowed twice as long a string. > > > '83 WORD and > > 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing > > blank. '94 guarantees only 31 chars and excludes new programs from using > > the trailing blank. 200x removed the blank altogether. > > Not sure what the 31 characters is about. minimum WORD buffer size: ANS ... 31+2 '83 ... 255+2 > WORD makes a counted string. > It did retain the blank but advertised it as "obsolescent" to allow a > generation (of programs) to adapt before the blank was removed > altogether. Again, I doubt that broke any existing programs. > > > '94 permitted separate > > and common f/p stack. 200x excluded systems with a common f/p stack. > > The common f/p stack was retained in '94 mainly as a commitment to the > Harris team and Chuck. > > > What is notable about these is that they add no new facility to Forth, nor fixed > > any problem. The only effect of these changes has been the removal features > > and options Forth users once had, potentially breaking programs in the process. > > The TYPE change allowed strings twice as long. This was considered > important because some people TYPE into a file. The integrated f/p stack > was a feature that had to be documented and that one wasn't supposed to > depend on. It still is, it's just that instead of being a documented > option it's now an environmental restriction. I'm not at all sure about > the value of these features or whether any actual programs were broken. An extraordinary set of admissions. The TC changes the behaviour of Standard words and then asks users whether any actual programs were broken? Honestly? I'm aware of the TC dismissing alternatives to their own proposals citing it would break programs because an obscure Forth used a word with the same name. You ask what is broken? Forth's credibility is broken. You cannot expect people to invest time and money in a language which chops and changes according to the whims of "some people".
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-06 22:15 -1000 |
| Message-ID | <CIGdnVBIwaE9KlbPnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #27707 |
On 1/6/14 3:45 PM, Ed wrote: > Elizabeth D. Rather wrote: >> On 1/4/14 4:26 PM, Ed wrote: >>> ... >>> '83 TYPE takes a signed count. '94 changed it to unsigned. >> >> Were any systems broken that depended on a negative count? I didn't >> think so. The change allowed twice as long a string. >> >>> '83 WORD and >>> 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing >>> blank. '94 guarantees only 31 chars and excludes new programs from using >>> the trailing blank. 200x removed the blank altogether. >> >> Not sure what the 31 characters is about. > > minimum WORD buffer size: > ANS ... 31+2 > '83 ... 255+2 Ok, I found that reference, which I had forgotten. However, minimum specifications don't "break" programs. Only on very small embedded systems will you see a WORD buffer thus limited, and if it will cause your program pain, you need to document an environmental requirement for a WORD buffer of at least <n> bytes. That program will probably run into other difficulties anyway. ... > > An extraordinary set of admissions. The TC changes the behaviour of Standard > words and then asks users whether any actual programs were broken? Honestly? We asked users (via first surveys and later public review periods) when we were contemplating the changes. My question quoted above was for you. > I'm aware of the TC dismissing alternatives to their own proposals citing it would > break programs because an obscure Forth used a word with the same name. > > You ask what is broken? Forth's credibility is broken. You cannot expect people > to invest time and money in a language which chops and changes according to the > whims of "some people". The record of stability as well as system conformance since Forth94 has been exemplary. And a 6-year development period with users invited to 4 meetings/year, all drafts published, and so many public review periods, can hardly be considered whimsical. 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 | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-15 08:39 +1100 |
| Message-ID | <lb4auc$frj$1@speranza.aioe.org> |
| In reply to | #27711 |
Elizabeth D. Rather wrote: > On 1/6/14 3:45 PM, Ed wrote: > > Elizabeth D. Rather wrote: > > ... > >> Not sure what the 31 characters is about. > > > > minimum WORD buffer size: > > ANS ... 31+2 > > '83 ... 255+2 > > Ok, I found that reference, which I had forgotten. However, minimum > specifications don't "break" programs. Only on very small embedded > systems will you see a WORD buffer thus limited, and if it will cause > your program pain, you need to document an environmental requirement for > a WORD buffer of at least <n> bytes. That program will probably run into > other difficulties anyway. '94 didn't need to reduce the 255+2 minimum spec for WORD's buffer. It need only have stated systems which did not meet the spec of 255+2 had an environmental dependency which might limit the Standard Programs they could run. Same deal for TYPE. '94 could have retained the '83 specs and avoided the current silliness which requires programmers to document entitlements which existed in Forth from earliest days. Embedded systems low on memory should be using forth's scheme of overlapping buffers. That'll guarantee them a WORD buffer much greater than the ANS minimum. > > ... > > You ask what is broken? Forth's credibility is broken. You cannot expect people > > to invest time and money in a language which chops and changes according to the > > whims of "some people". > > The record of stability as well as system conformance since Forth94 has > been exemplary. And a 6-year development period with users invited to 4 > meetings/year, all drafts published, and so many public review periods, > can hardly be considered whimsical. In 1993 when I obtained a copy of DPANS had someone told me it was manna from heaven, I might have accepted it. But that was 20 years ago and much water has passed under the bridge. I've seen too much to believe everything I read.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-05 12:53 +0000 |
| Message-ID | <2014Jan5.135354@mips.complang.tuwien.ac.at> |
| In reply to | #27678 |
"Ed" <invalid@invalid.com> writes:
>I must have a different set of documents ...
>
>'83 TYPE takes a signed count.
You obviously have a different document. The Forth-83 document I have says:
|TYPE addr +n -- M,79
| +n characters are displayed from memory beginning with the
| character at addr and continuing through consecutive
| addresses. Nothing is displayed if +n is zero.
So the count must not be non-negative.
>'94 changed it to unsigned.
No Forth-83 compliant program became Forth-94 non-compliant because of
this change. This is a tightening of the spec.
>'83 WORD and
>11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
>blank. '94 guarantees only 31 chars and excludes new programs from using
>the trailing blank. 200x removed the blank altogether.
As far as I can see, Forth-94 guarantees at least 33 chars, while I
don't see any length guarantee in Forth-83. One can argue that this
means that the string can have up to 255 characters, but I suspect
that a number of systems that were generally considered to be Forth-83
compliant put the pictured numeric output (HOLD) buffer and PAD inside
those 255 chars.
The removal of the guaranteed trailing blank is a loosening of the
spec. Such a removal of guarantees has to be done with care, that's
why it happened in two stages: In the first stage, it was announced
that it would be removed, in the second (18 years later) it was
removed.
>'94 permitted separate
>and common f/p stack. 200x excluded systems with a common f/p stack.
That's a tightening of the spec. There were practically no Forth-94
programs that used FP and did not have either an environmental
dependency on a separate FP stack, or on a shared data/FP stack with
FP numbers having n cells. In other words, Forth-94 had not
standardized FP in a way that encouraged people to write fully
standard programs. Forth-2012 corrects that.
>What is notable about these is that they add no new facility to Forth, nor fixed
>any problem. The only effect of these changes has been the removal features
>and options Forth users once had, potentially breaking programs in the process.
Tightening the standard does not de-standardize previously standard
programs (unlike the Forth-83 changes).
Loosening the standard does destandardize previously standard program,
but systems are still free to implement the tighter spec, so they can
still support the programs that had run on the system before; also,
loosening the spec is done in stages to give programmers time to adapt
to the new situation.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-02 13:45 -0600 |
| Message-ID | <js-dnSUacfdUXFjPnZ2dnUVZ_jSdnZ2d@supernews.com> |
| In reply to | #27592 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> In contrast, the changes from Forth-79 to Forth-83 broke existing >>> code. Code that used, e.g., C@ NOT that worked on Forth-79 did not >>> work on any Forth-83 compliant system, and no Forth-83 compliant >>> system can be written to make such Forth-79 compliant code work. >> >>Sure, but as I have already explained, Forth code at the time was so >>vendor-specific that it was going to have to be changed anyway, and >>people didn't much port code between Forths, so it didn't really >>matter. > > If they did not port code, why have a standard? Because it was thought that portability, both of programmers and programs, might be useful. > And why would the code have to be changed anyway? > > When you introduce a standard (for the whole language, or for one > particular feature set, like locals in Forth-94), you always have > the situation that the code is vendor-specific. And a lot of people > don't port their code between language implementations most of the > time, so for them standardization does not matter most of the time. > It's only when they want to or have to change implementations that > they notice. If their vendor doesn't make incompatrible changes to their Forth, they'll be fine, but in the end, if the standard succeeds, everyone will move to it, and everyone will have to make changes to their code. There's nothing special about Forth in this regard; it happend with many other langauges, in particular the change from K&R C. >>Not really, no. There's no real evidence that it did any damage. > > Knowing you, whatever evidence I present, you will always claim it's > not real, so I won't invest any time in this futile exercise. Oh dear, this is my punishment for failing to agree with you. I'm not at all sure that it's even possible to show such a thing, let alone real evidence. You'd have to run history again. I do not believe that anyone cared enough about Forth-79 for it really to matter. >>> That may have been the consensus among the Forth-83 committee, but it >>> obviously was not the consensus of the wider community. >> >>"Obviously?" IIRC Forth-83 was widely used, although there remained a >>vocal minority who didn't accept it. There still is for every Forth >>standard. > > There was a vocal minority who did not accept Forth-94 and stuck with > Forth-83? Who? No-one AFAIAA. However, there is a vocal minority who didn't accept ANS. > I don't remember anyone. > >>>>That was irrelevant anyway because the vendors had incompatible >>>>dialects. >>> >>> That was also the case in Forth-94 and the Forth-200x effort, >> >>Not to the same extent, IIRC. Forth-83 was good enough, and widely >>accepted enough, to be a reasonable basis for Forth-94. > > Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were > good enough, and widely accepted enough to be a reasonable basis for > these words in Forth-83, but the Forth-83 committee chose to not just > ignore this, but also to use these names for words that behave > differently. That's unquestionably true. > Going forward, vendors had incompatible dialects for locals by the > time the Forth-94 comittee was at work. Following your argument, they > would have been allowed to change all parts of the language > incompatibly. No, because post-ANS, everything changed. There was now a standard worth having, and was worth keeping compatibility with. It was not so in 1983. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-02 20:17 -0500 |
| Message-ID | <op.w82675jh5zc71u@localhost> |
| In reply to | #27603 |
On Thu, 02 Jan 2014 14:45:13 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > No, because post-ANS, everything changed. There was now a > standard worth having, and was worth keeping compatibility with. Where's Hugh when you need him? He hates ANS, yes? RP
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 04:03 -0600 |
| Message-ID | <IYKdnULucd-WFlvPnZ2dnUVZ_omdnZ2d@supernews.com> |
| In reply to | #27614 |
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > On Thu, 02 Jan 2014 14:45:13 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >> No, because post-ANS, everything changed. There was now a >> standard worth having, and was worth keeping compatibility with. > > Where's Hugh when you need him? He hates ANS, yes? I suppose so, in which case he's one of the vocal minority. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web