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 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-06 16:44 -0700 |
| Message-ID | <7x8urixbtj.fsf@ruckus.brouhaha.com> |
| In reply to | #29331 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > That's vastly overstating it. Forth programmers usually have a > toolbox they carry around with them, but different Forth programmers > have different toolboxes, because they can't agree on the tools. Even very simple things have to be done at a low level in Forth. Like if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ (I don't know about Java), I just print it in one operation. I don't have to write a loop to print it element by element. > Example: When I started Gforth on Android, I used the NativeActivity. Yeah, I've so far avoided having anything to do with Android, maybe because of issues like this. > However, when you think about maintainability: The biggest Forth > program, CCS, is a million lines of code.... It is highly competitive; > you would think that this kind of business planning/financial > application would best be done in Java I've heard of that program and I have always wondered what level of effort it takes to maintain it, compared with something similar written in Java or whatever. I'm certainly no fan of Java. Around here there was a company whose main business was processing mobile phone billing records, another Java-ish area, but their code was written in OCaml. Their recruiting ads asked for Python programmers because they figured directly mentioning OCaml might scare people too much, but someone good at Python could pick up OCaml. Then word got out that they were actually using OCaml, and suddenly they were flooded with nerds wanting to work there. So I wonder whether OCaml might also be a good choice for CCS-like applications.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-06 22:03 -0700 |
| Message-ID | <62b7de26-fa85-4e49-8e99-3a2deb9293f1@googlegroups.com> |
| In reply to | #29346 |
On Sunday, April 6, 2014 4:44:40 PM UTC-7, Paul Rubin wrote: > Even very simple things have to be done at a low level in Forth. Like > if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ > (I don't know about Java), I just print it in one operation. I don't > have to write a loop to print it element by element. If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH. You know, Paul, you really should learn more about Forth before you make these pronouncements about Forth. Earlier you stated that all Forth programs have to be written from scratch. Now you state that to print every element in a data-structure you "have to write a loop to print it element by element." You are just accepting Elizabeth Rather's style of Forth programming as an inherent limitation of the Forth language. This is really Elizabeth Rather's worst crime --- that she teaches novices such as yourself that Forth is limited, and then you go out and tell the whole world that Forth is limited --- you will never get beyond the "Starting Forth" level of Forth so long as you continue to listen to Elizabeth Rather!
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2014-04-07 01:29 -0700 |
| Message-ID | <85e15f4e-96de-4467-8e02-969cc4023399@googlegroups.com> |
| In reply to | #29356 |
>
>
>
> If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH.
>
>
Your discussion with Bernd interested me, so I've implemented locals in my Forth and made a simple test.
The Forth code looks like:
: test { a b c }
a . cr b . cr c . cr
4
[: { d }
d . cr
a . cr b . cr c . cr
." Hello World"
;]
execute
;
1 2 3 test
which gives the following output:
1
2
3
4
1
2
3
Hello World
The block has access to the outer word locals.
The curled bracket define locals, which are stored in a separate local stack. So a simple solution to the locals-problem might be to add a third stack. Chuck's genius divided the normal stack into 2 separate stacks. This decoupled control flow from data processing. Adding a third local stack decouples the parameter processing from local variables. The solution is simple and straightforward. Construct like "each" now can easily be implemented, although this is not a powerful as closures.
(BTW: The curled bracket definition assumes the last word to be the top of stack. This is similar to Forth's standard stack comments).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-07 16:57 +0000 |
| Subject | locals in nested definitions (was: Epic Fail) |
| Message-ID | <2014Apr7.185716@mips.complang.tuwien.ac.at> |
| In reply to | #29361 |
Stefan Mauerhofer <smauerhofer@androsoft.ch> writes:
>Your discussion with Bernd interested me, so I've implemented locals in my =
>Forth and made a simple test.
>
>The Forth code looks like:
>
>: test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr=20
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
>;
>1 2 3 test
>
> which gives the following output:
>
>1
>2
>3
>4
>1
>2
>3
>Hello World
>
>The block has access to the outer word locals.
>
>The curled bracket define locals, which are stored in a separate local stac=
>k. So a simple solution to the locals-problem might be to add a third stack=
>. Chuck's genius divided the normal stack into 2 separate stacks. This deco=
>upled control flow from data processing. Adding a third local stack decoupl=
>es the parameter processing from local variables. The solution is simple an=
>d straightforward. Construct like "each" now can easily be implemented, alt=
>hough this is not a powerful as closures.
Well, EXECUTEing the quotation right away is an easy case. But it
gets harder if you pass the xt to another word that has its own
locals; and consider what happens if it is recursive. This can all be
solved with well-known techniques (static link chains or displays);
did you do this?
And as long as the xt never leaves the definitions whose locals it
references, you can memory-manage them on a stack. But then the
benefit of outer locals is also quite small.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-04-07 11:48 -0700 |
| Message-ID | <6e7d7199-86f0-4fb2-af2c-4958ecfec32a@googlegroups.com> |
| In reply to | #29361 |
On Monday, April 7, 2014 10:29:22 AM UTC+2, Stefan Mauerhofer wrote:
> The curled bracket define locals, which are stored in a separate
> local stack. So a simple solution to the locals-problem might be
> to add a third stack. Chuck's genius divided the normal stack into
> 2 separate stacks. This decoupled control flow from data processing.
> Adding a third local stack decouples the parameter processing from
> local variables. The solution is simple and straightforward.
> Construct like "each" now can easily be implemented, although this
> is not a powerful as closures.
You know this of course, but the controversy is over what happens
when you export the xt of the local word:
:noname LOCALS| c b a | ( -- xt )
a . b . c .
4
[: LOCAL d
d . a . b . c .
." Hello World"
;] ; constant test2-xt
1 2 3 test2-xt execute execute
You will get 1 2 3 4 0 0 0 Hello World \ most probably
If you get 1 2 3 instead of 0 0 0 (repeatedly), I want
to know how you did it :-)
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 22:54 +0200 |
| Message-ID | <lhv3a2$b0f$2@online.de> |
| In reply to | #29361 |
Stefan Mauerhofer wrote:
>>
>>
>>
>> If you have quotations, then this is trivial. You just write a quotation
>> that prints a node according to whatever data is in the node, and you
>> give the quotation to EACH. Actually, this is an example of a quotation
>> that doesn't need any communication with the creator function, so
>> Payson-faked quotations will work, or my "touchers" in the novice package
>> --- I have examples of printing everything in a data structure in both
>> LIST.4TH and ASSOCIATION.4TH.
>>
>>
>
> Your discussion with Bernd interested me, so I've implemented locals in my
> Forth and made a simple test.
>
> The Forth code looks like:
>
> : test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
> ;
> 1 2 3 test
>
> which gives the following output:
>
> 1
> 2
> 3
> 4
> 1
> 2
> 3
> Hello World
>
> The block has access to the outer word locals.
Yes, but only as long as you don't have anything in between. E.g. if you
replace EXECUTE with
: test-exec { xt } xt execute ;
it will fail.
--
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-08 00:04 -0700 |
| Message-ID | <f4b36b90-ca8f-48d9-a276-115ed160b27b@googlegroups.com> |
| In reply to | #29361 |
On Monday, April 7, 2014 1:29:22 AM UTC-7, Stefan Mauerhofer wrote:
> > If you have quotations, then this is trivial. You just write a quotation that prints a node according to whatever data is in the node, and you give the quotation to EACH. Actually, this is an example of a quotation that doesn't need any communication with the creator function, so Payson-faked quotations will work, or my "touchers" in the novice package --- I have examples of printing everything in a data structure in both LIST.4TH and ASSOCIATION.4TH.
> Your discussion with Bernd interested me, so I've implemented locals in my Forth and made a simple test.
>
> The Forth code looks like:
>
> : test { a b c }
> a . cr b . cr c . cr
> 4
> [: { d }
> d . cr
> a . cr b . cr c . cr
> ." Hello World"
> ;]
> execute
> ;
>
> 1 2 3 test
>
> which gives the following output:
>
> 1
> 2
> 3
> 4
> 1
> 2
> 3
>
> Hello World
>
> The block has access to the outer word locals.
>
> The curled bracket define locals, which are stored in a separate local stack. So a simple solution to the locals-problem might be to add a third stack. Chuck's genius divided the normal stack into 2 separate stacks. This decoupled control flow from data processing. Adding a third local stack decouples the parameter processing from local variables. The solution is simple and straightforward. Construct like "each" now can easily be implemented, although this is not a powerful as closures.
>
> (BTW: The curled bracket definition assumes the last word to be the top of stack. This is similar to Forth's standard stack comments).
This is intriguing! I'm pleased to see that somebody is making an effort along these lines.
You need a chain of display-pointers at run-time . I don't understand how your "third stack" provides this. Can you elaborate?
Is your Forth publicly available? Can I examine what you have?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 14:12 +0200 |
| Message-ID | <lhu4ne$hod$1@online.de> |
| In reply to | #29346 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> That's vastly overstating it. Forth programmers usually have a >> toolbox they carry around with them, but different Forth programmers >> have different toolboxes, because they can't agree on the tools. > > Even very simple things have to be done at a low level in Forth. Like > if I want to print an array in Python, Lisp, Haskell, Ruby, or even C++ > (I don't know about Java), I just print it in one operation. I don't > have to write a loop to print it element by element. Print a string array in Gforth with Gforth's string library (in the current git head): $[]. ( addr -- ) One operation. Of course there is a loop somewhere inside $[]., what would you think how Python does it? Magic? The way to program Forth is to build the abstractions you need yourself. Different people have different needs (which is why Forthers usually don't agree on a single library), but there *are* libraries out there, e.g. the Forth Foundation Library. You want to print a cell array (car.fs) in FFL? car-dump ( car -- ) One operation. Of course there is a loop somewhere inside it. Actually, both libraries use the same approach: There's a higher order function walking the entire array. >> Example: When I started Gforth on Android, I used the NativeActivity. > > Yeah, I've so far avoided having anything to do with Android, maybe > because of issues like this. I think this is a general problem with the use run-of-the-mill employees and tools: Too much incompetence. >> However, when you think about maintainability: The biggest Forth >> program, CCS, is a million lines of code.... It is highly competitive; >> you would think that this kind of business planning/financial >> application would best be done in Java > > I've heard of that program and I have always wondered what level of > effort it takes to maintain it, compared with something similar written > in Java or whatever. They are very competitive and have no problem to stay in business. It's not a big company. If i would be way more difficult than what the competition does, they would certainly be out of business by now. > I'm certainly no fan of Java. Around here there was a company whose > main business was processing mobile phone billing records, another > Java-ish area, but their code was written in OCaml. Their recruiting > ads asked for Python programmers because they figured directly > mentioning OCaml might scare people too much, but someone good at Python > could pick up OCaml. Then word got out that they were actually using > OCaml, and suddenly they were flooded with nerds wanting to work there. > So I wonder whether OCaml might also be a good choice for CCS-like > applications. Maybe. The main problem is that programmers have a large difference in performance, even using the same tools (Brooks reports a factor 20). But good programmers usually know more than just one programming language, and by doing so, they have found the programming language that fits their way of thinking, and then they are even more productive than with average tools. If you want good work, you need self-selected, dedicated people who drive it forward. You get much further with that approach than with the run-of-the- mill approach. Quite often, run-of-the-mill managers are scared by people who do their stuff in Forth, and then try to replace their work with run-of-the-mill people and tools. The typical outcome is a complete failure - many software projects are failures, anyways, and using average people with average tools is a recipie for disaster, especially when they are competing with good people and tools that are right for the job. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-07 21:23 -0700 |
| Message-ID | <7xwqf04ffx.fsf@ruckus.brouhaha.com> |
| In reply to | #29373 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Print a string array in Gforth with Gforth's string library (in the current > git head): > $[]. ( addr -- ) Good to know, though I'm still on 0.7.0. > One operation. Of course there is a loop somewhere inside $[]., what would > you think how Python does it? Magic? Of course there's a loop, but the items inside the array also know how to represent themselves as strings so they can be printed. Doing the same thing with a Forth OOP system is perfectly doable but again, it's a roll-your-own operation. > The way to program Forth is to build the abstractions you need yourself. > Different people have different needs Yes, that's the whole point, other languages have taken the experience of past decades on board, that certain abstractions like arrays and dictionaries are useful enough that it's worth supplying them pre-built. Then they become part of the language background rather than the program, eliminating some layers of abstraction from the program. >>> The biggest Forth program, CCS, is a million lines of code.... > They are very competitive and have no problem to stay in business. > It's not a big company. If i would be way more difficult than what > the competition does, they would certainly be out of business by now. I don't know what competition in that industry involves. Those types of programs tend to not evolve very fast: I've done some work with payment and POS terminals recently and it was like stepping back to the 1980's. Competition may be mostly about landing deals and supporting customers rather than advancing technology. The restaurant business is also highly competitive, and one area of competition is developing new recipes and dishes, but not THAT much of their effort goes into that area. It's more about doing a good job with the existing recipes and keeping the venue attractive and the service level high. Maybe it's similar with the CCS company and its software base. > Quite often, run-of-the-mill managers are scared by people who do > their stuff in Forth, and then try to replace their work with > run-of-the-mill people and tools. The typical outcome is a complete > failure - many software projects are failures, anyways I wonder if the failure rate for Forth projects is any different. There's an old Yosefk post that may explain some of what goes on with Forth: http://www.yosefk.com/blog/low-level-is-easy.html It says (among other things) low level approaches can be more tedious, but have fewer dependencies and are more robust against going wrong because somebody else's stuff broke, and tends to be more solid because everyone else's stuff will break if the low level stuff fails.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-07 19:33 -1000 |
| Message-ID | <tamdnQ6jqquAF97OnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #29416 |
On 4/7/14 6:23 PM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: ... > >> The way to program Forth is to build the abstractions you need yourself. >> Different people have different needs > > Yes, that's the whole point, other languages have taken the experience > of past decades on board, that certain abstractions like arrays and > dictionaries are useful enough that it's worth supplying them pre-built. > Then they become part of the language background rather than the > program, eliminating some layers of abstraction from the program. I think it's more that in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures you have and how to use them is just not worth the bother. >>>> The biggest Forth program, CCS, is a million lines of code.... >> They are very competitive and have no problem to stay in business. >> It's not a big company. If i would be way more difficult than what >> the competition does, they would certainly be out of business by now. > > I don't know what competition in that industry involves. Those types of > programs tend to not evolve very fast: I've done some work with payment > and POS terminals recently and it was like stepping back to the 1980's. > Competition may be mostly about landing deals and supporting customers > rather than advancing technology. The restaurant business is also > highly competitive, and one area of competition is developing new > recipes and dishes, but not THAT much of their effort goes into that > area. It's more about doing a good job with the existing recipes and > keeping the venue attractive and the service level high. Maybe it's > similar with the CCS company and its software base. Stephen and I both did a lot of work with payment terminals in the 90's. Programming them then was at least 1980s, maybe 1970's, but the industry was fiercely resistant to change, as they regarded the arcaneness of their tools as their hedge against competition. >> Quite often, run-of-the-mill managers are scared by people who do >> their stuff in Forth, and then try to replace their work with >> run-of-the-mill people and tools. The typical outcome is a complete >> failure - many software projects are failures, anyways > > I wonder if the failure rate for Forth projects is any different. I think most project failures are due to poor design and project management. In my experience, it is easier to compensate for poor design decisions in Forth because of its greater flexibility. I do remember hearing about one famous Forth project failure from folks who were involved. It seems to have involved poor design and project management, in addition to lack of application domain experience on the part of the programmers (who were hired because they "knew Forth" instead of knowing anything about that kind of project, and then not presented with much design guidance from anyone who *did* know the application domain). > There's an old Yosefk post that may explain some of what goes on with > Forth: > > http://www.yosefk.com/blog/low-level-is-easy.html > > It says (among other things) low level approaches can be more tedious, > but have fewer dependencies and are more robust against going wrong > because somebody else's stuff broke, and tends to be more solid because > everyone else's stuff will break if the low level stuff fails. Well, the article rambles on far more than it needs to, but his point is well taken. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-07 23:52 -0700 |
| Message-ID | <c5e65e50-4710-494e-a9cc-cc3e57b5dc96@googlegroups.com> |
| In reply to | #29419 |
On Monday, April 7, 2014 10:33:16 PM UTC-7, Elizabeth D. Rather wrote: > I think it's more that in Forth it's so easy to build data structures > that are exactly right for the particular application at hand that > worrying about what pre-built structures you have and how to use them is > just not worth the bother. Elizabeth Rather is the #1 cause of Forth's "epic fail" --- primarily because of her ongoing effort to prevent general-purpose Forth software from being written. This idea of building data-structures from scratch for every application is stupid. This only works for ultra-simple data-structures such as linked-lists. This is a terrible idea for more complicated data-structures such as self-balancing trees. In my novice package I provide an LLRB tree (association.4th) --- Elizabeth Rather has never provided such a thing, and never will --- she is incapable of doing so. Anybody who follows Elizabeth Rather's advice will be forever limited to writing programs that involve only simple data-structures --- this implies writing programs that are simple and/or inefficient. Not coincidentally, this is the reputation that Forth has in the real-world --- a toy language suitable only for writing toy programs. The only way for Forth to succeed is for Elizabeth Rather to be defeated!
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-08 09:07 +0100 |
| Message-ID | <nva7k9lidntvu8d2hovtrkq39rocb67nfa@4ax.com> |
| In reply to | #29421 |
On Mon, 7 Apr 2014 23:52:40 -0700 (PDT), hughaguilar96@yahoo.com wrote: >Elizabeth Rather is [...rant...] > >This idea of building data-structures from scratch for every application is stupid. This only works for ultra-simple data-structures such as linked-lists. This is a terrible idea for more complicated data-structures such as self-balancing trees. > >In my novice package I provide an LLRB tree (association.4th) --- Elizabeth Rather has [...personal attack...] > >Anybody who follows Elizabeth Rather's advice [...speculation...] Not coincidentally, this is the reputation that Forth has in the real-world --- a toy language suitable only for writing toy programs. > >The only way for Forth to succeed is for Elizabeth Rather to be defeated! Not sure what the etiquette is on C.L.F., but can I ask whether it's really necessary to follow-up every post of Elizabeth's with direct personal attacks. I get that some people feel very strongly about the role of various people or companies in the evolution of their favourite language. But I think everyone on C.L.F. knows this position (it's on almost every thread in which E.R. expresses herself). Look, at the end of the day, it's a free forum where people (I think for the most part) are here to talk about Forth stuff that they care about. My ask: could we just leave it at that, and maybe set aside the personal attacks (or at least put up all of the reasoning in a single thread or blog post somewhere and just refer to that thread whenever you feel you want to call attention to it?) No matter the situation, it just feels wrong to go after someone so doggedly and so personally on every posting. Thanks, and I mean this in the best way. - Assad
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-08 12:35 +0100 |
| Message-ID | <li0muk$nv8$1@dont-email.me> |
| In reply to | #29425 |
on 08/04/2014 09:07:29, Assad Ebrahim wrote: > On Mon, 7 Apr 2014 23:52:40 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >>Elizabeth Rather is [...rant...] >> >>This idea of building data-structures from scratch for every application is stupid. This only works for ultra-simple data-structures such as linked-lists. This is a terrible idea for more complicated data-structures such as self-balancing trees. >> >>In my novice package I provide an LLRB tree (association.4th) --- Elizabeth Rather has [...personal attack...] >> >>Anybody who follows Elizabeth Rather's advice [...speculation...] Not coincidentally, this is the reputation that Forth has in the real-world --- a toy language suitable only for writing toy programs. >> >>The only way for Forth to succeed is for Elizabeth Rather to be defeated! > > > Not sure what the etiquette is on C.L.F., but can I ask whether it's > really necessary to follow-up every post of Elizabeth's with direct > personal attacks. > > I get that some people feel very strongly about the role of various > people or companies in the evolution of their favourite language. > > But I think everyone on C.L.F. knows this position (it's on almost > every thread in which E.R. expresses herself). > > Look, at the end of the day, it's a free forum where people (I think > for the most part) are here to talk about Forth stuff that they care > about. > > My ask: could we just leave it at that, and maybe set aside the > personal attacks (or at least put up all of the reasoning in a single > thread or blog post somewhere and just refer to that thread whenever > you feel you want to call attention to it?) > > No matter the situation, it just feels wrong to go after someone so > doggedly and so personally on every posting. > > Thanks, and I mean this in the best way. > > - Assad > Ignore Hugh. He occasionally has some valid points, but they're well buried in his spittle flecked rants and pathological hatred of Elizabeth Rather and a number of other people here. Some, like you, have tried to educate him on the niceties of civilized discourse, but he's too far gone for that.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-04-08 16:21 +0000 |
| Message-ID | <2014Apr8.182107@mips.complang.tuwien.ac.at> |
| In reply to | #29425 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes:
>Not sure what the etiquette is on C.L.F.,
Like on any other Usenet newsgroup, part of the etiquette is:
Do not feed the trolls!
- 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-08 16:33 -0400 |
| Message-ID | <op.xd0l1usz6zenlw@localhost> |
| In reply to | #29452 |
On Tue, 08 Apr 2014 12:21:07 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: >> Not sure what the etiquette is on C.L.F., > > Like on any other Usenet newsgroup, part of the etiquette is: > > Do not feed the trolls! > I don't see where calling Hugh a troll helps anything. He programs in Forth. One aspect of being a troll is not having any justification for posting to a newsgroup. Hugh is clearly attacking the c.l.f. newsgroup clique. As you should be well aware, he views the Forth "authorities" as an impediment to Forth progress. None of the Forth "authorities" have accepted his programs for novices or his language extensions, e.g., closures and his allocation method. How much rejection can one take before they begin fight back or simply go away? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-08 23:41 +0100 |
| Message-ID | <li1tvl$jbj$1@dont-email.me> |
| In reply to | #29461 |
on 08/04/2014 21:33:15, "Rod Pemberton" wrote: > On Tue, 08 Apr 2014 12:21:07 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > >>> Not sure what the etiquette is on C.L.F., >> >> Like on any other Usenet newsgroup, part of the etiquette is: >> >> Do not feed the trolls! >> > > I don't see where calling Hugh a troll helps anything. He > programs in Forth. One aspect of being a troll is not having > any justification for posting to a newsgroup. Hugh is clearly > attacking the c.l.f. newsgroup clique. As you should be well > aware, he views the Forth "authorities" as an impediment to Forth > progress. None of the Forth "authorities" have accepted his > programs for novices or his language extensions, e.g., closures > and his allocation method. How much rejection can one take > before they begin fight back or simply go away? > > > Rod Pemberton > Closures are too new to be standardized, and Hugh's description of them doesn't address some funamental issues that need to be addressed prior to formalization. His allocation method is trivial, possible to implement without carnal knowledge and not generally required; and is therefore a bad combination for standardization. All IMHO. Both were discussed here and may have been discussed on the Yahoo Forth200x list, but no RfDs have been forthcoming. Hugh has made one proposal; http://www.forth200x.org/colon-name.txt and it was extensively (and politely) discussed and rejected. Hugh did not rework it or resubmit it and it never made it to a call for votes (CfV). He has made no formal proposal for closures, nor for his allocation method. http://www.forth200x.org/ for RfDs.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-04-08 22:47 -0700 |
| Message-ID | <b3828d6e-fb5e-4620-b101-918dccf4e6c8@googlegroups.com> |
| In reply to | #29452 |
On Tuesday, April 8, 2014 9:21:07 AM UTC-7, Anton Ertl wrote: > Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > >Not sure what the etiquette is on C.L.F., > > Like on any other Usenet newsgroup, part of the etiquette is: > > Do not feed the trolls! Apparently that is why you didn't respond to me in this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/x7cXQEcmvZQ Instead you were satisfied to let Julien Fondren call my code "stupid." You are only allowed to be a big chief on Forth-200x because Elizabeth Rather gives you permission. The topic for this thread is "Epic Fail" --- and Elizabeth Rather was the chair-person of the ANS-Forth committee --- pointing out the gross stupidity of Elizabeth Rather's statement that all data-structures must be customized for every application program is not off-topic. It does, in fact, hit the nail on the head. Forth-200x is going to be an "epic fail" just like ANS-Forth was, unless you kick Elizabeth Rather and Forth Inc. off the Forth-200x committee --- but you don't have the authority to do that --- so don't call me a troll, when you are nothing more than Elizabeth Rather's lap-dog yapping at me. You endlessly talk up your compiler-writing expertise. If you know so much about compiler-writing, why is Gforth the slowest Forth implementation available??? Gforth will never be used for any commercial program; it is a toy for your students to play with. Also, your Gforth is over-complicated --- to paraphrase Nietzsche: "nor are you clean enough for me; you muddy the waters to make them appear deep."
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-08 10:43 +0200 |
| Message-ID | <li0cs0$smi$1@news.albasani.net> |
| In reply to | #29421 |
On Mon, 7 Apr 2014 23:52:40 -0700 (PDT) hughaguilar96@yahoo.com wrote: > On Monday, April 7, 2014 10:33:16 PM UTC-7, Elizabeth D. Rather wrote: > > I think it's more that in Forth it's so easy to build data > > structures that are exactly right for the particular application at > > hand that worrying about what pre-built structures you have and how > > to use them is just not worth the bother. > > Elizabeth Rather is the #1 cause of Forth's "epic fail" --- primarily > because of her ongoing effort to prevent general-purpose Forth > software from being written. > > This idea of building data-structures from scratch for every > application is stupid. This only works for ultra-simple > data-structures such as linked-lists. This is a terrible idea for > more complicated data-structures such as self-balancing trees. Hm, C does not have container library, too, and I can't see it's popularity suffers because of that. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-08 07:22 -0700 |
| Message-ID | <7xmwfvnboq.fsf@ruckus.brouhaha.com> |
| In reply to | #29419 |
"Elizabeth D. Rather" <erather@forth.com> writes: > I think it's more that in Forth it's so easy to build data structures > that are exactly right for the particular application at hand that > worrying about what pre-built structures you have and how to use them > is just not worth the bother. That approach has some merit on old minicomputers and contemporary microcontrollers, where every byte of program memory is precious, so even for a general purpose data structure like a dictionary you want to implement just the subset of features that the application needs. On bigger computers you can just use a generic implementation and be done with it. Why spend even 2 minutes implementing a dictionary, instead of using a language that already supports them?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-08 10:12 -0500 |
| Message-ID | <SYWdnZQM9dFCjNnOnZ2dnUVZ8l6dnZ2d@supernews.com> |
| In reply to | #29444 |
Paul Rubin <no.email@nospam.invalid> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> I think it's more that in Forth it's so easy to build data structures >> that are exactly right for the particular application at hand that >> worrying about what pre-built structures you have and how to use them >> is just not worth the bother. > > That approach has some merit on old minicomputers and contemporary > microcontrollers, where every byte of program memory is precious, so > even for a general purpose data structure like a dictionary you want > to implement just the subset of features that the application needs. > On bigger computers you can just use a generic implementation and be > done with it. Why spend even 2 minutes implementing a dictionary, > instead of using a language that already supports them? You're rather assuming that the dictionary can be treated as a black box with predictable high performance and reliability. If this is assumed to be true, I agree that argument has some merit. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web