Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55968 > unrolled thread
| Started by | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| First post | 2017-03-20 09:58 -0700 |
| Last post | 2017-03-24 17:52 -0700 |
| Articles | 20 on this page of 212 — 28 participants |
Back to article view | Back to comp.lang.forth
Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 09:58 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-20 10:34 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 10:51 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-20 18:08 +0000
Re: Make Forth Small Again! NN <november.nihal@gmail.com> - 2017-03-20 12:19 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 05:51 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-21 15:04 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 11:22 -1000
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:47 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-22 01:34 +0100
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-25 17:27 +1100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 00:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 01:02 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 01:05 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 12:11 +1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 15:53 +1000
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-26 22:12 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:30 +1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 09:34 +0000
Re: Make Forth Small Again! mhx@iae.nl - 2017-03-25 03:46 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 10:56 +1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 10:07 +1000
Re: Make Forth Small Again! mhx@iae.nl - 2017-03-27 16:46 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-27 18:51 -0700
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-27 17:21 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 10:57 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-28 01:16 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-28 03:36 -0500
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-28 01:54 -0700
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-28 12:57 -1000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-28 03:51 -0500
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:29 +1000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 03:33 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 05:17 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 09:42 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 09:49 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 12:12 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:28 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:43 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 14:11 -1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-21 16:46 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 12:32 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:57 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 14:10 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 15:29 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:01 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 03:23 -0500
Re: Make Forth Small Again! Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-07 09:26 +0200
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-04-07 10:10 -1000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:42 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 13:10 +0000
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:38 -0700
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 15:24 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 08:52 -0500
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 13:55 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-25 17:41 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 07:43 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 08:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 10:01 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 10:19 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 10:59 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-22 18:31 +0000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 13:55 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-23 05:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 08:05 -0500
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-23 13:47 +0000
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-23 15:31 +0100
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 10:25 -0500
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 18:07 +0000
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 10:45 +0100
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-05-03 03:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 05:57 -0500
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 12:08 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 12:26 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:02 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 16:08 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:35 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 18:28 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-04 10:14 +0100
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-05-04 12:44 +0200
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-04 12:32 +0100
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 06:49 -0500
Re: Make Forth Small Again! crc <charles.childers@gmail.com> - 2017-05-04 04:50 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-04 13:14 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-05 11:19 +0100
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-05-05 04:16 -0700
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-05 12:35 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-05-03 13:55 -0700
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 17:04 -0500
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-05-04 07:29 +0300
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:52 -0500
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-04 05:08 -0400
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 06:34 -0500
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-05-04 11:17 -0500
Re: Make Forth Small Again! Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-03 19:03 +0100
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 18:12 +0000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 13:49 +0000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:58 -0400
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-22 20:55 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-23 18:05 -0700
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-22 15:57 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 10:29 +0000
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-25 04:00 -0700
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-05-03 08:01 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:06 +0000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 14:02 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-22 20:59 -1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 12:14 +0000
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 14:45 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-23 12:24 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 10:55 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-27 17:24 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:49 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-28 15:05 -1000
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-28 19:06 -0700
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-03-29 06:43 +0300
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-30 10:37 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-29 19:34 -1000
Re: Make Forth Small Again! stephen@mpeforth.com (Stephen Pelc) - 2017-03-23 10:36 +0000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 11:33 +0000
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 14:58 +0100
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 17:57 +0000
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 22:32 +0000
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-24 17:10 -0700
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 07:31 +0000
Re: Make Forth Small Again! Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-07 08:50 +0200
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-20 17:57 -0400
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 10:09 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 10:28 +0100
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-05-03 07:57 -0400
Re: Make Forth Small Again! stephen@mpeforth.com (Stephen Pelc) - 2017-05-03 13:07 +0000
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:03 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-20 14:08 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-20 17:51 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-20 13:12 -0700
Re: Make Forth Small Again! bruehlconsult@gmail.com - 2017-03-20 17:22 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-20 19:12 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-21 02:30 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-21 02:47 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 05:56 -0500
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-21 16:07 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 14:28 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 11:30 +1000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:42 -0400
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-21 22:56 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 04:04 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-24 02:32 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 10:00 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-24 06:46 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 14:41 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-25 15:32 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-25 23:10 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-25 17:29 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-25 18:08 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-26 08:30 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-26 08:50 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-26 15:14 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 08:32 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 13:21 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 15:31 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 09:04 -0700
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-03-27 11:52 -0500
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 18:41 +0100
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-03-27 12:58 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 12:07 -0700
Re: Make Forth Small Again! foxaudioresearch@gmail.com - 2017-03-27 13:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 11:30 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-28 20:06 +0100
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-29 14:54 +0200
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 19:13 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 21:18 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 10:54 -0700
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-03-27 21:53 +0300
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 22:29 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 14:07 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 16:03 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-31 09:28 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 03:36 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-31 19:29 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-04-01 04:37 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-04-01 09:23 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-01 10:37 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-01 11:55 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 14:15 -0700
Re: Make Forth Small Again! Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:55 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-07 12:08 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-05-07 09:04 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-04-01 21:35 +0200
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-01 20:35 -0400
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-01 11:52 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 16:31 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 20:54 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 21:13 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-05 16:06 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-31 09:42 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 03:52 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 20:26 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-27 04:55 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 08:49 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 13:35 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 14:23 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-30 15:28 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 23:20 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 02:29 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-31 03:20 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-31 03:38 -0500
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 09:17 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-24 17:52 -0700
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-21 16:46 +0000 |
| Message-ID | <2017Mar21.174630@mips.complang.tuwien.ac.at> |
| In reply to | #55995 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Some people think that because a word is in CORE it has to be in the
>set of words which is always loaded into the system, and it must be
>present in the predefined dictionary when Forth starts. But this is
>not true: there is no reason why some words can't be loaded from
>source as required. It is true that the system won't be standard
>until they are loaded, but this doesn't matter to anyone.
It certainly matters to me that I have to do some arcane incantations
to load the FP words before I can use them on some of the systems I
test on.
>Therefore,
>people complaining that the CORE wordset is "too large for small
>systems" are not making any sense.
Does it matter? Running standard programs is not very important for
small systems, and the core/extension difference does not make a big
difference for most useful programs (they don't limit themselves to
core words), and for "programmer portability" core/extension does not
make a difference (they don't limit themselves to core words), either.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 12:32 -0500 |
| Message-ID | <Xq2dnWZVx8M0_kzFnZ2dnUU7-b3NnZ2d@supernews.com> |
| In reply to | #56019 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Some people think that because a word is in CORE it has to be in the >>set of words which is always loaded into the system, and it must be >>present in the predefined dictionary when Forth starts. But this is >>not true: there is no reason why some words can't be loaded from >>source as required. It is true that the system won't be standard >>until they are loaded, but this doesn't matter to anyone. > > It certainly matters to me that I have to do some arcane incantations > to load the FP words before I can use them on some of the systems I > test on. OK, I see. >>Therefore, people complaining that the CORE wordset is "too large >>for small systems" are not making any sense. > > Does it matter? Running standard programs is not very important for > small systems, and the core/extension difference does not make a big > difference for most useful programs (they don't limit themselves to > core words), and for "programmer portability" core/extension does > not make a difference (they don't limit themselves to core words), > either. Maybe it doesn't matter greatly in practice. However, for the sake of the sanity of people using small systems, it does make sense to have some idea of a basic entitlement. CORE is a reasonable choice for such a set of words, IMO. I think that most of the words in CORE EXT are of marginal use on very small systems, and I am happy to see that the atrocious PICK and ROLL are not required in CORE. On the other hand, I don't think that anyone would much enjoy using an embedded system without HEX. But these are judgement calls, and very much a matter for the application programmer. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 10:57 -0700 |
| Message-ID | <69223862-5341-4fb2-9789-eb1eff15416c@googlegroups.com> |
| In reply to | #56022 |
Am Dienstag, 21. März 2017 18:32:32 UTC+1 schrieb Andrew Haley: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>Some people think that because a word is in CORE it has to be in the > >>set of words which is always loaded into the system, and it must be > >>present in the predefined dictionary when Forth starts. But this is > >>not true: there is no reason why some words can't be loaded from > >>source as required. It is true that the system won't be standard > >>until they are loaded, but this doesn't matter to anyone. > > > > It certainly matters to me that I have to do some arcane incantations > > to load the FP words before I can use them on some of the systems I > > test on. > > OK, I see. > > >>Therefore, people complaining that the CORE wordset is "too large > >>for small systems" are not making any sense. > > > > Does it matter? Running standard programs is not very important for > > small systems, and the core/extension difference does not make a big > > difference for most useful programs (they don't limit themselves to > > core words), and for "programmer portability" core/extension does > > not make a difference (they don't limit themselves to core words), > > either. > > Maybe it doesn't matter greatly in practice. However, for the sake of > the sanity of people using small systems, it does make sense to have > some idea of a basic entitlement. CORE is a reasonable choice for > such a set of words, IMO. > > I think that most of the words in CORE EXT are of marginal use on very > small systems, and I am happy to see that the atrocious PICK and ROLL > are not required in CORE. On the other hand, I don't think that > anyone would much enjoy using an embedded system without HEX. But > these are judgement calls, and very much a matter for the application > programmer. > > Andrew. What do not you like about "ROLL" or "PICK"? I could imagine a word "NUKE" that works like: : NUKE ROLL DROP ; There is the question, what is more interesting for building the system - "ROLL" or "NUKE". If you do not like these words, I can tell you, what words I do not like - or at least one word: "[" ;) Always, if someone uses "[", there comes some trick into play... Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 14:10 -0500 |
| Message-ID | <X-ydnfx0w4Y350zFnZ2dnUU7-bvNnZ2d@supernews.com> |
| In reply to | #56027 |
Helmar Wodtke <helmwo@gmail.com> wrote: > > What do not you like about "ROLL" or "PICK"? This question comes up regularly. I guess it's not yet come up this year. https://groups.google.com/forum/#!topic/comp.lang.forth/hvXr30y2Tdk http://tinyurl.com/kp9m52s Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 12:50 -0700 |
| Message-ID | <f9fb2a58-1255-4cf2-a881-81bb3f7b2b1f@googlegroups.com> |
| In reply to | #56036 |
Am Dienstag, 21. März 2017 20:10:40 UTC+1 schrieb Andrew Haley: > Helmar Wodtke <helmwo@gmail.com> wrote: > > > > What do not you like about "ROLL" or "PICK"? > > This question comes up regularly. I guess it's not yet come up this > year. > > https://groups.google.com/forum/#!topic/comp.lang.forth/hvXr30y2Tdk > > http://tinyurl.com/kp9m52s > > Andrew. I'm at a completely different layer of why I ask you this ;) I dont even like to use these words. But they are build-tokens for other words and in that I think they are "core". I think these words should be used only and only if there is no other option. But for creating new stack shuffling words, they are a build token. It's like using >R RDROP and R> for flow control... You would not do this inside a program, but if you define new words, you might need this. Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 15:29 -0500 |
| Message-ID | <prCdnXfI7sKTEEzFnZ2dnUU7-eWdnZ2d@supernews.com> |
| In reply to | #56047 |
Helmar Wodtke <helmwo@gmail.com> wrote: > > I'm at a completely different layer of why I ask you this ;) I dont > even like to use these words. But they are build-tokens for other > words and in that I think they are "core". I think these words > should be used only and only if there is no other option. But for > creating new stack shuffling words, they are a build token. But why use PICK and ROLL? Surely there are better ways to build the basic stack operators. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 14:01 -0700 |
| Message-ID | <53d44be0-994d-4597-8c65-96a315244c0c@googlegroups.com> |
| In reply to | #56051 |
Am Dienstag, 21. März 2017 21:29:07 UTC+1 schrieb Andrew Haley: > Helmar Wodtke <helmwo@gmail.com> wrote: > > > > I'm at a completely different layer of why I ask you this ;) I dont > > even like to use these words. But they are build-tokens for other > > words and in that I think they are "core". I think these words > > should be used only and only if there is no other option. But for > > creating new stack shuffling words, they are a build token. > > But why use PICK and ROLL? Surely there are better ways to build the > basic stack operators. > > Andrew. There are better ways in assembly language of the system. Inside FORTH? I think you could do some artistic things using R> & Co. and static variables. This is not better, only slower. By no reason - because some people dont like using PICK and ROLL (I include me to these people, but I would not use the things without reason). Because PICK and ROLL are a bad choice for learning to program in Forth, they are still good tools for building new words that handle the stack... Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-22 03:23 -0500 |
| Message-ID | <aOidncpJEZ4bqU_FnZ2dnUU7-a2dnZ2d@supernews.com> |
| In reply to | #56057 |
Helmar Wodtke <helmwo@gmail.com> wrote: > Am Dienstag, 21. M?rz 2017 21:29:07 UTC+1 schrieb Andrew Haley: >> Helmar Wodtke <helmwo@gmail.com> wrote: >> > >> > I'm at a completely different layer of why I ask you this ;) I >> > dont even like to use these words. But they are build-tokens for >> > other words and in that I think they are "core". I think these >> > words should be used only and only if there is no other >> > option. But for creating new stack shuffling words, they are a >> > build token. >> >> But why use PICK and ROLL? Surely there are better ways to build the >> basic stack operators. > > There are better ways in assembly language of the system. Inside > FORTH? Yes. At the most basic level you need DUP, OVER, SWAP, R> and >R. That's a good base to start from. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-04-07 09:26 +0200 |
| Message-ID | <86bms84r17.fsf@molnjunk.nocrew.org> |
| In reply to | #56047 |
Helmar Wodtke wrote: >> > What do not you like about "ROLL" or "PICK"? > I think these words should be used only and only if there is no other > option. In that case, if you really strictly mean that, they should never be used. ROLL and PICK can be implemented with simpler stack juggling words and the return stack, which goes to show that there are always other options.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-07 10:10 -1000 |
| Message-ID | <-_ednVSQAfbUb3rFnZ2dnUU7-f_NnZ2d@supernews.com> |
| In reply to | #56803 |
On 4/6/17 9:26 PM, Lars Brinkhoff wrote: > Helmar Wodtke wrote: >>>> What do not you like about "ROLL" or "PICK"? >> I think these words should be used only and only if there is no other >> option. > > In that case, if you really strictly mean that, they should never be > used. ROLL and PICK can be implemented with simpler stack juggling > words and the return stack, which goes to show that there are always > other options. I wrote Forth code for 30 years without using them, and most of my colleagues avoided them, too, including Chuck. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-03-21 16:42 -0400 |
| Message-ID | <20170321164222.546a92c8@_> |
| In reply to | #56036 |
On Tue, 21 Mar 2017 14:10:34 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Helmar Wodtke <helmwo@gmail.com> wrote: > > What do not you like about "ROLL" or "PICK"? > > This question comes up regularly. I guess it's not yet come up this > year. > > https://groups.google.com/forum/#!topic/comp.lang.forth/hvXr30y2Tdk > Was that intentional? Did you recall or notice that Helmar was in that thread? Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-22 13:10 +0000 |
| Message-ID | <2017Mar22.141045@mips.complang.tuwien.ac.at> |
| In reply to | #56022 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I don't think that
>anyone would much enjoy using an embedded system without HEX.
HEX is not just obsolete, it's a bad idea to use it. Better use $ff
for input and HEX. for output.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-22 06:38 -0700 |
| Message-ID | <a399d230-1995-4ca6-858c-f75bbf214143@googlegroups.com> |
| In reply to | #56102 |
Am Mittwoch, 22. März 2017 14:13:59 UTC+1 schrieb Anton Ertl: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >I don't think that > >anyone would much enjoy using an embedded system without HEX. > > HEX is not just obsolete, it's a bad idea to use it. Better use $ff > for input and HEX. for output. Anton? You dont like BASE at all? : HEX 1 2* 2* 2* 2* BASE ! ; Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-22 15:24 +0000 |
| Message-ID | <2017Mar22.162429@mips.complang.tuwien.ac.at> |
| In reply to | #56103 |
Helmar Wodtke <helmwo@gmail.com> writes:
>Am Mittwoch, 22. M=C3=A4rz 2017 14:13:59 UTC+1 schrieb Anton Ertl:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> >I don't think that
>> >anyone would much enjoy using an embedded system without HEX.
>>=20
>> HEX is not just obsolete, it's a bad idea to use it. Better use $ff
>> for input and HEX. for output.
>
>Anton? You dont like BASE at all?
Correct.
>: HEX 1 2* 2* 2* 2* BASE ! ;
$10 BASE !
would be enough, if I ever wanted this functionality,
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-22 08:52 -0500 |
| Message-ID | <79idnfBLdokuHE_FnZ2dnUU7-TmdnZ2d@supernews.com> |
| In reply to | #56102 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I don't think that anyone would much enjoy using an embedded system >>without HEX. > > HEX is not just obsolete, it's a bad idea to use it. Better use $ff > for input and HEX. for output. Bletch. You're joking, surely: HEX. , HEX-DUMP, HEX-U. , HEX-D. , etc. A rather obvious refactoring suggests itself... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-25 13:55 +0000 |
| Message-ID | <2017Mar25.145538@mips.complang.tuwien.ac.at> |
| In reply to | #56106 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>I don't think that anyone would much enjoy using an embedded system
>>>without HEX.
>>
>> HEX is not just obsolete, it's a bad idea to use it. Better use $ff
>> for input and HEX. for output.
>
>Bletch. You're joking, surely: HEX.
Yes. Or, as SwiftForth calls it, H..
>HEX-DUMP,
No. Every high-quality DUMP dumps in hex anyway (a candidate for
tightening the standard?), even the one in SwiftForth, despite Chuck
Moore's quote about decimal dumps:
SwiftForth i386-Linux 3.6.3 29-Jun-2016
decimal here 16 - 16 dump
8083938 78 2F 68 69 2E 66 00 E8 6B 69 FC FF 26 00 00 00 x/hi.f..ki..&... ok
>HEX-U.
No. Both HEX. and H. print unsigned.
>HEX-D. ,
No.
SWAP HEX. HEX.
would be sufficient if I ever needed that (has not happened to me yet).
None of your additional words are needed, and I never missed them.
Looking at some systems, Gforth has HEX. and SwiftForth has H.;
neither has something like the strawman words you suggest.
>A rather obvious refactoring suggests itself...
If you want to propose BASE-EXECUTE for standardization, you have my
support.
|'base-execute' i*x xt u - j*x gforth "base-execute"
| execute xt with the content of 'BASE' being u, and restoring the
|original 'BASE' afterwards.
[Ideally the xt should be on the TOS, but this word was defined before
I found that out.]
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-25 17:41 -0500 |
| Message-ID | <F7adnXkNU46cb0vFnZ2dnUU7-V_NnZ2d@supernews.com> |
| In reply to | #56276 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>I don't think that anyone would much enjoy using an embedded system >>>>without HEX. >>> >>> HEX is not just obsolete, it's a bad idea to use it. Better use $ff >>> for input and HEX. for output. >> >>Bletch. You're joking, surely: HEX. > > Yes. Or, as SwiftForth calls it, H.. > >>HEX-DUMP, > > No. Every high-quality DUMP dumps in hex anyway (a candidate for > tightening the standard?), even the one in SwiftForth, despite Chuck > Moore's quote about decimal dumps: > > SwiftForth i386-Linux 3.6.3 29-Jun-2016 > decimal here 16 - 16 dump > 8083938 78 2F 68 69 2E 66 00 E8 6B 69 FC FF 26 00 00 00 x/hi.f..ki..&... ok Colour me unimpressed. >>HEX-U. > > No. Both HEX. and H. print unsigned. That's all very inflexible. Fixing dump as hex only, and fixing all hex output as unsigned, is surely the exact opposite of factored code. >>HEX-D. , > > No. > SWAP HEX. HEX. > would be sufficient if I ever needed that (has not happened to me yet). Hmph. > > None of your additional words are needed, and I never missed them. That's a very telling remark. > Looking at some systems, Gforth has HEX. and SwiftForth has H.; > neither has something like the strawman words you suggest. There's nothing strawman about any of them. By definition, a straw man argument is when you misrepresent an opponent's argument, but I have not done that: I've talked about the conveniences I would miss. I do not know whether anyone else would, and I'm certainly not suggesting that you would. Speaking only for myself, I have always found switching everything to hex when debugging an embedded system very convenient, and I consider BASE to be a brilliant idea. >>A rather obvious refactoring suggests itself... > > If you want to propose BASE-EXECUTE for standardization, you have my > support. Thus piling complication on complication. Besides, I think you'd have to type HEX every time. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-22 07:43 -0700 |
| Message-ID | <d8f2c272-e79d-44db-ac2e-af0a9b7c1dfb@googlegroups.com> |
| In reply to | #56102 |
On Wednesday, March 22, 2017 at 6:13:59 AM UTC-7, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >I don't think that > >anyone would much enjoy using an embedded system without HEX. > > HEX is not just obsolete, it's a bad idea to use it. Better use $ff > for input and HEX. for output. Anton Ertl is inadvertently shining a spotlight on yet another stupid aspect of Elizabeth Rather's toy language. When QUIT executes (typically when ABORT or ABORT" call it), QUIT fails to restore the system to a known state. 1.) BASE still has the value that it had prior to the abort. 2.) The search-order is the same as it was prior to the abort. 3.) The current word-list is the same as it was prior to the abort. If compilation of a file aborts, it often happens that the user is left in the REPL and nothing works. Numbers don't work as expected because BASE is not decimal. None of the words work as expected because the search-order is screwed up. This can be truly baffling! It is baffling for me, although with my experience I can get it back into a rational state. Most novices will think that the Forth system is fatally corrupted and they will just kill the whole Forth system. Whether they feel inspired to restart Forth again, is dubious --- many will just say: "Forth sucks! I was just writing a simple program, and I must have had a bug, but then everything went haywire and the system began behaving in a truly bizarre manner. I'm going back to programming in C again!" The intelligent design for a Forth system would be for QUIT to restore global variables (such as BASE the search-order, etc.) that describe the state of the Forth system. Also, though, it would be a good idea if the contents of these global variables prior to QUIT were dumped into a snapshot data-structure so the user could examine these values to help him determine what caused the abort (quite often in a cross-compiler, getting the search-order screwed up is the cause of the abort; that is a very common bug). Also, the intelligent design for a Forth system would be for QUIT to be vectored. This is so the user can write a custom QUIT that restores some of his own global variables that describe the state of the Forth system for him. ANS-Forth was not an intelligent design. ANS-Forth was just the corpse of Charles Moore's 1970s Forth system warmed up and goaded into walking --- ANS-Forth is a zombie --- it is dead, but it just keeps on lurching forward into the future with flat-line neural activity. The Forth-200x committee, who are supposedly experts in Forth (so they say), are just sitting on their "little pink cloud" pretending that there is nothing wrong with ANS-Forth --- they are deeply delusional --- everybody in the world thinks that they are stupid, and have thought so since 1994. The only way for Forth to succeed is for ANS-Forth to be killed for good --- ANS-Forth makes the Forth community look stupid every day, in multiple ways --- anything would be better than ANS-Forth!
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-22 08:06 -0700 |
| Message-ID | <7b338452-89dd-48a7-bfd3-1e7891126371@googlegroups.com> |
| In reply to | #56114 |
Am Mittwoch, 22. März 2017 15:43:27 UTC+1 schrieb hughag...@gmail.com: > On Wednesday, March 22, 2017 at 6:13:59 AM UTC-7, Anton Ertl wrote: > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > > >I don't think that > > >anyone would much enjoy using an embedded system without HEX. > > > > HEX is not just obsolete, it's a bad idea to use it. Better use $ff > > for input and HEX. for output. > > Anton Ertl is inadvertently shining a spotlight on yet another stupid aspect of Elizabeth Rather's toy language. > > When QUIT executes (typically when ABORT or ABORT" call it), QUIT fails to restore the system to a known state. > 1.) BASE still has the value that it had prior to the abort. > 2.) The search-order is the same as it was prior to the abort. > 3.) The current word-list is the same as it was prior to the abort. > > If compilation of a file aborts, it often happens that the user is left in the REPL and nothing works. Numbers don't work as expected because BASE is not decimal. None of the words work as expected because the search-order is screwed up. This can be truly baffling! It is baffling for me, although with my experience I can get it back into a rational state. Most novices will think that the Forth system is fatally corrupted and they will just kill the whole Forth system. Whether they feel inspired to restart Forth again, is dubious --- many will just say: "Forth sucks! I was just writing a simple program, and I must have had a bug, but then everything went haywire and the system began behaving in a truly bizarre manner. I'm going back to programming in C again!" > > The intelligent design for a Forth system would be for QUIT to restore global variables (such as BASE the search-order, etc.) that describe the state of the Forth system. Also, though, it would be a good idea if the contents of these global variables prior to QUIT were dumped into a snapshot data-structure so the user could examine these values to help him determine what caused the abort (quite often in a cross-compiler, getting the search-order screwed up is the cause of the abort; that is a very common bug). Also, the intelligent design for a Forth system would be for QUIT to be vectored. This is so the user can write a custom QUIT that restores some of his own global variables that describe the state of the Forth system for him. > > ANS-Forth was not an intelligent design. ANS-Forth was just the corpse of Charles Moore's 1970s Forth system warmed up and goaded into walking --- ANS-Forth is a zombie --- it is dead, but it just keeps on lurching forward into the future with flat-line neural activity. > > The Forth-200x committee, who are supposedly experts in Forth (so they say), are just sitting on their "little pink cloud" pretending that there is nothing wrong with ANS-Forth --- they are deeply delusional --- everybody in the world thinks that they are stupid, and have thought so since 1994. > > The only way for Forth to succeed is for ANS-Forth to be killed for good --- ANS-Forth makes the Forth community look stupid every day, in multiple ways --- anything would be better than ANS-Forth! How about you make a proposal for that "anything"? You claim to be intelligent. Or is this not your job? Your job is just to be offensive? It makes no sense what you say. QUIT is defined. What you describe is inside definition. ANS is a kind of crap and we all know it. It's something with the label "standard". And you want one too. So write a better one. I do not think you could do that, as writing such a document requires some social skills... Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-22 10:01 -0700 |
| Message-ID | <70ddfa19-c3a1-41df-8915-dbacd728d09d@googlegroups.com> |
| In reply to | #56117 |
On Wednesday, March 22, 2017 at 8:06:23 AM UTC-7, Helmar Wodtke wrote: > Am Mittwoch, 22. März 2017 15:43:27 UTC+1 schrieb hughag...@gmail.com: > > On Wednesday, March 22, 2017 at 6:13:59 AM UTC-7, Anton Ertl wrote: > > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > > > >I don't think that > > > >anyone would much enjoy using an embedded system without HEX. > > > > > > HEX is not just obsolete, it's a bad idea to use it. Better use $ff > > > for input and HEX. for output. > > > > Anton Ertl is inadvertently shining a spotlight on yet another stupid aspect of Elizabeth Rather's toy language. > > > > When QUIT executes (typically when ABORT or ABORT" call it), QUIT fails to restore the system to a known state. > > 1.) BASE still has the value that it had prior to the abort. > > 2.) The search-order is the same as it was prior to the abort. > > 3.) The current word-list is the same as it was prior to the abort. > > > > If compilation of a file aborts, it often happens that the user is left in the REPL and nothing works. Numbers don't work as expected because BASE is not decimal. None of the words work as expected because the search-order is screwed up. This can be truly baffling! It is baffling for me, although with my experience I can get it back into a rational state. Most novices will think that the Forth system is fatally corrupted and they will just kill the whole Forth system. Whether they feel inspired to restart Forth again, is dubious --- many will just say: "Forth sucks! I was just writing a simple program, and I must have had a bug, but then everything went haywire and the system began behaving in a truly bizarre manner. I'm going back to programming in C again!" > > > > The intelligent design for a Forth system would be for QUIT to restore global variables (such as BASE the search-order, etc.) that describe the state of the Forth system. Also, though, it would be a good idea if the contents of these global variables prior to QUIT were dumped into a snapshot data-structure so the user could examine these values to help him determine what caused the abort (quite often in a cross-compiler, getting the search-order screwed up is the cause of the abort; that is a very common bug). Also, the intelligent design for a Forth system would be for QUIT to be vectored. This is so the user can write a custom QUIT that restores some of his own global variables that describe the state of the Forth system for him. > > > > ANS-Forth was not an intelligent design. ANS-Forth was just the corpse of Charles Moore's 1970s Forth system warmed up and goaded into walking --- ANS-Forth is a zombie --- it is dead, but it just keeps on lurching forward into the future with flat-line neural activity. > > > > The Forth-200x committee, who are supposedly experts in Forth (so they say), are just sitting on their "little pink cloud" pretending that there is nothing wrong with ANS-Forth --- they are deeply delusional --- everybody in the world thinks that they are stupid, and have thought so since 1994. > > > > The only way for Forth to succeed is for ANS-Forth to be killed for good --- ANS-Forth makes the Forth community look stupid every day, in multiple ways --- anything would be better than ANS-Forth! > How about you make a proposal for that "anything"? You claim to be intelligent. Or is this not your job? Your job is just to be offensive? I have a document describing Straight Forth --- the first chapter, anyway --- I have shown it to Forth programmers (not on comp.lang.forth) and have gotten useful feedback that may cause me to change the design. A fundamental principle of Straight Forth came from Ilya Vasilyev --- I hadn't thought of that --- I immediately recognized it as a good idea though. > It makes no sense what you say. QUIT is defined. What you describe is inside definition. Just define QUIT as being a word that restarts the REPL and restores the Forth system to a rational state, and stores the state prior to the quit in a struct (also defined). Also, define QUIT as being deferred and define <QUIT> as doing what QUIT does and being the default action of the QUIT vector. The user can then define his own version of QUIT that calls <QUIT> but also does what he wants. The user can define a new struct that is a child class of the struct that <QUIT> uses --- his version of QUIT will use this child struct so it can save his important global variables in addition to the global variables that <QUIT> saves. All of this seems easy and obvious to me. You say that it doesn't make any sense? Really??? Well, the "Starting Forth" book did describe vectored execution as being a "hairy subject" --- maybe you don't understand how it works --- I doubt that anybody on the ANS-Forth committee understood how it worked. > ANS is a kind of crap and we all know it. It's something with the label "standard". And you want one too. So write a better one. I do not think you could do that, as writing such a document requires some social skills... I have repeatedly said that I want Straight Forth to be a collaborative effort of the Forth community. That is the point of talking about it here. I am willing to listen to anybody if they actually are a Forth programmer (in the sense that they write Forth programs; not just a salesperson for a corporation) and they are respectful (they don't show up braying about how they are the "leading expert" and everybody must accede to their mighty wisdom in all matters). The Forth-200x committee demand "social skills" that I consider to be brown-nosing --- they demand that all Forthers accept them as the leading experts on Forth who have the right to make the final decision on what is Forth --- they demand that every Forther approach them on his knees with suggestions, which they can then dismiss as being stupid (typically without bothering to read the suggestions at all). Who exactly elected the Forth-200x committee to be the leaders of the Forth community? No Forth programmer did! The Forth-200x committee were appointed to their exulted position by Elizabeth Rather --- most (maybe all) have financial ties to Forth Inc. --- doing what Forth Inc. tells them to do is just part of their job; this is where their paycheck comes from. You are not getting a paycheck from Forth Inc. though --- so why are you brown-nosing the Forth-200x committee? --- why are you supporting ANS-Forth, which is total crap from a technical standpoint, and which was never anything except a marketing gimmick from Forth Inc.? I suppose that brown-nosing is just an inherent aspect of many people's psychological profile --- they credit themselves with having "social skills; " what this means is that they do a lot of brown-nosing and they vaguely wish that somebody would brown-nose them --- Elizabeth Rather's whole career has depended upon finding people like this to be her supporters...
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web