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 2 of 19 — ← Prev page 1 [2] 3 4 … 19 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-10 22:35 +0200 |
| Message-ID | <li6vap$9pl$1@online.de> |
| In reply to | #29501 |
hughaguilar96@yahoo.com wrote:
> And how about the issue of LOCALS| having the names backwards? That is a
> real WTF?-inducing moment for the reader of the ANS-Forth document. I
> fixed this problem in the novice package with {. It was not difficult.
Yes, we all fixed this problem with {. And it even became part of Forth200x
(under the name {:, because some people used { for comments, and we don't
want to break their code... but I think that name was a failure: Everybody
still uses { for locals, and no Forth I have here implements {: - we should
admit defeat by inertia, and { has been the right name for locals for the
last 20 years, and those fools who have used { for something else should pay
the price for their ignorance ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-10 17:51 -0700 |
| Message-ID | <00402916-1579-4aa2-8504-7d7175ebc06d@googlegroups.com> |
| In reply to | #29513 |
On Thursday, April 10, 2014 1:35:36 PM UTC-7, Bernd Paysan wrote:
> hughaguilar96@yahoo.com wrote:
>
> > And how about the issue of LOCALS| having the names backwards? That is a
> > real WTF?-inducing moment for the reader of the ANS-Forth document. I
> > fixed this problem in the novice package with {. It was not difficult.
>
> Yes, we all fixed this problem with {. And it even became part of Forth200x
> (under the name {: ...
ANS-Forth came out in 1994. This is 2014. That is 20 years.
Lets imagine an parallel universe in which Kernighan and Ritchie defined C to have the parameters backwards (names of parameters in a function declaration are backwards to the order that the parameters are given in the function call). Many decades go by, and during that time K&R say: "Well, um, we couldn't figure out how to make it work correctly, so just get used to doing it backwards --- or write a preprocessor if you really want it to make sense, although be aware that everybody's preprocessor is going to be subtly different from everybody else's, as preprocessing is not part of the C standard." Also, in this parallel universe, Elizabeth Rather has enough brains to define LOCALS| correctly in the ANS-Forth standard. So, in the year 2014, which language is popular and which is considered to be a toy?
Also, btw, Anton Ertl wrote {: and I never got it to work for me, because I have SwiftForth v2 that crashes whenever (LOCAL) is used. This is why my { uses LOCALS| internally --- so it won't crash under SwiftForth v2. My whole novice package is full of work-arounds for bugs in Forth implementations and bad design in ANS-Forth. My novice package is more practical than Anton Ertl's ivory-tower code that doesn't take into account the bugs in SwiftForth --- but Elizabeth Rather has not yet thanked me for helping her customers work around the bugs in SwiftForth --- instead she installs Anton Ertl as the puppet-ruler of the Forth-200x committee.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2014-04-10 21:44 -0700 |
| Message-ID | <a8ffe081-3390-4708-b1e2-dddfe74fd739@googlegroups.com> |
| In reply to | #29513 |
> Yes, we all fixed this problem with {. And it even became part of Forth200x
>
> (under the name {:, because some people used { for comments, and we don't
>
> want to break their code... but I think that name was a failure: Everybody
>
> still uses { for locals, and no Forth I have here implements {: - we should
>
> admit defeat by inertia, and { has been the right name for locals for the
>
> last 20 years, and those fools who have used { for something else should pay
>
> the price for their ignorance ;-).
>
agreed
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-11 23:10 -0700 |
| Message-ID | <4cde73fc-f677-4377-ac78-7f81ee13ae65@googlegroups.com> |
| In reply to | #29513 |
On Thursday, April 10, 2014 1:35:36 PM UTC-7, Bernd Paysan wrote:
> hughaguilar96@yahoo.com wrote:
>
> > And how about the issue of LOCALS| having the names backwards? That is a
> > real WTF?-inducing moment for the reader of the ANS-Forth document. I
> > fixed this problem in the novice package with {. It was not difficult.
>
> Yes, we all fixed this problem with {. And it even became part of Forth200x
> (under the name {:, because some people used { for comments, and we don't
> want to break their code... but I think that name was a failure: Everybody
> still uses { for locals, and no Forth I have here implements {: - we should
> admit defeat by inertia, and { has been the right name for locals for the
> last 20 years, and those fools who have used { for something else should pay
> the price for their ignorance ;-).
The "fools" who used { for multi-line comments were Forth Inc.. AFAIK, SwiftForth is the only Forth system that does this. As you say, pretty much everybody uses { for locals, and has done so for the last 20 years. Anton Ertl assumes that everything in SwiftForth is Forth-200x standard by default, which is why he had to use the ugly and difficult to type {: for locals.
Note that in my novice package I provide COMMENT for multi-line comments. This is a nice self-documenting name.
By far however, the biggest blunder that Anton Ertl made in his {: was to make the initial values of the locals "undefined." WTF??? This is an incredibly bad idea. On one compiler they may get initialized to zero, and on another to something else. Also, they may get initialized to whatever happened to be in memory, so this will be a pretty much random value from one run of the program to the next. The danger here is that the programmer may have a bug in his program in that he uses a local without explicitly initializing it. The problem is that this may work sometimes, if the local happens to be automatically initialized to a value that works, and may not work sometimes, if the local happens to be automatically initialized to a value that doesn't work. A bug like this will be very difficult to catch! The program will sometimes work and sometimes crash. Even worse, the program may work for months, and then suddenly stop working because something caused the locals to get initialized to different random numbers than before. Anton Ertl's undefined initialization values are stupid! They should be defined to be initialized to some specific value (I use zero) just so they are always the same. I would really expect even the most novice programmer to understand this simple idea. I told Anton about this problem when he first wrote his {: word, but Elizabeth Rather predictably said that I was wrong and Anton was right, so Anton stuck with his undefined initialization values. It is possible that he understood what I told him (he's not a complete idiot), but he can't contradict Elizabeth Rather if he wants to continue to be allowed to be a big chief on the Forth-200x committee, so he had to play dumb and pretend that he didn't understand --- that is why {: is going into the Forth-200x standard with undefined initialization values.
BTW: If I am a troll, then why am I the only person discussing Forth in this thread? A discussion of C is off-topic --- recall that the topic is "Epic Fail" --- the "epic fail" was of ANS-Forth, not C. This forum is comp.lang.forth not comp.lang.c --- we are supposed pretty much stick to Forth. Nobody here really cares about C except Anton Ertl and Rod Pemberton, because they implemented their Forth systems in C --- but implementing a Forth system in C is utter foolishness! --- so C is a topic that Forthers can largely ignore (that is pretty much the point of being a Forther).
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-12 06:18 -0400 |
| Message-ID | <op.xd679uym6zenlw@localhost> |
| In reply to | #29554 |
On Sat, 12 Apr 2014 02:10:50 -0400, <hughaguilar96@yahoo.com> wrote:
> By far however, the biggest blunder that Anton Ertl made in his {: was
> to make the initial values of the locals "undefined." WTF??? This is an
> incredibly bad idea. On one compiler they may get initialized to zero,
> and on another to something else. Also, they may get initialized to
> whatever happened to be in memory, so this will be a pretty much random
> value from one run of the program to the next. The danger here is that
> the programmer may have a bug in his program in that he uses a local
> without explicitly initializing it.
If that's true Hugh, I'd agree with you, in general. But, I'm coming from
the C perspective that these should be treated like ? and cleared. Of
course,
C doesn't automatically clear auto or procedure local variables, which
requires
the programmer to do so. So, it's entirely possible that Forth should
treat
them the way Anton did too.
> BTW: If I am a troll, then why am I the only person discussing Forth in
> this thread?
I've brought that up many times. No one here discusses Forth. Well, a
few people do on occasion, but the majority generally don't, including
those who criticize others for not discussing Forth.
But, I'll discuss Forth if you like. What's a trivial way to implement
a Forth optimizer in Forth? Maybe, put ten numbers, 0 to 9, on the stack,
then redefine math and binary operations to do nothing, then execute a
sequence of stack, math, and binary operations, and emit the stack (.S)
to see the final order? How do you determine the lowest cost sequence? ...
Drop the results back into a stack optimizer?
> Nobody here really cares about C except Anton Ertl and Rod Pemberton,
> [...]
What about Paul Rubin?
> Nobody here really cares about C except Anton Ertl and Rod Pemberton,
> because they implemented their Forth systems in C --- but implementing
> Forth system in C is utter foolishness!
No, it's not. The way most C's in Forth are implemented is foolish.
Those are done the C way, if you could call it that. But, I implemented
mine the Forth way. It's implemented exactly like you would in assembly.
This must be like the thirtieth time I've mentioned that now ...
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-12 06:23 -0400 |
| Message-ID | <op.xd68gnzt6zenlw@localhost> |
| In reply to | #29558 |
On Sat, 12 Apr 2014 06:18:56 -0400, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: (correction) > If that's true Hugh, I'd agree with you, in general. But, I'm coming > from the C perspective that these should be treated like ? and cleared. s/?/an unitialized global variable/ RP
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-12 10:52 -0700 |
| Message-ID | <7bde558d-6b98-4de9-b13f-ff87c51f3faf@googlegroups.com> |
| In reply to | #29558 |
On Saturday, April 12, 2014 3:18:56 AM UTC-7, Rod Pemberton wrote:
> On Sat, 12 Apr 2014 02:10:50 -0400, <hughaguilar96@yahoo.com> wrote:
> > By far however, the biggest blunder that Anton Ertl made in his {: was
> > to make the initial values of the locals "undefined." WTF??? This is an
> > incredibly bad idea. On one compiler they may get initialized to zero,
> > and on another to something else. Also, they may get initialized to
> > whatever happened to be in memory, so this will be a pretty much random
> > value from one run of the program to the next. The danger here is that
> > the programmer may have a bug in his program in that he uses a local
> > without explicitly initializing it.
> If that's true Hugh, I'd agree with you, in general. But, I'm coming from
> the C perspective that these should be treated like ? and cleared. Of
> course,
> C doesn't automatically clear auto or procedure local variables, which
> requires
> the programmer to do so. So, it's entirely possible that Forth should
> treat
> them the way Anton did too.
I have worked as a C/C++ programmer, so I'm familiar with the language. I know that locals in C are initialized to whatever happened to be in memory. This is one of the many cases in which K&R chose speed-optimization over reliability. The fact that C treats locals this way, does not mean that Forth "should" treat locals this way --- C is not the "god language" --- C is just a 1970s-vintage effort at making a compiler produce faster code than what the Pascal compilers were producing.
There is no reason why Forth should follow C's lead --- C wasn't all that great.
> > Nobody here really cares about C except Anton Ertl and Rod Pemberton,
> > [...]
>
> What about Paul Rubin?
Paul Rubin cares about Haskell --- he is way too high-brow to care about C --- I have no idea why he is interested in Forth, and I'm not aware of him having ever written a Forth program in his life.
He likely hangs out on comp.lang.forth because he has too much free time on his hands --- although that could be said of all of us --- comp.lang.forth is a huge waste of time.
> > Nobody here really cares about C except Anton Ertl and Rod Pemberton,
> > because they implemented their Forth systems in C --- but implementing
> > Forth system in C is utter foolishness!
>
> No, it's not. The way most C's in Forth are implemented is foolish.
> Those are done the C way, if you could call it that. But, I implemented
> mine the Forth way. It's implemented exactly like you would in assembly.
> This must be like the thirtieth time I've mentioned that now ...
If you've told me this 30 times and I still don't believe it, then maybe you should find a more productive hobby --- like teaching pigs to sing.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.invalid> |
|---|---|
| Date | 2014-04-12 20:14 +0200 |
| Message-ID | <libvqa$3kj$1@solani.org> |
| In reply to | #29580 |
On Sat, 12 Apr 2014 10:52:06 -0700 (PDT) hughaguilar96@yahoo.com wrote: > comp.lang.forth is a huge waste of time. > I don't think so. Lot of interesting things here. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-12 19:21 -0400 |
| Message-ID | <op.xd78hcfe6zenlw@localhost> |
| In reply to | #29580 |
On Sat, 12 Apr 2014 13:52:06 -0400, <hughaguilar96@yahoo.com> wrote: > I know that locals in C are initialized to whatever happened to be in > memory. This is one of the many cases in which K&R chose > speed-optimization over reliability. Typically, locals are immediately set to a value. If not, they're typically set to a value at a later time, sometimes more than one possible value later. So, why clear always? > If you've told me this 30 times and I still don't believe it, then maybe > you should find a more productive hobby --- like teaching pigs to sing. Well, if they can make floppy drives sing, like this: http://www.youtube.com/watch?v=b6Pj9IlOxQc I guess pigs would work too ... For pigs, I'd think you'd need to have multiple feeders that would respond to a variety of different grunts. If pigs are even slightly selective in their food choices, or perhaps prefer liquids then solids, with many pigs, you'd have a single instrument orchestra, with a limited range of notes, a variety of sounds, and an improvised song: OOOooIIIIInk, oink, oink, oink, Oink, oink, oink, ... Why does that sound like a Rickroll? Of course, this is the modern era. So, it'd be easier to sample the 'oink', and generate changes to the note pitch and amplitude via a DSP or software Fourier transforms, etc. Was that an echo of you saying we don't discuss Forth? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-13 12:25 -0500 |
| Message-ID | <BIednWstufwRVdfOnZ2dnUVZ_vydnZ2d@supernews.com> |
| In reply to | #29558 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > But, I'm coming from the C perspective that [locals] should be > treated like ? and cleared. Of course, C doesn't automatically > clear auto or procedure local variables, which requires the > programmer to do so. So, it's entirely possible that Forth should > treat them the way Anton did too. Hold on, are you saying that you think that locals should be zeroed, but C doesn't do so, therefore not zeroing Forth locals should be okay? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-04-13 20:33 -0400 |
| Message-ID | <op.xd96hvwf6zenlw@localhost> |
| In reply to | #29614 |
On Sun, 13 Apr 2014 13:25:32 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> But, I'm coming from the C perspective that [locals] should be >> treated like [an unitialized global variable] and cleared. Of course, >> C doesn't automatically clear auto or procedure local variables, >> which requires the programmer to do so. So, it's entirely possible >> that Forth should treat them the way Anton did too. > > Hold on, are you saying that you think that locals should be zeroed, [RP's posted correction inserted above] Yes. It's a safety issue. Although they're technically locals, they also seem somewhat similar to globals in C which are cleared. > but C doesn't do so, Yes. C doesn't clear locals. But, locals in C are typically initialized at some point by the programmer, and usually safely. I.e., it's a slight potential safety issue to not clear locals in C since they can be used without being initialized. However, that's generally infrequent. C compilers are generally pretty good at warning about unused and unitialized procedure locals too. I.e., there is a safety check in place on their use: the C compiler. > therefore not zeroing Forth locals should be okay? s/should/could/ s/okay/acceptable in Forth/ If Forth programmers typically init the locals in a safe manner, then, obviously, clearing them is not needed at all. But, ISTM that it makes more sense to treat them as globals and clear. Why? How are you going to require they're initialized prior to usage? ... If, as I suspect, that's not easy to implement in Forth or across a variety of Forths, then it's far better to clear. Do any Forths emit warnings for use of unitialized locals? ... If, as I suspect, none do, then it's far better to clear. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-04-12 16:12 +0000 |
| Message-ID | <53496291.222039920@news.demon.co.uk> |
| In reply to | #29554 |
On Fri, 11 Apr 2014 23:10:50 -0700 (PDT), hughaguilar96@yahoo.com
wrote:
<somebody>
>assumes that everything in SwiftForth is Forth-200x standard by default, w=
>hich is why he had to use the ugly and difficult to type {: for locals.
Just for the record, Leon Wagner suggested {: ... :} which is actually
easier to distinguish than { even with syntax colouring.
>By far however, the biggest blunder that Anton Ertl made in his {: was to m=
>ake the initial values of the locals "undefined." WTF??? This is an incredi=
>bly bad idea.
Actually it's an incredibly good idea. Initialised data can be
specified as inputs, and uninitialised locals are faster to set up.
In addition, common practice was for locals between '|' and -- to
be uninitialised. MPE's locals in ProForth and VFX Forth have worked
that way for over 20 years.
: foo {: i1 i2 i3 | l4 l5 -- x :}
If you want l4 and l5 to be initialised, the following declaration
works on all systems I have tested:
: foo 0 0 {: i1 i2 i3 l4 l5 -- x :}
I am a fan of "crash early and crash often" for debugging. Bugs that
lead to crashes will get fixed, whereas defensive implementation leads
to bad programming practice. Far better to be explicit that such
locals must be initialised by the programmer.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-12 09:48 -0700 |
| Message-ID | <7xppkm7au4.fsf@ruckus.brouhaha.com> |
| In reply to | #29571 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
> : foo {: i1 i2 i3 | l4 l5 -- x :}
> I am a fan of "crash early and crash often" for debugging. Bugs that
> lead to crashes will get fixed,
That's nice, but how does the uninitialised value force a crash?
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2014-04-12 10:23 -0700 |
| Message-ID | <ce9c4724-b484-4487-8bbe-f2b96330fc6b@googlegroups.com> |
| In reply to | #29573 |
>
> > : foo {: i1 i2 i3 | l4 l5 -- x :}
>
> > I am a fan of "crash early and crash often" for debugging. Bugs that
>
> > lead to crashes will get fixed,
IMHO, it doesn't make sense not to initialize local variables. The only reason to have them is mostly to access values without stack acrobatics. So prepare them on the parameter stack, declare & initialize them (in one step) and use them. KISS
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-04-12 19:51 +0000 |
| Message-ID | <534998b0.235895523@news.demon.co.uk> |
| In reply to | #29573 |
On Sat, 12 Apr 2014 09:48:35 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:
>stephenXXX@mpeforth.com (Stephen Pelc) writes:
>> : foo {: i1 i2 i3 | l4 l5 -- x :}
>> I am a fan of "crash early and crash often" for debugging. Bugs that
>> lead to crashes will get fixed,
>
>That's nice, but how does the uninitialised value force a crash?
Because there's a good chance it's an invalid address. However, 0 is
too on most systems. My point is more about defensive implementations.
When we moved from the previous ProForth (defensive) to VFX Forth
(fast and brutal), the conclusion after porting a very large
application was that using VFX revealed a large number of bugs that
had been lurking for many years.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-12 13:00 -0700 |
| Message-ID | <7xob06uxlf.fsf@ruckus.brouhaha.com> |
| In reply to | #29586 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: >>That's nice, but how does the uninitialised value force a crash? > Because there's a good chance it's an invalid address. However, 0 is > too on most systems. But why not do what gforth does? Always initialize locals from stack slots. > When we moved from the previous ProForth (defensive) to VFX Forth > (fast and brutal), the conclusion... was that using VFX revealed a > large number of bugs that had been lurking for many years. I hadn't thought of it this way before, but this seems to say that the "defensive" implementation accepted invalid data and quietly patched it to a value more likely to escape detection, while the "brutal" version acted non-deterministically, which resulted in a number of crashes that at least got noticed and debugged. I guess that has some merit, but better to prevent the invalid data from getting there in the first place.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-12 10:29 -0700 |
| Message-ID | <70ed1dd9-1af7-4a69-8fb2-a8ffe73d1bed@googlegroups.com> |
| In reply to | #29571 |
On Saturday, April 12, 2014 9:12:19 AM UTC-7, Stephen Pelc wrote:
> On Fri, 11 Apr 2014 23:10:50 -0700 (PDT), hughaguilar96@yahoo.com
> wrote:
> <somebody>
> >assumes that everything in SwiftForth is Forth-200x standard by default, w=
> >hich is why he had to use the ugly and difficult to type {: for locals.
> Just for the record, Leon Wagner suggested {: ... :} which is actually
> easier to distinguish than { even with syntax colouring.
Leon Wagner doesn't "suggest" to Anton Ertl --- he just tells Anton what to do, and Anton does it. Leon might phrase his order as a suggestion to be polite, but if Anton were to refuse he would fire Anton on the spot --- install another puppet in his place.
The reason why he demanded that {: be used rather than { (although as Bernd said, everybody else had been using { for 20 years), is because SwiftForth uses { for multi-line comments. This has nothing to do with syntax coloring --- colors are about as easy to distinguish for a 1-char token as a 2-char token.
> >By far however, the biggest blunder that Anton Ertl made in his {: was to m=
> >ake the initial values of the locals "undefined." WTF??? This is an incredi=
> >bly bad idea.
> Actually it's an incredibly good idea. Initialised data can be
> specified as inputs, and uninitialised locals are faster to set up.
> In addition, common practice was for locals between '|' and -- to
> be uninitialised. MPE's locals in ProForth and VFX Forth have worked
> that way for over 20 years.
It is slightly faster to use uninitialized locals; to initialize them to whatever data happened to be in memory already --- but this will result in the local being initialized pretty much randomly.
> : foo {: i1 i2 i3 | l4 l5 -- x :}
>
> If you want l4 and l5 to be initialised, the following declaration
> works on all systems I have tested:
>
> : foo 0 0 {: i1 i2 i3 l4 l5 -- x :}
>
> I am a fan of "crash early and crash often" for debugging. Bugs that
> lead to crashes will get fixed, whereas defensive implementation leads
> to bad programming practice. Far better to be explicit that such
> locals must be initialised by the programmer.
The problem is that the programmer MAY forget to explicitly initialize his local --- this is not an error, this is a mistake --- maybe you claim that you've never made a mistake in 20 years, but mistakes are pretty common in the rest of the world.
Lets say a programmer has this function:
: bl-count {: adr len | cnt -- cnt :}
\ 0 to cnt \ the programmer forgot this line
adr len + adr do
I c@ bl = if 1 +to cnt then
loop cnt ;
Just by happenstance however, CNT got initialized to zero. So the programmer tests his function and determines that it works fine, and he continues programming. A couple of months go by and the program works fine every time that it is tested. The program gets shipped to the customer. On the first day that the customer runs his program, it fails spectacularly! The customer calls up and asks: "Don't you idiots test your program before shipping it???"
What likely happened here, is that the compiler was tweaked slightly for the production version. This could involve compiling into an executable and/or using different optimization settings. So the CNT local got initialized to a different random number, and everything went haywire.
Computer programs are supposed to be "determinite" --- this means that they do the same thing every time, given the same inputs. When you initialize your locals to whatever happened to be in memory at the time, then those random numbers are inputs too. Any program that uses random numbers as inputs, is going to behave randomly!
In my novice package, I initialize the locals after | to zero. The programmer can depend upon this! Sometimes that reduces source-code bloat slightly because zero is a pretty common initialization value, so the initialization is already done. This isn't the point though. The point is that the program is determinite and will behave the same way every time.
Lets say that the programmer wants to initialize his local to 99. If he forgets to do so explicitly, then my { will initialize it to 0. When he tests his function, he will discover immediately that it is not 99, but it is 0 instead. He will say: "Oops! I forgot to initialize my variable. I had better fix that bug right away." Problem solved! With your system however, by bad luck, it might get initialized to 99, and then the problem won't get fixed. Or Loki might initialize it to 100 --- then the programmer spends the rest of the afternoon trying to figure out why his results are off by 1.
Stephen, I really expected you of all people to understand this simple concept without needing a cab driver to explain it to you. I had been thinking that you might be a good candidate for implementing a machine-code generating compiler for my language (I'm just implementing an ITC generating compiler) --- now I have my doubts. I am writing a standards document for my language, so anybody can implement a compiler for the language --- the language isn't just what I say from day to day, but it has a definition that can be followed. Any person who implements a compiler for the language, must be able to understand the concepts however --- my document says that the locals after | have to be initialized to zero, so you can't just say: "Well, I optimized the speed slightly by initializing them to whatever happened to be in memory." --- I will not certify your compiler if you do things like this.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-04-12 19:56 +0000 |
| Message-ID | <5349997b.236098667@news.demon.co.uk> |
| In reply to | #29578 |
On Sat, 12 Apr 2014 10:29:58 -0700 (PDT), hughaguilar96@yahoo.com wrote: >Leon Wagner doesn't "suggest" to Anton Ertl --- he just tells Anton what to= > do, and Anton does it. Leon might phrase his order as a suggestion to be p= >olite, but if Anton were to refuse he would fire Anton on the spot --- inst= >all another puppet in his place.=20 Absolute rubbish - I was at that meeting. >Stephen, I really expected you of all people to understand this simple conc= >ept without needing a cab driver to explain it to you. Part of the problem with democracy is that people are entitled to disagree with you. I have indicated why I disagree with you. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-13 00:25 -0700 |
| Message-ID | <5c0ecf8b-d6ef-40bd-bd30-24d52625c992@googlegroups.com> |
| In reply to | #29587 |
On Saturday, April 12, 2014 12:56:14 PM UTC-7, Stephen Pelc wrote: > On Sat, 12 Apr 2014 10:29:58 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >Stephen, I really expected you of all people to understand this simple conc= > >ept without needing a cab driver to explain it to you. > > Part of the problem with democracy is that people are entitled to > disagree with you. I have indicated why I disagree with you. I think that initializing variables (both local and global) to whatever happened to be in memory at the time, is a bad idea. But this is a minor issue. Much more important in regard to why ANS-Forth has been an "epic fail" is Elizabeth Rather's on-going attack on the concept of general purpose code. In this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/OSGAn7bsDU0 She says this about my data-structures in my novice package: On Thursday, September 26, 2013 12:09:59 PM UTC-7, Elizabeth D. Rather wrote: > On 9/26/13 2:27 AM, Albert van der Horst wrote: > > In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>, > > <hughaguilar96@yahoo.com> wrote: > >> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote: > >>> But my point is that you can define data objects to behave *exactly* the > >>> way you want them to, to solve the problem at hand. > > >> I totally disagree with this. It is foolish to custom-implement basic > >> data structures such as arrays for every application. It is easy to > >> write a general-purpose array or linked-list or whatever, that works > >> exactly the way that you want it to for *every* application. > > Does "*every* application" you write use exactly the same kind of data > arranged in the same way? If so, having written it once you can reuse it > often. If not, you either have to rearrange your data to make it work or > modify your "general-purpose" structure.
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-13 10:50 +0100 |
| Message-ID | <ilkkk9t5s2rvs60gihlp1ia20ilg249fhe@4ax.com> |
| In reply to | #29604 |
On Sun, 13 Apr 2014 00:25:52 -0700 (PDT), hughaguilar96@yahoo.com wrote: >Much more important in regard to why ANS-Forth has been an "epic fail" is Elizabeth Rather's on-going attack on the concept of general purpose code. > >In this thread: >https://groups.google.com/forum/#!topic/comp.lang.forth/OSGAn7bsDU0 > >She says this about my data-structures in my novice package: > >On Thursday, September 26, 2013 12:09:59 PM UTC-7, Elizabeth D. Rather wrote: >> On 9/26/13 2:27 AM, Albert van der Horst wrote: >> > In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>, >> > <hughaguilar96@yahoo.com> wrote: >> >> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote: >> >>> But my point is that you can define data objects to behave *exactly* the >> >>> way you want them to, to solve the problem at hand. >> >> >> I totally disagree with this. It is foolish to custom-implement basic >> >> data structures such as arrays for every application. It is easy to >> >> write a general-purpose array or linked-list or whatever, that works >> >> exactly the way that you want it to for *every* application. >> >> Does "*every* application" you write use exactly the same kind of data >> arranged in the same way? If so, having written it once you can reuse it >> often. If not, you either have to rearrange your data to make it work or >> modify your "general-purpose" structure. I don't think that more general-purpose code is needed in Forth. When I started with Forth, sure I would have liked to have more general-purpose code words around because it felt very painful not to have pre-built generic data-stuctures and I didn't know Forth well enough to do almost anything myself. But having invested in learning Forth, I no longer miss the generics. Finally, as far as your novice package. Not sure how much feedback you get from novices, so I thought I'd share my experience. I was a complete novice last year (posting as AKE). You sent me your Novice package. And I took a look at it because I was quite in need of something to help ease into the Forth way of doing things. But to be honest, I did not find your package easy. It would have required that I invest quite a bit of time learning your data structures and your way of thinking of data organisation As a novice, the best thing that I could do was to bite the bullet and learn to use Forth properly myself. The pay-off was that within a short while I got the hang of it and so didn't need the Novice package. Learning to use your novice package felt, for me, against the spirit of Forth. If I wanted to use pre-built libraries for everything why bother to learn Forth at all? why not stick with library languages? Of course, others' mileage may vary, but given that you're quite passionate about your novice package, I thought it would be useful to post some feedback from a recent novice (under 40) who not only liked Forth enough to learn it, but who likes it enough to be using it more often. - Assad
[toc] | [prev] | [next] | [standalone]
Page 2 of 19 — ← Prev page 1 [2] 3 4 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web