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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-31 09:28 +0100 |
| Message-ID | <obl3pk$bdu$1@dont-email.me> |
| In reply to | #56498 |
On 3/31/2017 00:03, hughaguilar96@gmail.com wrote: > Alex McDonald has been putting everything I do in the doomed > category for a long time. Yup. Prove me wrong. > He says that I have a "serious misunderstanding of how pointers > work." True. SORT confused you for a long time. Hence your sort-that-moves-the-records code. > When I write code to calculate the day-of-week, he calls it "peak > stupid." I called out the pinnacle of asininity when you said (emphasis mine) === The MATHISFUN calculator says that it uses Zeller's Algorithm for calculating the day of the week. *I looked this up on Wikipedia and it appears to be no good* === Yes, peak stupid. > He actually knows nothing about Straight Forth. Who does? It's a mashup of your brain right now. Publish or be doomed. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-03-31 03:36 -0700 |
| Message-ID | <6dbe3c9c-73ab-4143-a21b-ca35c633fd57@googlegroups.com> |
| In reply to | #56498 |
пятница, 31 марта 2017 г., 2:04:00 UTC+3 пользователь hughag...@gmail.com написал: > Considering how few Forth programmers remain (and how old they are), a lot of competing standards is a bad idea. This reminds me of a cartoon I saw back in the days when the Berlin Wall was still standing. The Americans and the Russians had a joint project to send astronauts to the Moon --- when they arrived though, the first thing they did was build a wall to separate their landing site into halves. Yes, innatural activity just to show independency is not effective. There are a lot tasks where Forth may be useful, and scale is very similar to your picture - two persons for entire Moon. I remember a similar cartoon - two humsters in the stock full of peas.. and they start to divide that stock. > OTOH, I think it is possible to have two or more incompatible standards in use at the same time. ANS-Forth can be phased out gradually. ANS-Forth is rife with bad design and blatant blunders, but Forth programmers have become accustomed to working around the problems in ANS-Forth --- they are like drug addicts who are ruining their health, but don't want to stop suddenly --- they want to ease out of their bad habit gradually. I don't see any attempts to replace words like DUP DROP + - IF etc. This means we still have a naturally evolutioned Forth core, suitable for most of programmers. Details may be discussed with proper arguments, but I've never seen a propose to replace DUP by COPY or ONEMORE or someone else. > Forth-83 lacked a lot of useful features: > 1.) The ability to obtain and change attributes of words given the xt (immediate or not, which vocabulary, smudged or not, smudge-ready or not). > 2.) LOCAL for marking the last word defined as smudge-ready, and END-MODULE for changing all the smudge-ready words into smudged words. > 3.) Local variables that provide an address and are big enough that singles, doubles, floats, etc. can be stored in them. > 4.) Quotations that access the parent function's local variables. > 5.) All strings will be worked with on the string-stack. They will not be worked with in global variables (such as PAD or the <# buffer). The programmer will not work with address/count pairs on the data-stack, but will use string-stack functions. The main thing I can see here - if you can describe details and state them in consistent manner, it is your choice. Regarding to data types, I think it should be described, but not limited or defined. Stack concept itself is not limits the types of data, so int32, int64, int128, floats, strings may be implemented if needed. > There will always be advanced Forth programmers who want to write a custom Forth system. The standard allows programs to be written that are portable, and can be maintained by novice-level programmers. Even if a person is advanced, he doesn't necessarily want to turn every program into a demonstration of his awesome skill. Most of the time, he just wants to write a working program, and he wants to write it in such a way that anybody can understand how it works and it works on any Forth system --- that is what a standard would be for. Exactly. Programmers needs guides and recommendations, not calls to copy a lot of words. With less activity, it is time to give more freedom, spread technology and see what happens, and only after this to collect, reorganize and write a new standard, based on real trends and usage statistics. > Straight Forth is pretty close to Traditional Forth, but there are some differences: > > 1.) Straight Forth leaves the definition of a number undefined. I got this idea from Ilya Vasilyev. Some possibilities are: > Fixed --- a 64-bit fixed-point number with an assumed unity of 2^32. > Float --- an IEEE-754 float. > Some programs will depend upon a particular definition of number (if they need the range of IEEE-754 floats, then they can't work on the Fixed version). For the most part, programs will be portable, but they may have different results in the least-significant digits. > > 2.) Straight Forth defines arrays and chains as part of the language. The expectation is that 98% of the programs will use these two data-structures, and only 2% will use custom data-structures. Arrays and chains can be defined in Traditional Forth because we do have quotations (Forth-83, ANS-Forth and Forth-200x all lack quotations). Straight Forth programs would tend to be pretty similar, because they all use the arrays and chains (mostly chains), whereas Traditional Forth programs would vary a lot --- wild variance has always been a traditional aspect of Forth programming. I just can repeat - the main thing is you can define what you want to implement and give an explanation. Even if you are only programmer of Straight Forth, you can highlight trade-offs and show code patterns. This is totally unlike C/../C# world, where we need to think 1000 times before issue a compiler implementation. > ANS-Forth was a total failure! I think it is possible to put together a Forth standard though --- something that allows portability of programs --- this wouldn't stop advanced programmers from writing custom systems, but it would allow 98% of the Forth programs to be standard. The main problem of ANS group they don't ready to discuss non-programming matters. It is easy enough to write word with given stack notation, but local optimizations and activity can lead to... everywhere. As a starting point, I can ask simple questions: how many programmers? how many projects? how many articles? Annual income? Y-t-Y difference? Oh, 'you are a troll!' :) If all of these running low, things are going bad. No matter who is asking and how many pretty-looking words are proposed last month.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-31 19:29 -0700 |
| Message-ID | <f5807046-6fc1-43e5-be4b-33a91a4b6347@googlegroups.com> |
| In reply to | #56509 |
On Friday, March 31, 2017 at 3:36:12 AM UTC-7, Ilya Tarasov wrote:
> пятница, 31 марта 2017 г., 2:04:00 UTC+3 пользователь hughag...@gmail.com написал:
> > Forth-83 lacked a lot of useful features:
> > 1.) The ability to obtain and change attributes of words given the xt (immediate or not, which vocabulary, smudged or not, smudge-ready or not).
> > 2.) LOCAL for marking the last word defined as smudge-ready, and END-MODULE for changing all the smudge-ready words into smudged words.
> > 3.) Local variables that provide an address and are big enough that singles, doubles, floats, etc. can be stored in them.
> > 4.) Quotations that access the parent function's local variables.
> > 5.) All strings will be worked with on the string-stack. They will not be worked with in global variables (such as PAD or the <# buffer). The programmer will not work with address/count pairs on the data-stack, but will use string-stack functions.
>
> The main thing I can see here - if you can describe details and state them in consistent manner, it is your choice. Regarding to data types, I think it should be described, but not limited or defined. Stack concept itself is not limits the types of data, so int32, int64, int128, floats, strings may be implemented if needed.
I think that it is a very bad idea to have data of different sizes intermixed on the data-stack. This is the major reason why Forth has a reputation for being unreadable. We often see ANS-Forth words that are composed primarily of stack-juggling words (such as 2OVER >R etc.) and have relatively few work words that actually do something to the data other than just move it around.
With Traditional Forth and Straight Forth both, I have a separate double-stack. Mixed-precision arithmetic words use both stacks. For example:
S>D \ single: n -- \ double: -- n
UM* \ single: a b -- \ double: -- a*b
UM/MOD \ single: den -- rem quot \ double: num --
So, we never have double precision numbers on the single-stack.
Similarly, strings are held on the string-stack. You never have an address/count pair on the data-stack.
The language does limit the number of intrinsic data types and where they are held:
single-stack: single-precision number (64-bit fixed-point with unity= 2^32 )
single-stack: pointer
single-stack: xt (either a colon word or a quotation)
double-stack: double-precision number (128-bit fixed-point with unity= 2^64 )
double-stack: ratio (a 64-bit signed numerator and 64-bit unsigned denominator)
double-stack: BFI (big f'ing integer) a 128-bit fixed-point with unity=1)
string-stack: string
float-stack: IEEE-754 double-precision floating-point number
The ANS-Forth design assumes a PDP-11 that has only 7 registers. Because of this extreme register shortage, there weren't any registers available for use as stack pointers (double-stack, string-stack and float-stack) --- all of this disparate data had to be intermixed on one data-stack. Also, the return-stack had to be used for multiple purposes:
1.) hold the return-address
2.) hold the >R data
3.) hold the DO loop data
This is why we have that weird clash between >R and DO that confuses the novices --- they don't understand why their >R data isn't available inside of a DO loop --- there is no good answer for them.
My language design does, of course, limit the number of intrinsic data-types. All language designs do! A complete list is given above.
If you want any other data-type, then you have to use a struct. On the single-stack you will have a pointer to your struct. Structs are usually in the heap, but they can be in the dictionary too. Here are some examples:
class pt nada
w field .x
w field .y
w field .z
end-class
class circ pt
w field .radius
end-class
class seg nada
pt field .endA
pt field .endB
end-class
In the above, I used the naming convention of the field name starting with a dot. This naming convention is for classes that are pretty fundamental (graphics are pretty fundamental).
It is also possible to use the naming convention of the field name being the class name, followed by a dot, followed by the field name. For example:
class pt nada
w field pt.x
w field pt.y
w field pt.z
end-class
This naming convention is necessary when you have a lot of different classes in use and the field names clash. This should be used for the classes that aren't fundamental --- especially if they aren't being used in code-libraries.
> > There will always be advanced Forth programmers who want to write a custom Forth system. The standard allows programs to be written that are portable, and can be maintained by novice-level programmers. Even if a person is advanced, he doesn't necessarily want to turn every program into a demonstration of his awesome skill. Most of the time, he just wants to write a working program, and he wants to write it in such a way that anybody can understand how it works and it works on any Forth system --- that is what a standard would be for.
>
> Exactly. Programmers needs guides and recommendations, not calls to copy a lot of words. With less activity, it is time to give more freedom, spread technology and see what happens, and only after this to collect, reorganize and write a new standard, based on real trends and usage statistics.
You said: "Exactly."
But then you said exactly the opposite of what I was saying!
I am saying that the Forth community knows enough now to design a language that is capable of supporting 98% of the programs that we want to write. Advanced programmers will write the other 2% of the programs, and they will use a custom language that is non-standard.
I am saying that my language would mostly be used for writing novice-level programs,
and only rarely used for writing intermediate-level programs,
and will never be used for writing advanced-level programs.
Obviously, novice-level programmers can only write novice-level programs. Intermediate-level and advanced-level programmers will mostly write novice-level programs too --- if the program does the job, then there is no need to make it more complicated.
Intermediate-level and advanced-level programmers will only write intermediate-level programs when this is really necessary, because the job can't be done with novice-level programming --- when they do this, they will be stuck with maintaining the program themselves --- they can't turn the program maintenance over to a novice, because the novice can't understand an intermediate-level program.
I'm not trying to design the most whiz-bang Forth ever. I just want a standard Forth that would be useful for writing 98% of the programs that people need to write. ANS-Forth is utterly useless! I can do better than this --- you could do better than this too --- anybody with a three-digit I.Q. could do better than this.
Forth-200x is going in the wrong direction --- their recognizers are just gratuitous whiz-bang, but are not useful at all --- the Forth-200x enthusiasts all want to be advanced-level programmers, although most of them know little or nothing about programming, and have never done anything useful in their entire life.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-01 04:37 -0700 |
| Message-ID | <94859086-568f-462d-9aa0-ac95d52a8e33@googlegroups.com> |
| In reply to | #56517 |
Agree. I'd even go so far as to advocate a control stack so that the return stack can be used if necessary inside loops.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-01 09:23 -0700 |
| Message-ID | <87zig05c6r.fsf@nightsong.com> |
| In reply to | #56532 |
Mark Wills <markwills1970@gmail.com> writes: > Agree. I'd even go so far as to advocate a control stack so that the > return stack can be used if necessary inside loops. Wait, what? You want a separate stack for loop indices? Ok, but why not put the return address there too, so the formerly return stack would be available for arbitrary user data?
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-01 10:37 -0700 |
| Message-ID | <900af364-9ab1-42b9-a1d9-ba84dc4a97fc@googlegroups.com> |
| In reply to | #56543 |
суббота, 1 апреля 2017 г., 19:23:41 UTC+3 пользователь Paul Rubin написал:
> Mark Wills <markwills1970@gmail.com> writes:
> > Agree. I'd even go so far as to advocate a control stack so that the
> > return stack can be used if necessary inside loops.
>
> Wait, what? You want a separate stack for loop indices? Ok, but why
> not put the return address there too, so the formerly return stack would
> be available for arbitrary user data?
A possible effect of separate LOOP stack:
---------------------------------------------
: INSIDE
5 0 DO
J . I . CR
LOOP
;
: TEST
5 0 DO INSIDE LOOP
;
TEST
---------------------------------------------
Both I and J are accessible in the nested loop.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-01 11:55 -0500 |
| Message-ID | <vK2dnSt14M0TRkLFnZ2dnUU7-I-dnZ2d@supernews.com> |
| In reply to | #56532 |
Mark Wills <markwills1970@gmail.com> wrote: > Agree. I'd even go so far as to advocate a control stack so that the > return stack can be used if necessary inside loops. It's quite easy to forget that the Forth dual-stack design is intended to allow small tasks. That's fairly easy as long as you just have two stacks and a user area, but gets really awkward with several stacks. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-01 14:15 -0700 |
| Message-ID | <ffb187a4-fe8b-451c-826a-fdb3e5792623@googlegroups.com> |
| In reply to | #56545 |
On Saturday, April 1, 2017 at 9:55:49 AM UTC-7, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: > > Agree. I'd even go so far as to advocate a control stack so that the > > return stack can be used if necessary inside loops. > > It's quite easy to forget that the Forth dual-stack design is intended > to allow small tasks. That's fairly easy as long as you just have two > stacks and a user area, but gets really awkward with several stacks. > > Andrew. Elizabeth Rather designed ANS-Forth for computers with only a handful of registers and only a few KB of RAM --- her employee Andrew Haley is just parroting her as usual --- such small memory systems haven't existed since the 1970s (that is why they are "quite easy to forget").
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-05-06 12:55 -0700 |
| Message-ID | <e496f2c1-f9e9-4bd2-824b-5a7f42f8a18f@googlegroups.com> |
| In reply to | #56553 |
On Saturday, April 1, 2017 at 2:15:51 PM UTC-7, hughag...@gmail.com wrote: > On Saturday, April 1, 2017 at 9:55:49 AM UTC-7, Andrew Haley wrote: > > Mark Wills <markwills1970@gmail.com> wrote: > > > Agree. I'd even go so far as to advocate a control stack so that the > > > return stack can be used if necessary inside loops. > > > > It's quite easy to forget that the Forth dual-stack design is intended > > to allow small tasks. That's fairly easy as long as you just have two > > stacks and a user area, but gets really awkward with several stacks. > > > > Andrew. > > Elizabeth Rather designed ANS-Forth for computers with only a handful of registers and only a few KB of RAM --- her employee Andrew Haley is just parroting her as usual --- such small memory systems haven't existed since the 1970s (that is why they are "quite easy to forget"). Elizabeth took on the job of herding cats, which wasn't an easy one. It got so crazy that Chuck Moore walked out on the TC. But, she did it. Standards appeal to the lowest common denominator, but it's what customers wanted. It reminds me of a line from the film "Clerks". "This job would be great if it wasn't for the f--king customers". ANS isn't perfect, but you can't blame that on her or on a concussion caused by a crazy surfer. Small footprint isn't the point. Simplicity is the point. There's always creeping complexity whose costs are always underestimated. Pursuit of simplicity is part of Forth's legacy and really what Forth is. You might say brutal simplicity is all Forth has left. It's why Forth will always be here. Complexity would kill a really great thing.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 12:08 +0100 |
| Message-ID | <oemv1s$o7k$1@dont-email.me> |
| In reply to | #58749 |
On 5/6/2017 20:55, Brad Eckert wrote: > Standards appeal to the lowest common denominator Well, a common denominator, and that denominator is often the highest. On other standard's bodies, I see companies bringing to the table their best ideas and asking for standardization. I can provide documented and recent examples if you're interested. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-07 09:04 -0700 |
| Message-ID | <4b71c320-60fc-4875-8aba-a54ff8dcf77b@googlegroups.com> |
| In reply to | #58764 |
On Sunday, May 7, 2017 at 4:08:50 AM UTC-7, Alex wrote: > On 5/6/2017 20:55, Brad Eckert wrote: > > Standards appeal to the lowest common denominator > > Well, a common denominator, and that denominator is often the highest. > On other standard's bodies, I see companies bringing to the table their > best ideas and asking for standardization. I can provide documented and > recent examples if you're interested. > > -- > Alex That explains how PAD got put in the ANS-Forth standard! ;-)
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-04-01 21:35 +0200 |
| Message-ID | <h5eqtou12398.11ah7l4r38tt9.dlg@40tude.net> |
| In reply to | #56532 |
Op Sat, 1 Apr 2017 04:37:15 -0700 (PDT) schreef Mark Wills: > Agree. I'd even go so far as to advocate a control stack so that the return stack can be used if necessary inside loops. Please cite at least _some_ context. This way using a real newsreader is painful. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-01 20:35 -0400 |
| Message-ID | <20170401203553.11b56b51@_> |
| In reply to | #56532 |
On Sat, 1 Apr 2017 04:37:15 -0700 (PDT) Mark Wills <markwills1970@gmail.com> wrote: > Agree. I'd even go so far as to advocate a control stack so that the > return stack can be used if necessary inside loops. Have you tried using a dedicated stack for I J K values? Would that speed up loops by eliminating some overhead? 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 | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-01 11:52 -0700 |
| Message-ID | <f24db1ab-48f5-40e3-b362-038e07c3597f@googlegroups.com> |
| In reply to | #56517 |
> > The main thing I can see here - if you can describe details and state them in consistent manner, it is your choice. Regarding to data types, I think it should be described, but not limited or defined. Stack concept itself is not limits the types of data, so int32, int64, int128, floats, strings may be implemented if needed. > > I think that it is a very bad idea to have data of different sizes intermixed on the data-stack. This is the major reason why Forth has a reputation for being unreadable. We often see ANS-Forth words that are composed primarily of stack-juggling words (such as 2OVER >R etc.) and have relatively few work words that actually do something to the data other than just move it around. No, I don't have in mind we need to mix different data types. I just want to note we have push/pop commands independent from the data size/type. So if you want to use data stack with int32, this can be done. If you want to have int64, or universal 128/256 bit cell, this also can be done. I don't see here any reason to restrict data stack implementation or bind Forth as a language concept to certain data type/size. > Similarly, strings are held on the string-stack. You never have an address/count pair on the data-stack. Again, this is very important to describe the approach. I don't want to put a principal critics not on separate string stack neither on addr, count / szptr / something else. This must not break Forth concept at all. > This is why we have that weird clash between >R and DO that confuses the novices --- they don't understand why their >R data isn't available inside of a DO loop --- there is no good answer for them. This is why an explanation is very important here. This explanation, created for beginners, may also point to possible improvements. > > > There will always be advanced Forth programmers who want to write a custom Forth system. The standard allows programs to be written that are portable, and can be maintained by novice-level programmers. Even if a person is advanced, he doesn't necessarily want to turn every program into a demonstration of his awesome skill. Most of the time, he just wants to write a working program, and he wants to write it in such a way that anybody can understand how it works and it works on any Forth system --- that is what a standard would be for. > > > > Exactly. Programmers needs guides and recommendations, not calls to copy a lot of words. With less activity, it is time to give more freedom, spread technology and see what happens, and only after this to collect, reorganize and write a new standard, based on real trends and usage statistics. > > You said: "Exactly." > But then you said exactly the opposite of what I was saying! > > I am saying that the Forth community knows enough now to design a language that is capable of supporting 98% of the programs that we want to write. Advanced programmers will write the other 2% of the programs, and they will use a custom language that is non-standard. Correct, my 'programmers' describes 'advanced programmers'. They need a how-to about main algorithms and approaches to create their implementation. But beginners also need a pack of guides, covering simple code patterns etc. The problem in ANS is there is no clear concept of Forth in practical meaning. > I am saying that my language would mostly be used for writing novice-level programs, > and only rarely used for writing intermediate-level programs, > and will never be used for writing advanced-level programs. This is corresponds with what I'm saying. Just define your goals, describe ways to achieve and keep all consistent. > I'm not trying to design the most whiz-bang Forth ever. I just want a standard Forth that would be useful for writing 98% of the programs that people need to write. ANS-Forth is utterly useless! I can do better than this --- you could do better than this too --- anybody with a three-digit I.Q. could do better than this. I'm sure right way is not to create a 'perfect Forth', but to know how create a certain Forth for given target domain. Yes, this means having a product is no longer provide a sweet life (if any kind of sweet life exist for someone if Forth community). More important is having skill to create and adopt Forth concept to solve a certain task. > Forth-200x is going in the wrong direction --- their recognizers are just gratuitous whiz-bang, but are not useful at all --- the Forth-200x enthusiasts all want to be advanced-level programmers, although most of them know little or nothing about programming, and have never done anything useful in their entire life. I just know a real enthusiast is usually desire communications and ready to find new ways to cooperate. 'Write code for our language' is not a call to cooperation. But those who don't want to break an ullision they are experts in the world full of agressors, just scary.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-01 16:31 -0700 |
| Message-ID | <73c4d92e-3d2f-43fc-84c9-6eee57550016@googlegroups.com> |
| In reply to | #56548 |
On Saturday, April 1, 2017 at 11:52:31 AM UTC-7, Ilya Tarasov wrote: > > > The main thing I can see here - if you can describe details and state them in consistent manner, it is your choice. Regarding to data types, I think it should be described, but not limited or defined. Stack concept itself is not limits the types of data, so int32, int64, int128, floats, strings may be implemented if needed. > > > > I think that it is a very bad idea to have data of different sizes intermixed on the data-stack. This is the major reason why Forth has a reputation for being unreadable. We often see ANS-Forth words that are composed primarily of stack-juggling words (such as 2OVER >R etc.) and have relatively few work words that actually do something to the data other than just move it around. > > No, I don't have in mind we need to mix different data types. I just want to note we have push/pop commands independent from the data size/type. So if you want to use data stack with int32, this can be done. If you want to have int64, or universal 128/256 bit cell, this also can be done. I don't see here any reason to restrict data stack implementation or bind Forth as a language concept to certain data type/size. I understand you now! You don't like my Straight Forth idea of setting the cell size at 64-bit. Well, that is a controversial idea. Traditionally, Forth has allowed the cell size to be anything. In Forth-83 I had a constant defined like one of these: 2 constant w \ 16-bit 4 constant w \ 32-bit It was common for me to write programs that ran on either 16-bit or 32-bit UR/Forth just by changing this constant --- afaik, everybody did something similar. In those days however, both 16-bit and 32-bit computers were common. About 10 or 15 years ago, both 32-bit and 64-bit computers were common. Now however, only 64-bit computers are common, and it is unlikely that we will get 128-bit computers as the trend now is to have multi-core 64-bit processors but to not get larger cell sizes. Straight Forth is for desktop computers that are going to be 64-bit. With Traditional Forth however, I would be okay with a variable 32-bit, 64-bit etc. cell size --- allowing any cell size is traditional going back to Forth-83. > > Similarly, strings are held on the string-stack. You never have an address/count pair on the data-stack. > > Again, this is very important to describe the approach. I don't want to put a principal critics not on separate string stack neither on addr, count / szptr / something else. This must not break Forth concept at all. I can email you a copy of STRING-STACK.4TH --- or just wait for the next novice-package release when this will be included --- I could release the novice-package upgrade at any time, but I'm delaying as I write some documentation. > > This is why we have that weird clash between >R and DO that confuses the novices --- they don't understand why their >R data isn't available inside of a DO loop --- there is no good answer for them. > > This is why an explanation is very important here. This explanation, created for beginners, may also point to possible improvements. If the subject can't be explained to beginners in a way that they will understand, then it is usually because the subject doesn't make any sense. This has always been a problem in Forth. A lot of the design decisions that Charles Moore made back in the 1970s assumed an extremely limited processor, and those design decisions didn't make any sense in 1994 when ANS-Forth became the standard. Also, I think Charles Moore was writing programs under deadline and some of his design decisions for Forth were just expedient hacks needed to get a particular application program into the customer's hands --- if he hadn't gotten kicked out of Forth Inc. in 1982, he would have fixed these problems --- he never intended these bad decisions to be written in stone and be considered to be unquestionable all the way into the 21st century. > > > > There will always be advanced Forth programmers who want to write a custom Forth system. The standard allows programs to be written that are portable, and can be maintained by novice-level programmers. Even if a person is advanced, he doesn't necessarily want to turn every program into a demonstration of his awesome skill. Most of the time, he just wants to write a working program, and he wants to write it in such a way that anybody can understand how it works and it works on any Forth system --- that is what a standard would be for. > > > > > > Exactly. Programmers needs guides and recommendations, not calls to copy a lot of words. With less activity, it is time to give more freedom, spread technology and see what happens, and only after this to collect, reorganize and write a new standard, based on real trends and usage statistics. > > > > You said: "Exactly." > > But then you said exactly the opposite of what I was saying! > > > > I am saying that the Forth community knows enough now to design a language that is capable of supporting 98% of the programs that we want to write. Advanced programmers will write the other 2% of the programs, and they will use a custom language that is non-standard. > > Correct, my 'programmers' describes 'advanced programmers'. They need a how-to about main algorithms and approaches to create their implementation. But beginners also need a pack of guides, covering simple code patterns etc. The problem in ANS is there is no clear concept of Forth in practical meaning. These are my definitions: 1.) novice Forth programmer --- Understands Forth fully and is capable of writing most programs. Understands basic meta-compiling. Needs to use built-in data-structures (arrays and chains) rather than write his own. Does not know how to design general-purpose code and so is not able to write a code library. 2.) intermediate Forth programmer --- Knows how to design general-purpose code and so is able to write a code library. This includes writing HOFs. Also should be comfortable with meta-programming at a pretty complicated level. Should be able to write a cross-compiler. 3.) advanced Forth programmer --- Should be able to write an assembler for a processor that packs multiple instructions into each opcode. The assembler should rearrange the instructions in order to pack them efficiently (minimize how many NOP instructions have to be inserted) while still guaranteeing that the program does the same thing as if the instructions were compiled one-per-opcode in the order that they appeared in the source-code. Note that I'm the only advanced Forth programmer in the world. > > I am saying that my language would mostly be used for writing novice-level programs, > > and only rarely used for writing intermediate-level programs, > > and will never be used for writing advanced-level programs. > > This is corresponds with what I'm saying. Just define your goals, describe ways to achieve and keep all consistent. > > > I'm not trying to design the most whiz-bang Forth ever. I just want a standard Forth that would be useful for writing 98% of the programs that people need to write. ANS-Forth is utterly useless! I can do better than this --- you could do better than this too --- anybody with a three-digit I.Q. could do better than this. > > I'm sure right way is not to create a 'perfect Forth', but to know how create a certain Forth for given target domain. Yes, this means having a product is no longer provide a sweet life (if any kind of sweet life exist for someone if Forth community). More important is having skill to create and adopt Forth concept to solve a certain task. You are assuming that the "certain Forth for given target domain" will be incompatible with other Forths for other target domains. This is not what a standard is for though! A standard is for the 98% of the programs that don't require any special effort. It is not a perfect Forth because it only covers 98% rather than 100%, but it is reasonable. A standard doesn't say anything about the 2% that need special effort. You are free to write some guidelines for doing this. This can never be standardized though.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-04-01 20:54 -0700 |
| Message-ID | <b3cb76c4-708a-40e2-b8eb-be2dadc1b654@googlegroups.com> |
| In reply to | #56555 |
On Saturday, April 1, 2017 at 6:31:30 PM UTC-5, hughag...@gmail.com wrote:
> On Saturday, April 1, 2017 at 11:52:31 AM UTC-7, Ilya Tarasov wrote:
> > Correct, my 'programmers' describes 'advanced programmers'. They need a how-to about main algorithms and approaches to create their implementation. But beginners also need a pack of guides, covering simple code patterns etc. The problem in ANS is there is no clear concept of Forth in practical meaning.
It's a standard. It's deficient as a tutorial and as a vehicle for a
'clear concept of Forth' and as many other things that are not
standards.
But I agree that there's a need to communicate to people how Forth is
used. There are in programming communities all kinds of 'frameworks'
that are, essentially, just documented workflows for getting simple
things done. Many of them are not many steps above
*** ADDINATOR 7.0 ***
A FRAMEWORK FOR SUMMING NEARLY ANY NUMBER OF FIGURES
1 2 3 \ the figures thou aimst to sum
3 \ a counte of aforesaid numbers
ADDINATOR \ pure magic! Don't think about how it works!
. \ output: 6 -- amazing! so easy!
THIS WORK WITHOUT THE ADDINATOR:
1 2 + 3 + . \ feeling RSI pain? immediately call your doctor
IT EVEN WORKS FOR FIGURES HAVING MULTIPLE DIGITS
1 10 100 1000 10000 \ evene five is not excessive!
5 \ don't forget the count!
ADDINATOR . \ output: 11111 -- it's so easy!
THIS WORK WITHOUT THE ADDINATOR:
1 10 + \ so confusing!
100 1000 \ consistency???
10000 + + + + + \ spot the error?
CLICK [THIS LINK] FOR MY COMPANION FRAMEWORK: THE SUBTRACTAZOR.
I HAVE FINALLY RELEASED THE 1.0 VERSION OF IT
But even if people want to disguise their documentation, it's good to
have it. It's disappointing when people look and Forth and its tools
and conclude: I have no idea how to make a program out of this.
Here, libraries are a bit of a trap for Forth. People think them a
solution to the problem but they only delay the onset of the "I have
no idea" realization. The thing itself can be directly attacked. If
that's unclear, I plan to post some attacks on it soon, so please
wait for that.
> These are my definitions:
>
> 1.) novice Forth programmer --- Understands Forth fully and is capable of writing most programs. Understands basic meta-compiling. Needs to use built-in data-structures (arrays and chains) rather than write his own. Does not know how to design general-purpose code and so is not able to write a code library.
> 2.) intermediate Forth programmer --- Knows how to design general-purpose code and so is able to write a code library. This includes writing HOFs. Also should be comfortable with meta-programming at a pretty complicated level. Should be able to write a cross-compiler.
> 3.) advanced Forth programmer --- Should be able to write an assembler for a processor that packs multiple instructions into each opcode. The assembler should rearrange the instructions in order to pack them efficiently (minimize how many NOP instructions have to be inserted) while still guaranteeing that the program does the same thing as if the instructions were compiled one-per-opcode in the order that they appeared in the source-code.
> Note that I'm the only advanced Forth programmer in the world.
Hugh's posts are mostly just depressing or sickening to read, but on
occasion you can get a pretty good laugh out of them. This post even
has the structure of a joke, with the long ramp-up of absurdity
followed by a punch-line.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-01 21:13 -0700 |
| Message-ID | <b119e872-1fc1-4b6d-9816-9b4165ad985e@googlegroups.com> |
| In reply to | #56563 |
On Saturday, April 1, 2017 at 8:54:58 PM UTC-7, Julian Fondren wrote: > On Saturday, April 1, 2017 at 6:31:30 PM UTC-5, hughag...@gmail.com wrote: > > These are my definitions: > > > > 1.) novice Forth programmer --- Understands Forth fully and is capable of writing most programs. Understands basic meta-compiling. Needs to use built-in data-structures (arrays and chains) rather than write his own. Does not know how to design general-purpose code and so is not able to write a code library. > > > 2.) intermediate Forth programmer --- Knows how to design general-purpose code and so is able to write a code library. This includes writing HOFs. Also should be comfortable with meta-programming at a pretty complicated level. Should be able to write a cross-compiler. > > > 3.) advanced Forth programmer --- Should be able to write an assembler for a processor that packs multiple instructions into each opcode. The assembler should rearrange the instructions in order to pack them efficiently (minimize how many NOP instructions have to be inserted) while still guaranteeing that the program does the same thing as if the instructions were compiled one-per-opcode in the order that they appeared in the source-code. > > > Note that I'm the only advanced Forth programmer in the world. > > Hugh's posts are mostly just depressing or sickening to read, but on > occasion you can get a pretty good laugh out of them. This post even > has the structure of a joke, with the long ramp-up of absurdity > followed by a punch-line. I'm the only Forth programmer in the world who has done the advanced-level Forth described above. It seemed pretty complicated when I did it, but that was also almost a quarter of a century ago. Nowadays an assembler like that would be easier for me, and given the novice-package I could make the code more readable. Maybe my assembler should be in the intermediate-level category --- in that case, I don't know what an advanced-level Forth programmer would be --- I suppose that designing Straight Forth could count as being advanced-level Forth, but I haven't completed that, so I'm still not advanced-level. It is possible that either Ilya Tarasov or Walter Banks has written such an assembler, as they are our FPGA guys --- if so, perhaps they could comment on the definition of an advanced-level Forth programmer --- I could do without comments on the subject from sub-novice Forth programmers though.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-05 16:06 -0700 |
| Message-ID | <32eee530-63d3-40b0-b101-1827161b32cc@googlegroups.com> |
| In reply to | #56555 |
воскресенье, 2 апреля 2017 г., 2:31:30 UTC+3 пользователь hughag...@gmail.com написал: > I understand you now! You don't like my Straight Forth idea of setting the cell size at 64-bit. Well, that is a controversial idea. Traditionally, Indeed I like it :) Moving to 64 bits is a known trend, so it is in time. Maybe I need to think about other features you suggest, because just having 64 bits is very good, without more pretty looking formats. > In those days however, both 16-bit and 32-bit computers were common. About 10 or 15 years ago, both 32-bit and 64-bit computers were common. Now however, only 64-bit computers are common, and it is unlikely that we will get 128-bit computers as the trend now is to have multi-core 64-bit processors but to not get larger cell sizes. > > Straight Forth is for desktop computers that are going to be 64-bit. With Traditional Forth however, I would be okay with a variable 32-bit, 64-bit etc. cell size --- allowing any cell size is traditional going back to Forth-83. This is exactly I wrote many times. Not so important, how pretty things are looking. Feature list should be consistent. While you basing on common and proven trends, you have a very strong position in general. Details may be discussed. This style is far more better than minor proposals, proven by a couple of Forth hobbysts, even certain feature may be worse. > I can email you a copy of STRING-STACK.4TH --- or just wait for the next novice-package release when this will be included --- I could release the novice-package upgrade at any time, but I'm delaying as I write some documentation. I may take a look, but I don't feel it is critical. > > This is why an explanation is very important here. This explanation, created for beginners, may also point to possible improvements. > > If the subject can't be explained to beginners in a way that they will understand, then it is usually because the subject doesn't make any sense. This has always been a problem in Forth. A lot of the design decisions that Charles Moore made back in the 1970s assumed an extremely limited processor, and those design decisions didn't make any sense in 1994 when ANS-Forth became the standard. Also, I think Charles Moore was writing programs under deadline and some of his design decisions for Forth were just expedient hacks needed to get a particular application program into the customer's hands --- if he hadn't gotten kicked out of Forth Inc. in 1982, he would have fixed these problems --- he never intended these bad decisions to be written in stone and be considered to be unquestionable all the way into the 21st century. Hmm... looks like this. Forth is a mix of fundamental language approach (postfix, stack, linked list for words) and practical implementations (PAD, blocks). Some of practical solutions are obsolete today, since alternatives are known. So a kind of demystification should be done. > > Correct, my 'programmers' describes 'advanced programmers'. They need a how-to about main algorithms and approaches to create their implementation. But beginners also need a pack of guides, covering simple code patterns etc. The problem in ANS is there is no clear concept of Forth in practical meaning. > > These are my definitions: > > 1.) novice Forth programmer --- Understands Forth fully and is capable of writing most programs. Understands basic meta-compiling. Needs to use built-in data-structures (arrays and chains) rather than write his own. Does not know how to design general-purpose code and so is not able to write a code library. > > 2.) intermediate Forth programmer --- Knows how to design general-purpose code and so is able to write a code library. This includes writing HOFs. Also should be comfortable with meta-programming at a pretty complicated level. Should be able to write a cross-compiler. > > 3.) advanced Forth programmer --- Should be able to write an assembler for a processor that packs multiple instructions into each opcode. The assembler should rearrange the instructions in order to pack them efficiently (minimize how many NOP instructions have to be inserted) while still guaranteeing that the program does the same thing as if the instructions were compiled one-per-opcode in the order that they appeared in the source-code. > > Note that I'm the only advanced Forth programmer in the world. This is a possible solution, but I can see several 'axes' to measure. You describe skills, but also it may be a level of understanding system aspects. Also, I know at least one forther who can write an optimized compiler, assembler or C-style PL. I don't know what exactly you did with opcodes packing and optimizing and I have no goal to organize or take part in any coding contest :) If you have a product, you (and others) may take a look on further promotion and positioning. > You are assuming that the "certain Forth for given target domain" will be incompatible with other Forths for other target domains. This is not what a standard is for though! Yes. This is not a special goal, but a practical assumption indeed. > A standard is for the 98% of the programs that don't require any special effort. It is not a perfect Forth because it only covers 98% rather than 100%, but it is reasonable. > > A standard doesn't say anything about the 2% that need special effort. You are free to write some guidelines for doing this. This can never be standardized though. Another level of determine qualification may come from army examples. Let's imagine we have an order to take a fortified hill. 1. Soldier. 'I must run fast, shoot my targets and use obstacles for hide' 2. Sergeant. 'I must inspire my squad, watch for danger and issue tactical orders in time' 3. Captain 'I must decide to stop attack and call for reinforcement or artillery strike, because that hill looks fortified strong'. 4. General 'I must find a moment to regroup troops, because attacking that hill probably took reserves and made other positions weak' 5. Diplomat 'I must use our success on that hill for pressing their government' All these thinks in different terms and have different deep of system-level vision. What stle is using now by Rather, Ertl & Co? I see no higher than sergeant level :) 'Write programs, use standard and work together' is like 'attack bravely, be inspired by our banner, hold your line'.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-31 09:42 +0100 |
| Message-ID | <obl4k0$e4e$1@dont-email.me> |
| In reply to | #56495 |
On 3/30/2017 22:07, Ilya Tarasov wrote: > How do you think, do we need a word of wisdom, starting from 'our > poor newbies, welcome to the bright world of Forth and let us guide > you'? Stop guessing about what I think. It's all you've done in this entire thread. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-03-31 03:52 -0700 |
| Message-ID | <20cf5ee1-9ce9-49e0-bc30-4da0254f23b3@googlegroups.com> |
| In reply to | #56505 |
пятница, 31 марта 2017 г., 11:42:28 UTC+3 пользователь Alex написал: > On 3/30/2017 22:07, Ilya Tarasov wrote: > > How do you think, do we need a word of wisdom, starting from 'our > > poor newbies, welcome to the bright world of Forth and let us guide > > you'? > > Stop guessing about what I think. It's all you've done in this entire > thread. I'm just asking you, not guessing :) If you feel a trouble finding arguments or lead a logic, this is a simple approach. Would you like to sell you car for 1$? For 1000000? Ok, now we have 'of course no' and 'of course, yes'. So real price of your car is somewhere between. If you can clearly describe what is 100% not needed for programmers, and what is really needed, we can continue to lead. Repeating 'standards allows programmers to work together' is far away from the problem.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web