Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Page 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-19 17:44 -0700 |
| Message-ID | <ff7890d6-5c3b-487c-9ba8-6f343dac8a94@googlegroups.com> |
| In reply to | #29678 |
On Wednesday, April 16, 2014 12:31:29 AM UTC-7, Elizabeth D. Rather wrote: > (LOCAL) was proposed by > Don Colburn, of Creative Solutions. His MacForth systems were the first > to implement any form of locals, in the 1980's, and when his proposal > was presented there were over 50,000 copies of his system in use. The TC > opted to support this existing, successful implementation in preference > to inventing a new one. This should sober up people like Bernd Payson and Anton Ertl. Elizabeth Rather's own words (on www.forth.com) describing herself are: "Elizabeth Rather is the co-founder of FORTH, Inc. and is a leading expert in the Forth programming language. Elizabeth was a colleague of Chuck Moore back when he worked at NRAO in the early 1970s. During his development of Forth, she became the second ever Forth programmer. Since then, she has become a leading expert in the language and one of its main proponents. Elizabeth was the chair of the ANSI Technical Committee that produced the ANSI Standard for Forth (1994). She is an author of several books on Forth and gives regular training seminars on its usage." She describes herself as a "leading expert" more than once in a single paragraph. But, when it is pointed out that LOCALS| has the parameters backwards, she throws Don Colburn under the bus, claiming that it is all his fault. This is leading??? I think that the only reason why she allows Bernd Payson and Anton Ertl to be puppet chiefs on the Forth-200x committee, is so she will have somebody to blame when Forth-200x proves to be another "epic fail." > FORTH, Inc. didn't implement any form of locals > until several years after Forth94 was adopted. This is a really good quote. This sums up why ANS-Forth was an "epic fail" --- far better than anything that I could say. Maybe if you had tested LOCALS| even once, you would have noticed that the parameters were backwards. Also, you are neglecting to mention that when you did implement (LOCAL) in SwiftForth version-2, it would crash SwiftForth when it was used (although LOCALS| worked as advertised) --- so you still hadn't tested the use of local variables even once, but you just sold SwiftForth for almost $500 to gullible customers such as myself (caveat emptor!). The reason why you didn't test local variables even once, is because you aren't a programmer. You can't even write simple test functions, and certainly not whole programs. ANS-Forth will inevitably disappear. It was still-born in 1994; essentially everybody abandoned Forth at that time. The goal now, should be to ensure that when ANS-Forth finally disappears completely, that the Forth language doesn't disappear along with it. The best way to succeed at this goal, is to kick Forth Inc. off the Forth-200x committee. ANS-Forth was an "epic fail" --- there has to be a clean break away from ANS-Forth in order to not be another "epic fail." Don't tie yourself to the mast of a sinking ship --- loyalty isn't all that great of a virtue --- Forth Inc. is dragging Forth down, and they have to be abandoned sooner or later. I had previously said that my Forth would be called "Straight Forth." This was because, at that time, Elizabeth Rather's attack poodle John Passaniti was attacking me relentlessly. Passaniti is long gone now, although Elizabeth Rather continues to accuse me of being homophobic (for example, when she was demanding that I be kicked off the Forth-200x mailing list). I would be more than happy to forget about all of that disgusting homosexuality issue that C.L.F. was embroiled in when Elizabeth Rather was keeping Passaniti as her pet. With this in mind, I think that I will change the name to "Lifeboat Forth" --- that is a pretty good analogy --- as the ANS-Forth ship sinks beneath the waves, a handful of Forthers will escape (maybe just me and Richard Parker).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-20 11:35 -0700 |
| Message-ID | <454f6894-f6b2-45dc-b44f-6e598355650b@googlegroups.com> |
| In reply to | #29678 |
On Wednesday, April 16, 2014 12:31:29 AM UTC-7, Elizabeth D. Rather wrote: > On 4/15/14 8:50 PM, Alexander Skobelev wrote: > > On Wednesday, April 16, 2014 7:04:00 AM UTC+4, hughag...@yahoo.com wrote: > > >> I don't > >> want to be like Forth Inc. that wrote the ANS-Forth standard for > >> (LOCAL) at a time when they were selling a commercial compiler that > >> crashed every time that (LOCAL) was used. I'm very much opposed to > >> just making stuff up --- the internet has too much of that already. > I am thoroughly sick of Hugh's flat-out lies. (LOCAL) was proposed by > Don Colburn, of Creative Solutions. His MacForth systems were the first > to implement any form of locals, in the 1980's, and when his proposal > was presented there were over 50,000 copies of his system in use. The TC > opted to support this existing, successful implementation in preference > to inventing a new one. FORTH, Inc. didn't implement any form of locals > until several years after Forth94 was adopted. There were really 50,000 people using MacForth? And they all demanded that the parameters for LOCALS| should be backwards --- well, that proves that I am wrong to want the parameter declarations in the same order as the parameters are given to the function --- who am I to argue with an army of 50,000? I think that you are a pathological liar. You just make this stuff up! You once claimed to be personal friends with Barrack Obama's family in Hawaii, but then you stopped saying this when it became obvious that that turkey of a tale wasn't going to fly. When I was driving a cab, I encountered people like you all the time. For them, it is hugely important that they have a Scottsdale address rather than a Phoenix address (just like how you brag about living in Hawaii), because this supposedly distinguishes them from the riff-raff. They claim to be best friends with various celebrities that I'm supposed to know about, and they always refer to the celebrities by a nickname (just like how the Forth-200x document refers to Charles Moore as "Chuck"). They claim to be scientists or what-not, when they really just work as sales-people. I can spot people like this a mile away --- I saw you for what you were straight off (although not soon enough to avoid paying upwards of $500 for SwiftForth version-2 that crashes whenever (LOCAL) is used). I think that your story about NASA hiring Forth Inc. was just a marketing gimmick. You want potential customers to believe this, to induce them to pluck down their $500 and buy a copy of SwiftForth. This reminds me of how a guy trying to sell me Amway told me that my "upstream" would be some professional football player (I don't recall which one), and that I would be partying at his mansion and rubbing elbows with celebrities every weekend. Eventually it becomes obvious that the NASA story is not true, at which time you make some vague excuse about how the deal fell through at the last minute. The story is not realistic! What if a NASA engineer goes to your Forth class and asks how memory management is done, and you spend an hour describing PAD? I really don't believe that you work for NASA --- I don't believe that you've ever written a Forth program in your life. The problem with making stuff up like this, is that all Forthers end up being taken for liars --- guilt by association --- not really fair, but it happens all the time. Anybody who actually does accomplish something in Forth, tends to be dismissed out of hand as a liar. People will say: "Sure you succeeded with Forth, and you had 50,000 customers, and you work for NASA too --- whatever --- piss off!" In this thread we find you selling the heck out of SwiftForth: https://groups.google.com/forum/#!topic/comp.lang.forth/5SAR2WfAKUU%5B1-25-false%5D On Monday, September 23, 2013 11:13:49 AM UTC-7, Elizabeth D. Rather wrote: > The "death of Forth" is wildly exaggerated. Just yesterday I received > this note from Leon Wagner: > > "Just ended a really good week at NASA. I'm working with Robyn King on > a project to instantiate ARM Cortex-M0 cores both soft and hard into SoC > (system on chip) ASICs for flight. We did one of each. The soft (IP > only, delivered as an encrypted logic file) core was put into an Altera > Cyclone III FPGA and runs at 50 MHz. I think we could probably achieve > 100 or maybe even 120 MHz, but this was not a speed race. The second > core was a hard Cortex-M0 fabricated into a custom ASIC from Triad > Semiconductor. Surprisingly (to me), the soft core along with the > complexity of building a bus and RAM out of FPGA logic was simpler and > faster to get up and running. The hard core, which is much more like a > traditional microcontroller, was harder." > > This project is being programmed entirely in Forth. Forth has been in > use at NASA (as well as many other organizations) for over 30 years, in > many varied projects.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-16 00:19 -0700 |
| Message-ID | <aa6b00fe-0bb2-4d6a-90d3-e5669136199b@googlegroups.com> |
| In reply to | #29655 |
On Monday, April 14, 2014 10:04:44 PM UTC-7, Alexander Skobelev wrote: > Hugh, wouldn't it be more productive if you published a fixed version of > ANS-Forth... Straight Forth is not really a "fixed version of ANS-Forth." There are actually 2 languages: HostForth and TargForth. HostForth requires a 64-bit computer and the cell size must be 64-bit. Primarily, HostForth is the platform that the cross-compiler for TargForth is written in. TargForth will be for any size of cell from 16 to 32 bits. Most users will program entirely in TargForth, and will not be concerned with HostForth programming at all. Most of these will focus on micro-controllers, although a few may target desktop computers such as 16-bit MS-DOS or 32-bit Linux. When programming in TargForth, there are three modes: System --- This is HostForth programming, and all memory access words (@ ! etc.) are for the system memory. No user should ever need to do System programming. Host --- This is HostForth programming, but all memory access words (@ ! etc.) are for the target memory. Any user who writes immediate words will do so in Host mode. Also, in a <BUILDS DOES> construct, the compiler automatically switches to Host mode after the DOES> and back to Targ mode after the semicolon. Targ --- This is TargForth programming. This is your application program. Every word that is compiled in Targ mode will automatically also compile a word with the same name in Host mode, and that word when executed will compile code that executes the Targ mode word into target memory (typically a CALL machine-instruction). The advantage of always cross-compiling, is that all of the weird complication in ANS-Forth regarding STATE-smart words gets eliminated. Every word in Targ mode has a corresponding same-name word in Host mode that compiles the Targ mode word (these Host mode words are like all of those xxx, words in the novice package except that they are automatically generated and they have the same name as the Targ mode word that they compile). The Targ and Host mode words may have the same names, but they have different xt values. It is possible to examine an xt value and determine if it is for a Targ or Host mode word --- it is also possible to examine an xt value and determine what vocabulary it is in --- this feature is called "reflection." In ANS-Forth, there is no way to determine if a word compiles application-code or if it is application-code, because the compile-time and run-time words are all jumbled together and indistinguishable. In Gforth we have bizarre quirks, such as semicolon not having an xt value at all --- this kind of weirdness goes away in a cross-compiler. Actually, the weirdness doesn't entirely go away --- it has just been pushed uphill into System mode. If you program in System mode, then you still have to deal with this weirdness (not being able to distinguish between compile-time and run-time words by examining the xt) --- but this isn't a problem because nobody ever does program in System mode --- essentially all programmers work in Targ mode with some occasional Host mode extensions to the compiler. All in all, Targ mode programming is very simple and straight-forward; this is novice-level programming. Host mode programming is not compatible with Targ mode programming, but it is pretty similar, and also easy; this is intermediate-level programming. System mode programming is something that a "user" will never do. The only time System mode programming is done, is when retargeting the cross-compiler for a new micro-controller; this is advanced-level programming. One reason why ANS-Forth is over-complicated, is because it is one language that is supposedly suitable for every processor, from the 16-bit MSP430 up to the 64-bit x86. ANS-Forth is a "Jack of all trades and a master of none." By comparison, in my system, I have HostForth for 64-bit processors and TargForth for 16-bit and 32-bit micro-controllers --- desktop computers and micro-controllers are very different beasts, and they have different languages.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-16 05:29 -0700 |
| Message-ID | <90b8980b-58fe-40a6-81a1-9d5af007dadc@googlegroups.com> |
| In reply to | #29677 |
On Wednesday, April 16, 2014 12:19:09 AM UTC-7, hughag...@yahoo.com wrote: > Host --- This is HostForth programming, but all memory access words (@ ! etc.) are for the target memory. Any user who writes immediate words will do so in Host mode. Also, in a <BUILDS DOES> construct, the compiler automatically switches to Host mode after the DOES> and back to Targ mode after the semicolon. I said this backwards. You are actually in Host mode when you write your <BUILDS DOES> word, and the compiler automatically switches to Targ mode after the DOES> and back to Host mode after the semicolon.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-16 22:45 -0400 |
| Message-ID | <op.xefwlgxh6zenlw@localhost> |
| In reply to | #29681 |
On Wed, 16 Apr 2014 08:29:44 -0400, <hughaguilar96@yahoo.com> wrote: > I said this backwards. Maybe I'm dyslexic? .sdrawkcab siht dias I That looks like it was said backwards to me. (Insert feigned delayed comprehension.) Oh! You meant to say "that", not "this". What's with the mixed up "this" and "that"? First, it was Alex. Now, it's you. Strange. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-14 09:49 +0000 |
| Message-ID | <534baf38$0$27133$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #29617 |
In article <lif0fc$rk$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: <SNIP> >No, this C as portable assembler would just require to fix the specification >(follow Lunyu 13.3), i.e. define what's left undefined by the standard. The >really bad thing with GCC is that Andrew Haley tells us that Gforth is not >written in GCC, but GCC actually is a moving target, and therefore, he can't >tell us what we need to change. Gforth was originally written in GCC 2.4, >but certainly is not in GCC 4.9, because the GCC maintainer decide to change >the meaning of things for every subrelease. If they had documented it at >all; but even documentation is useless - they change it. I don't like >arguing with Humpty Dumpty (as in "Through the Looking Glass"), because he >has his own, weird definitions of terms. That's clearly breaking Lunyu >13.3, and in fact, in Wonderland, you can't get things done (and if you want >to stay in the same place, you have to run as fast as you can, just as you >have if you write C programs and want them to continue to run with changing >GCC versions ;-). In the tforth team we had the same problem. Marcel kept changing tforth, such that it was unsure whether the next metacompilation would be the same, or for that matter run. So I suggested to use a boat ancre version, to always run the metacompilation. The source of this version is lost, and if it existed, it may not be possible to compile it. For tforth this can work, because there is only one transputer. Another way is the ciforth solution: only use assembler instructions that are common to a large set (read virtual all Intel) of computers. The political correct way is: define it in an official language and as long as there are compliant compilers, you're good to go. The problem is you can define Forth portably in a high level language only if you give up on a lot of low level features, and speed. > >> (B2) We're actually not all that interested in C anyway --- what we >> would really like is to be able to take *any* language, transform it >> to a machine independent intermediate language, and then write out >> 'optimised' code to any given target machine. So what we're after is >> a universal middle-language, with reasonably sound translators from C, >> Fortran, C++, Objective-C, even Java, maybe even Python, into it, and >> then reasonably sound translators from this middle language into any >> of a vast number of machine languages. > >That part is a good goal for a compiler suite; however, this absolutely >requires that it is a well-specified portable assembler. C might be sloppy >about one's and two's complement, but Java e.g. isn't. In Java, bytes are 8 >bit bytes (yes, it has a data type called byte, which is a very sensible >thing to have!), integers are two's complement, with 32 bit size (longs 64), >and so on; if you want to compile Java, you must convert it to a much better >specified intermediate language, anyways. Because of the name I thought gForth was in bed with GNU. That suggests to me that gForth would be one of the programs that would be in the regression set of the GNU Compiler Collection. Apparently not. But it should, and I think it ludicrous if a GCC maintainer would think otherwise. > >> (B3) The only way to do the above is to be free to bend C into a >> reasonably conformant language so that the unlimited flexibility that >> C gives a programmer is restrained. Unlimited flexibility cannot be >> guaranteed to automaticaly convert correctly. Our mission is the >> automation of programming to allow a comprehensive abstraction layer >> to be able to sit between high level languages and the machine. > >Actually, you are free to do so. Wherever the C standard says "is >undefined", it's up to the implementor to specify what his compiler does. >He can say something, like "signed integers are two's complement, and they >wrap around on overflow". As a compiler should not intentionally break >existing programs, this also means that you don't have to write it down in >the spec: If it was that way in the past, you are not allowed to change it. > >I think we have to bite the bullet and at least write backends for popular >CPUs like amd64 and ARM (starting with v5). Of course this will be a Forth >compiler. For bootstrapping, our idea is to write a compiler for images, >i.e. you can turn an image into an engine, compiling only the things you >need. That means we will have everything every other compiler user will >need: an incremental compiler for JITs, and a batch compiler for images >(which would be the intermediate language). Turn the tables. Make Forth the implementation languages for C/C++ instead of the other way around. An interesting thought. > >-- >Bernd Paysan > Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-23 13:07 +0000 |
| Message-ID | <2014Apr23.150747@mips.complang.tuwien.ac.at> |
| In reply to | #29617 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Assad Ebrahim wrote:
>> Thanks for the interesting article reference.
>>
>> Is the below a fair representation of your and Bernd's point of view?
>>
>> (A1) we want some of the optimisations that optimising compilers
>> produce
>>
>> (A2) but we don't want them to do so at the expense of taking too
>> many liberties with the code
>
>Let's rephrase it: I want Forth's primitives to be tightly specified, i.e.
>there is not much place for "is undefined". Numbers are either unsigned or
>two's complement, and wrap around (Forth's dual use of + and - really makes
>only sense in two's complement). Addresses are either in memory, or they
>produce a -9 THROW on access.
>There are some corner cases, which Stephen called "the volatile issue": Is
>
>foo @ foo @
>
>identical to
>
>foo @ dup
>
>? Actually, it isn't. foo @ dup shall result in two times the same result,
>no matter if there is a race condition with another process, while foo @ foo
>@ *should* have different results in that case.
Other processes are not really the issue, at least not for this code,
because there is no guarantee that the other process gets a turn
between these two @s, even with sequential consistency. The issue
with this code is side effects on memory-mapped hardware.
In any case, if the programmer wants to write "foo @ dup", they can do
so, so there is little reason to "optimize" "foo @ foo @" into "foo @
dup", and if there are any reasons not to do it, we should refrain
from it.
Concerning other processes/threads, a more relevant issue is:
begin
foo @ until
Can we "optimize" this into
foo @ begin
dup until
drop
Unless the system is totally unfair and the other thread never
progresses, it will eventually reach the place that sets FOO, and then
the "optimization" has broken the program (by turning a not-too-unfair
system into a totally unfair system).
Again, if we really want that optimization, we can do it manually. It
becomes more complicated if more data is involved, so Forth
programmers may prefer to write
start-some-loop
.... bar @ ...
end-some-loop
even if BAR @ does not exercise side effects and BAR is not stored to
in another thread. Doing the BAR @ before the loop and storing the
result on the stack may cause too much stack juggling; locals are more
comfortable, but are still more cumbersome, plus there are some
anti-locals feelings in many Forth programmers. So yes, we may
eventually want to think about how we want to allow such an
optimization in Forth, and how to prevent it where not appropriate.
We also have to think about how to deal with all this broken "weak
consistency" hardware. My hope is that the hardware makers will
realize that they need to make their hardware programmable by other
people than gurus and implement sequential consistency eventually; it
worked for imprecise interrupts, and for distributed memory before,
maybe it will also work for weak consistency. Or maybe there will be
a solution where non-gurus don't have to concern themselves with
shared memory when they write multi-threaded programs.
>No, this C as portable assembler would just require to fix the specification
>(follow Lunyu 13.3), i.e. define what's left undefined by the standard.
For a language like C, doing that in every respect is not reasonable.
E.g., register allocation tends to change the arrangement of stuff in
memory or at least, what's stored there, and therefore what values are
returned or changed when you access memory beyond the contiguous
region (in Forth terminology) that the access is based on.
But treating every "undefined behaviour" as a license to miscompile is
not reasonable, either.
Richard Stallman had the perfect compromise in gcc-2.x. It performed
well and it behaved well.
- 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@xnothavet.cqm> |
|---|---|
| Date | 2014-04-23 20:16 -0400 |
| Message-ID | <op.xesoc1jp6zenlw@localhost> |
| In reply to | #29797 |
On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: [volatile issues in Forth] > In any case, if the programmer wants to write "foo @ dup", they can do > so, so there is little reason to "optimize" "foo @ foo @" into "foo @ > dup", and if there are any reasons not to do it, we should refrain > from it. How do you tell a Forth optimizer to selectively not optimize "foo @ foo @" into "foo @ dup"? Forth has no keyword like "volatile" in C to say: "Do not optimize this code." Conclusively, you must either: 1) disable all pointer based optimizations to prevent compiler optimization errors. (Didn't you just have a large rant on erroneous optimizations in C? ...) or, 2) implement a minimal type system in the optimizer so that when it recognizes "dup" in "foo @ dup" it can determine that the stack value is a pointer and do the opposite of optimizing, by converting "dup" into "foo @". Yes? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-23 14:41 -1000 |
| Message-ID | <p66dnZSH5pE2wMXOnZ2dnUVZ_rqdnZ2d@supernews.com> |
| In reply to | #29800 |
On 4/23/14 2:16 PM, Rod Pemberton wrote: > On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: > > [volatile issues in Forth] > >> In any case, if the programmer wants to write "foo @ dup", they can do >> so, so there is little reason to "optimize" "foo @ foo @" into "foo @ >> dup", and if there are any reasons not to do it, we should refrain >> from it. > > How do you tell a Forth optimizer to selectively not optimize > "foo @ foo @" into "foo @ dup"? Forth has no keyword like > "volatile" in C to say: "Do not optimize this code." Conclusively, > you must either: All the optimizing Forths I know have ways to turn the optimizer off and on. It's pretty much essential, for many reasons. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-24 17:10 +0000 |
| Message-ID | <2014Apr24.191024@mips.complang.tuwien.ac.at> |
| In reply to | #29800 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Wed, 23 Apr 2014 09:07:47 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>[volatile issues in Forth]
>
>> In any case, if the programmer wants to write "foo @ dup", they can do
>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @
>> dup", and if there are any reasons not to do it, we should refrain
>> from it.
>
>How do you tell a Forth optimizer to selectively not optimize
>"foo @ foo @" into "foo @ dup"?
Selectively?
As a programmer, I just write "foo @ foo @" if I want two loads from
memory, and "foo @ dup" if I want one. As a compiler writer, I just
mark @ as one of the words where common subexpression elimination (if
I implement it; seems questionable in Forth) is not applicable.
>1) disable all pointer based optimizations to prevent compiler
>optimization errors. (Didn't you just have a large rant on
>erroneous optimizations in C? ...)
Not sure what "pointer"-based optimizations you have in mind, but yes,
I would not "optimize" a @ away.
>2) implement a minimal type system in the optimizer so that when
>it recognizes "dup" in "foo @ dup" it can determine that the stack
>value is a pointer and do the opposite of optimizing, by converting
>"dup" into "foo @".
What would be the point of that? If the programmer writes "foo @
dup", the compiler should produce only one memory load.
- 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 | Spam@ControlQ.com |
|---|---|
| Date | 2014-04-24 15:14 -0400 |
| Message-ID | <alpine.BSF.2.00.1404241512470.58038@yoko.controlq.com> |
| In reply to | #29807 |
On Thu, 24 Apr 2014, Anton Ertl wrote: >> [volatile issues in Forth] >> >>> In any case, if the programmer wants to write "foo @ dup", they can do >>> so, so there is little reason to "optimize" "foo @ foo @" into "foo @ >>> dup", and if there are any reasons not to do it, we should refrain >>> from it. >> >> How do you tell a Forth optimizer to selectively not optimize >> "foo @ foo @" into "foo @ dup"? > > Selectively? > > As a programmer, I just write "foo @ foo @" if I want two loads from > memory, and "foo @ dup" if I want one. As a compiler writer, I just > mark @ as one of the words where common subexpression elimination (if > I implement it; seems questionable in Forth) is not applicable. > >> 1) disable all pointer based optimizations to prevent compiler >> optimization errors. (Didn't you just have a large rant on >> erroneous optimizations in C? ...) > > Not sure what "pointer"-based optimizations you have in mind, but yes, > I would not "optimize" a @ away. > >> 2) implement a minimal type system in the optimizer so that when >> it recognizes "dup" in "foo @ dup" it can determine that the stack >> value is a pointer and do the opposite of optimizing, by converting >> "dup" into "foo @". > > What would be the point of that? If the programmer writes "foo @ > dup", the compiler should produce only one memory load. > > - anton > Miniforth distinguishes between a regular memory @ and a register (volatile) fetch by having a second word r@ to obtain register values. Any future optimiser would optimise @ and pessimise r@ ... Cheers, Rob.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 08:40 +0000 |
| Subject | @ and optimization (was: Epic Fail) |
| Message-ID | <2014Apr25.104047@mips.complang.tuwien.ac.at> |
| In reply to | #29809 |
Spam@ControlQ.com writes:
>Miniforth distinguishes between a regular memory @ and a register
>(volatile) fetch by having a second word r@ to obtain register values.
>Any future optimiser would optimise @ and pessimise r@ ...
Given that there is a standard word R@, the naming of your r@ is a bad
idea.
Apart from that: Sure, one can add language features that allow some
optimizations. But if the "optimization" would break existing code,
the way to go is to have a new word that is optimizable, and the
existing word is not.
Furthermore, just saying that, say, "o@ is an optimizable @" does not
really tell the programmer what o@ will do or the compiler writer what
the compiler is allowed to optimize. You need to specify what o@ (or
whatever) is guaranteed to do.
In particular, optimizing @ has come up a number of times over the
years. One idea I had was @CONST, which would be applicable if we
knew that the data at the address will never change, e.g.:
: constant ( n -- )
create ,
does>
@const ;
Another idea (from Stephen Pelc) is to declare certain memory areas as
read-only, e.g.:
: constant ( n -- )
create here swap , 1 cells read-only
does>
@ ;
That is good for data that is in memory permanently. For
non-permanent data, e.g., ALLOCATEd data that may be FREEd, I don't
see how to implement READ-ONLY efficiently. But we may want to
perform certain optimizations for such data, too, e.g., pulling a read
out of a loop. OTOH, at the moment I cannot think of such an
optimization that cannot be coded in Forth directly without too much
effort, so maybe READ-ONLY is good enough.
Still, the thoughts I had on the issue were along the lines of
declaring to the compiler that the data in a certain contiguous region
won't change in a certain part of the program. I thought up two ways
of specifying that:
1) A typical code-boundary (block) based way:
( addr ) ro-begin
...
ro-end
would assert that none of the data in the contiguous region pointed
to by addr would change between ro-begin and ro-end.
2) A data-flow-oriented way:
ro-addr ( addr -- addr )
would assert that none of the data in the contiguous region pointed to
by addr would change while any address derived by adding something to
the addr returned by ro-addr still exists.
A compiler would need serious work to be able to benefit from this.
It's unclear how much benefit can be derived from that, so it probably
does not pay of to go there. READ-ONLY for permanent data does look
better wrt cost/benefit.
- 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-04-25 06:13 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <a6SdnYK-E8vp3sfOnZ2dnUVZ_vednZ2d@supernews.com> |
| In reply to | #29821 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Spam@ControlQ.com writes: >>Miniforth distinguishes between a regular memory @ and a register >>(volatile) fetch by having a second word r@ to obtain register values. >>Any future optimiser would optimise @ and pessimise r@ ... > > Given that there is a standard word R@, the naming of your r@ is a bad > idea. > > Apart from that: Sure, one can add language features that allow some > optimizations. But if the "optimization" would break existing code, > the way to go is to have a new word that is optimizable, and the > existing word is not. > > Furthermore, just saying that, say, "o@ is an optimizable @" does not > really tell the programmer what o@ will do or the compiler writer what > the compiler is allowed to optimize. You need to specify what o@ (or > whatever) is guaranteed to do. > > In particular, optimizing @ has come up a number of times over the > years. One idea I had was @CONST, which would be applicable if we > knew that the data at the address will never change, e.g.: > > : constant ( n -- ) > create , > does> > @const ; > > Another idea (from Stephen Pelc) is to declare certain memory areas as > read-only, e.g.: > > : constant ( n -- ) > create here swap , 1 cells read-only > does> > @ ; IMO, the Right Way to do it is to have explicit read and write barriers. These would insert barrier instructions on machines that need them and an optimization barrier on machines that don't. So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the rare case where you actually must read from foo twice, and this is guaranteed to do so even on machines with relaxed memory ordering. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 15:26 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr25.172651@mips.complang.tuwien.ac.at> |
| In reply to | #29822 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> In particular, optimizing @ has come up a number of times over the
>> years. One idea I had was @CONST, which would be applicable if we
>> knew that the data at the address will never change, e.g.:
>>
>> : constant ( n -- )
>> create ,
>> does>
>> @const ;
>>
>> Another idea (from Stephen Pelc) is to declare certain memory areas as
>> read-only, e.g.:
>>
>> : constant ( n -- )
>> create here swap , 1 cells read-only
>> does>
>> @ ;
>
>IMO, the Right Way to do it is to have explicit read and write
>barriers. These would insert barrier instructions on machines that
>need them and an optimization barrier on machines that don't.
After successfully destroying C, it looks like you are on the search
for a new target. You will have a harder time with Forth, though.
>So,
>your "foo @ foo @" could be "foo @ read-barrier foo @" in the rare
>case where you actually must read from foo twice, and this is
>guaranteed to do so even on machines with relaxed memory ordering.
"Relaxed memory ordering" does not have anything to do with it. Even
the most broken machine will not do the second "foo @" before the
first "foo @".
There is no reason to "optimize" "foo @ foo @" into "foo @ dup",
because we can write "foo @ dup" directly. Therefore we don't need an
optimization barrier when we write "foo @ foo @".
In any case, this idea of "optimizing" "foo @ foo @" into "foo @ dup"
has nothing to do with the @CONST and READ-ONLY ideas. It cannot
replace the example above.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-25 09:03 -0700 |
| Subject | Re: @ and optimization |
| Message-ID | <7xd2g5qtui.fsf@ruckus.brouhaha.com> |
| In reply to | #29827 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > There is no reason to "optimize" "foo @ foo @" into "foo @ dup", > because we can write "foo @ dup" directly. The two "foo @" might each be the result of a macro expansion. So if the compiler doesn't optimize it, the user program may have to do contorted things to get the optimization manually. There are also fancier cases where the two "foo @" may not be directly adjacent like that, and "foo" along with other variables are used to avoid stack juggling. Turning that into register code is precisely what an optimizing compiler is supposed to do, I thought.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 17:45 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr25.194544@mips.complang.tuwien.ac.at> |
| In reply to | #29829 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> There is no reason to "optimize" "foo @ foo @" into "foo @ dup",
>> because we can write "foo @ dup" directly.
>
>The two "foo @" might each be the result of a macro expansion.
>So if the compiler doesn't optimize it, the user program may have
>to do contorted things to get the optimization manually.
>There are also fancier cases where the two "foo @" may not
>be directly adjacent like that, and "foo" along with other
>variables are used to avoid stack juggling. Turning that
>into register code is precisely what an optimizing compiler
>is supposed to do, I thought.
As long as the result does not change behaviour, fine. But if you
need an "optimization barrier" (actually a miscompilation barrier),
that's obviously not the case.
Concerning cases where you have lots of "foo @" close enough to each
other that such an optimization would make a significant impact, that
does not occur in my code; so I am pretty sure that you don't have to
do contorted things to avoid it. Anyway, if we wanted that, the way
to go would be to give a hint to the compiler that it is allowed to do
this optimization there, instead of doing that transformation by
default and requiring the programmers to add miscompilation barriers
in previously working code.
- 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-04-25 11:15 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <EMWdnX9FbqCCF8fOnZ2dnUVZ_sidnZ2d@supernews.com> |
| In reply to | #29827 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> In particular, optimizing @ has come up a number of times over the >>> years. One idea I had was @CONST, which would be applicable if we >>> knew that the data at the address will never change, e.g.: >>> >>> : constant ( n -- ) >>> create , >>> does> >>> @const ; >>> >>> Another idea (from Stephen Pelc) is to declare certain memory areas as >>> read-only, e.g.: >>> >>> : constant ( n -- ) >>> create here swap , 1 cells read-only >>> does> >>> @ ; >> >>IMO, the Right Way to do it is to have explicit read and write >>barriers. These would insert barrier instructions on machines that >>need them and an optimization barrier on machines that don't. > > After successfully destroying C, it looks like you are on the search > for a new target. You will have a harder time with Forth, though. Oh come on Anton, you don't have to turn every discussion with me into a fight. It really isn't necessary. That's not my intention. The Forth tradition has always been a fairly thin layer of the underlying hardware, and explicit barriers are a good fit with that. >>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the >>rare case where you actually must read from foo twice, and this is >>guaranteed to do so even on machines with relaxed memory ordering. > > "Relaxed memory ordering" does not have anything to do with it. Huh? In this case it does. > Even the most broken machine will not do the second "foo @" before > the first "foo @". Actually, I'm not sure about Alpha, but everything else won't AFAIK. > There is no reason to "optimize" "foo @ foo @" into "foo @ dup", > because we can write "foo @ dup" directly. Therefore we don't need an > optimization barrier when we write "foo @ foo @". Sure, but as discussed, a) people already write Forth optimizers which make this transformation, and b) even if they don't the hardware may replace two fetches from the same address with a single one. And this is not "weird" hardware, but almost every modern (32 bits and up) design. Even the venerable x86 needs a StoreLoad barrier if you want sequential consistency. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-25 17:22 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr25.192230@mips.complang.tuwien.ac.at> |
| In reply to | #29830 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>IMO, the Right Way to do it is to have explicit read and write
>>>barriers. These would insert barrier instructions on machines that
>>>need them and an optimization barrier on machines that don't.
>>
>> After successfully destroying C, it looks like you are on the search
>> for a new target. You will have a harder time with Forth, though.
>
>Oh come on Anton, you don't have to turn every discussion with me into
>a fight. It really isn't necessary.
It is. The idea of miscompiling by default, and asking the programmer
to insert a miscompilation barrier (if it was really just an
optimization, there would be no point in disabling it) to prevent that
is just a bad idea.
>That's not my intention. The Forth tradition has always been a fairly
>thin layer of the underlying hardware, and explicit barriers are a
>good fit with that.
Sure, if you have broken hardware, and these barriers are a way to get
it to behave better, barriers may be the way to go.
However, that's not what you proposed. What you proposed is that the
broken hardware is the justification for turning the compiler into a
miscompiler, even on non-broken hardware, and that the programmer
should now make the miscompiler behave with these barriers.
And yes, exactly because Forth is a thin layer over the hardware, we
don't need such "optimizations". If the programmer wants to write
"foo @ dup", he does not need an "optimizer" for that.
>>>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the
>>>rare case where you actually must read from foo twice, and this is
>>>guaranteed to do so even on machines with relaxed memory ordering.
>>
>> "Relaxed memory ordering" does not have anything to do with it.
>
>Huh? In this case it does.
>
>> Even the most broken machine will not do the second "foo @" before
>> the first "foo @".
>
>Actually, I'm not sure about Alpha, but everything else won't AFAIK.
So you cannot name a single machine where relaxed memory ordering has
anything to do with it.
>> There is no reason to "optimize" "foo @ foo @" into "foo @ dup",
>> because we can write "foo @ dup" directly. Therefore we don't need an
>> optimization barrier when we write "foo @ foo @".
>
>Sure, but as discussed, a) people already write Forth optimizers which
>make this transformation,
People should fix bugs in their optimizers, and Stephen Pelc has done
so.
>and b) even if they don't the hardware may
>replace two fetches from the same address with a single one. And this
>is not "weird" hardware, but almost every modern (32 bits and up)
>design. Even the venerable x86 needs a StoreLoad barrier if you want
>sequential consistency.
Memory ordering/sequential consistency has nothing to do with this, as
established above. And sure, if you have two loads from the same
addresses in cached memory, the second one will be served from the
cache. But devices that have a side effect on reading are not in
cached memory, and two loads will result in two accesses (and two
times the side effect).
- 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-04-26 04:38 -0500 |
| Subject | Re: @ and optimization |
| Message-ID | <GqidnSV21dI148bOnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #29832 |
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: >>>>IMO, the Right Way to do it is to have explicit read and write >>>>barriers. These would insert barrier instructions on machines that >>>>need them and an optimization barrier on machines that don't. >>> >>> After successfully destroying C, it looks like you are on the search >>> for a new target. You will have a harder time with Forth, though. >> >>Oh come on Anton, you don't have to turn every discussion with me into >>a fight. It really isn't necessary. > > It is. The idea of miscompiling by default, and asking the programmer > to insert a miscompilation barrier (if it was really just an > optimization, there would be no point in disabling it) to prevent that > is just a bad idea. OK, that is a technical opinion, and one that can be reasoned about and discussed. It's not necessary to be insulting and emotional, and it does not help your case. >>That's not my intention. The Forth tradition has always been a fairly >>thin layer of the underlying hardware, and explicit barriers are a >>good fit with that. > > Sure, if you have broken hardware, and these barriers are a way to get > it to behave better, barriers may be the way to go. OK. That's a start, at least. > However, that's not what you proposed. What you proposed is that the > broken hardware is the justification for turning the compiler into a > miscompiler, even on non-broken hardware, and that the programmer > should now make the miscompiler behave with these barriers. Do we agree that Forth, as defined, uses "as if" semantics? I think we must, because no-one is suggesting that the stack really has to be implemented as a stack: all stack accesses may be converted to a series of register moves. So, "as if" semantics apply, and merging memory accesses is arguably a legitimate thing for a compiler to do. You can only reasonably describe this as "miscompiling" if you define your memory model. That is hard because it forces you to confront the reality of today's hardware. In other words: it requires work, not just shouting. And it requires some difficult tradeoffs. > And yes, exactly because Forth is a thin layer over the hardware, we > don't need such "optimizations". If the programmer wants to write > "foo @ dup", he does not need an "optimizer" for that. > >>>>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the >>>>rare case where you actually must read from foo twice, and this is >>>>guaranteed to do so even on machines with relaxed memory ordering. >>> >>> "Relaxed memory ordering" does not have anything to do with it. >> >>Huh? In this case it does. >> >>> Even the most broken machine will not do the second "foo @" before >>> the first "foo @". >> >>Actually, I'm not sure about Alpha, but everything else won't AFAIK. > > So you cannot name a single machine where relaxed memory ordering has > anything to do with it. Huh? You've lost me. I think we must be talking at cross purposes. >>and b) even if they don't the hardware may replace two fetches from >>the same address with a single one. And this is not "weird" >>hardware, but almost every modern (32 bits and up) design. Even the >>venerable x86 needs a StoreLoad barrier if you want sequential >>consistency. > > Memory ordering/sequential consistency has nothing to do with this, as > established above. And sure, if you have two loads from the same > addresses in cached memory, the second one will be served from the > cache. How is that different in effect from converting "foo @ foo @" into "foo @ dup" ? > But devices that have a side effect on reading are not in cached > memory, and two loads will result in two accesses (and two times the > side effect). I agree. Memory-mapped I/O is inherently non-portable and cannot be discussed outside the context of a particular physical system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-26 11:38 +0000 |
| Subject | Re: @ and optimization |
| Message-ID | <2014Apr26.133848@mips.complang.tuwien.ac.at> |
| In reply to | #29851 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Do we agree that Forth, as defined, uses "as if" semantics? I think
>we must, because no-one is suggesting that the stack really has to be
>implemented as a stack
You mean, as a memory-area plus stack pointer (as on most hardware)?
As a hardware stack (as on Chuck Moore's chips)?
>all stack accesses may be converted to a
>series of register moves.
Not in general.
>So, "as if" semantics apply, and merging
>memory accesses is arguably a legitimate thing for a compiler to do.
>You can only reasonably describe this as "miscompiling" if you define
>your memory model.
That's not necessary. If it produces a different behaviour than the
original code, it's not a legitimate thing for a compiler to do. That
follows directly from the as-if rule. No need for me to define a
memory model; that has been done by the hardware maker.
Your suggestion that an "optimization barrier" would be needed is an
admission that the as-if rule does not hold for the "optimization".
>That is hard because it forces you to confront the
>reality of today's hardware.
I don't find it particularly hard, and side effects on reading from an
I/O device have existed for over 30 years.
>>>>>So, your "foo @ foo @" could be "foo @ read-barrier foo @" in the
>>>>>rare case where you actually must read from foo twice, and this is
>>>>>guaranteed to do so even on machines with relaxed memory ordering.
>>>>
>>>> "Relaxed memory ordering" does not have anything to do with it.
>>>
>>>Huh? In this case it does.
>>>
>>>> Even the most broken machine will not do the second "foo @" before
>>>> the first "foo @".
>>>
>>>Actually, I'm not sure about Alpha, but everything else won't AFAIK.
>>
>> So you cannot name a single machine where relaxed memory ordering has
>> anything to do with it.
>
>Huh? You've lost me.
Read again, and (if necessary) ask concrete questions!
>>>and b) even if they don't the hardware may replace two fetches from
>>>the same address with a single one. And this is not "weird"
>>>hardware, but almost every modern (32 bits and up) design. Even the
>>>venerable x86 needs a StoreLoad barrier if you want sequential
>>>consistency.
>>
>> Memory ordering/sequential consistency has nothing to do with this, as
>> established above. And sure, if you have two loads from the same
>> addresses in cached memory, the second one will be served from the
>> cache.
>
>How is that different in effect from converting "foo @ foo @" into
>"foo @ dup" ?
The difference is that the compiler doesn't know that FOO points to
cached memory.
>> But devices that have a side effect on reading are not in cached
>> memory, and two loads will result in two accesses (and two times the
>> side effect).
>
>I agree. Memory-mapped I/O is inherently non-portable and cannot be
>discussed outside the context of a particular physical system.
Sure it can. We are doing so. And while programs doing memory-mapped
I/O may not be portable to platforms that don't have the device, they
can be portable across machines that have the device, and across
different Forth implementations on these machines.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
Page 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web