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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-21 02:30 -0700 |
| Message-ID | <9da02a1a-9361-4ec4-b1b2-d47f65904c23@googlegroups.com> |
| In reply to | #55988 |
On Tuesday, 21 March 2017 02:12:09 UTC, hughag...@gmail.com wrote: > On Monday, March 20, 2017 at 9:58:20 AM UTC-7, Helmar Wodtke wrote: > > Well, I did not reply to BIG/GREAT ;) > > > > Most people think that GREAT is some BIGger advanture, what a Forth system has to offer. > > > > What do you expect? A GUI-API? What number of GUIs has Forth survived? How complicated it is, to connect Forth to any user interface? > > > > Do you really want a "BUTTON" ( gui x y w h s -- gui' ) word defined in standard? > > > > Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". > > > > Regards, > > -Helmar > > How about: "Make Forth Sane Again!" > > With my Straight Forth design, I am getting rid of a lot of cruft. I don't have DO loops anymore, for example. > So, small is beautiful! > > On the other hand, I am adding two data-structures --- the array and the chain --- I expect maybe 99% of the programs to use these, and only 1% to have custom data-structures. > So, big is beautiful! > > I agree that we don't want to put a GUI code-library in the standard --- it should be possible to write code-libraries such as this in the standard --- it would be best to write versions for every OS that the system might be running on, so it will require somebody who knows a lot (knows more than I do). > > OTOH, some words are very useful --- an example is TICKS that gives the current time in milliseconds --- something like this would be difficult for the user to write, as it would require knowledge of every OS that the system might be running on. > > I might also have graphics capability built into the language --- that seems useful to everybody --- unfortunately, this is somewhat beyond my knowledge-level (a lot of useful programming is beyond my knowledge-level). I think the standard is very nearly there. I would like to see a moratorium on adding new words to the standard, and a focused effort to eradicate the use of "may" in the standard and a lot more use of "shall". The disambiguator code that Hugh developed is a good example of why this is necessary. If the true goal of the standard is portability (and it is, it's stated right there in the opening text of the standard) then more focus on removing the ambiguity is required. You can't blame the vendors for taking advantage of holes in a standard. You can only blame when their product doesn't conform to the standard. But at the moment, the standard (in some areas, by no means, all) is not prescriptive enough. I would also develop an appendix showing examples of every word in core, showing the outputs for given inputs, including corner cases. This is the essence of a standard (in my opinion): demonstration of compliance. If the standard itself includes test cases then you can be quite confident early on that your system is compliant; bugs in the implementation (or in the standard ;-) notwithstanding. Almost no standards that I have seen do this though, so the Forth TC is free of blame here, too. We should try and get away from blaming or criticising the TC for the short-comings, and try to come together, collaboratively, with a spirit of cooperation. This happens all over the world in the standards "world" with companies that are fierce competitors coming together to improve standards, which in turn helps them to focus product development. In involved with some of this in the water industry right now, and the members of the DNP3 WITS organisations are ALL competitors, yet they get on very well and progress is good, and sprits high. Why can't we do that in the Forth community?
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-03-21 02:47 -0700 |
| Message-ID | <91586907-716d-4f6b-8a50-ef02e800f71c@googlegroups.com> |
| In reply to | #55997 |
> I would also develop an appendix showing examples of every word in core, > showing the outputs for given inputs, including corner cases. This is the > essence of a standard (in my opinion): demonstration of compliance. If > the standard itself includes test cases then you can be quite confident > early on that your system is compliant; bugs in the implementation (or > in the standard ;-) notwithstanding. Almost no standards that I have seen > do this though, so the Forth TC is free of blame here, too. One can download the full test suite from the Forth200x site. It contains 3 test file (along with Hayes' venerable core.fr) alone for the core wordset. What are you missing?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 05:56 -0500 |
| Message-ID | <1N-dnfHgE6hOm0zFnZ2dnUU7-YOdnZ2d@supernews.com> |
| In reply to | #55997 |
Mark Wills <markwills1970@gmail.com> wrote: > > I think the standard is very nearly there. I would like to see a moratorium > on adding new words to the standard, and a focused effort to eradicate the > use of "may" in the standard and a lot more use of "shall". This is all very well in theory, but some concrete examples would be far more productive. > We should try and get away from blaming or criticising the TC for > the short-comings, and try to come together, collaboratively, with a > spirit of cooperation. This happens all over the world in the > standards "world" with companies that are fierce competitors coming > together to improve standards, which in turn helps them to focus > product development. In involved with some of this in the water > industry right now, and the members of the DNP3 WITS organisations > are ALL competitors, yet they get on very well and progress is good, > and sprits high. > > Why can't we do that in the Forth community? We do. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-21 16:07 -0400 |
| Message-ID | <oas10f$4kn$1@dont-email.me> |
| In reply to | #55997 |
On 3/21/2017 5:30 AM, Mark Wills wrote: > On Tuesday, 21 March 2017 02:12:09 UTC, hughag...@gmail.com wrote: >> On Monday, March 20, 2017 at 9:58:20 AM UTC-7, Helmar Wodtke wrote: >>> Well, I did not reply to BIG/GREAT ;) >>> >>> Most people think that GREAT is some BIGger advanture, what a Forth system has to offer. >>> >>> What do you expect? A GUI-API? What number of GUIs has Forth survived? How complicated it is, to connect Forth to any user interface? >>> >>> Do you really want a "BUTTON" ( gui x y w h s -- gui' ) word defined in standard? >>> >>> Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". >>> >>> Regards, >>> -Helmar >> >> How about: "Make Forth Sane Again!" >> >> With my Straight Forth design, I am getting rid of a lot of cruft. I don't have DO loops anymore, for example. >> So, small is beautiful! >> >> On the other hand, I am adding two data-structures --- the array and the chain --- I expect maybe 99% of the programs to use these, and only 1% to have custom data-structures. >> So, big is beautiful! >> >> I agree that we don't want to put a GUI code-library in the standard --- it should be possible to write code-libraries such as this in the standard --- it would be best to write versions for every OS that the system might be running on, so it will require somebody who knows a lot (knows more than I do). >> >> OTOH, some words are very useful --- an example is TICKS that gives the current time in milliseconds --- something like this would be difficult for the user to write, as it would require knowledge of every OS that the system might be running on. >> >> I might also have graphics capability built into the language --- that seems useful to everybody --- unfortunately, this is somewhat beyond my knowledge-level (a lot of useful programming is beyond my knowledge-level). > > I think the standard is very nearly there. I would like to see a moratorium > on adding new words to the standard, and a focused effort to eradicate the > use of "may" in the standard and a lot more use of "shall". The disambiguator > code that Hugh developed is a good example of why this is necessary. > If the true goal of the standard is portability (and it is, it's stated right > there in the opening text of the standard) then more focus on removing the > ambiguity is required. You can't blame the vendors for taking advantage of > holes in a standard. You can only blame when their product doesn't conform to > the standard. But at the moment, the standard (in some areas, by no means, > all) is not prescriptive enough. > > I would also develop an appendix showing examples of every word in core, > showing the outputs for given inputs, including corner cases. This is the > essence of a standard (in my opinion): demonstration of compliance. If > the standard itself includes test cases then you can be quite confident > early on that your system is compliant; bugs in the implementation (or > in the standard ;-) notwithstanding. Almost no standards that I have seen > do this though, so the Forth TC is free of blame here, too. > > We should try and get away from blaming or criticising the TC for the > short-comings, and try to come together, collaboratively, with a spirit > of cooperation. This happens all over the world in the standards "world" > with companies that are fierce competitors coming together to improve > standards, which in turn helps them to focus product development. In > involved with some of this in the water industry right now, and the > members of the DNP3 WITS organisations are ALL competitors, yet they > get on very well and progress is good, and sprits high. > > Why can't we do that in the Forth community? I would ask why you aren't part of the effort to update the standard? I know why Hugh isn't. He is far too argumentative. But why don't you work with the TC? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-21 14:28 -1000 |
| Message-ID | <vdydnVBdrsenWEzFnZ2dnUU7-YPNnZ2d@supernews.com> |
| In reply to | #55997 |
On 3/20/17 11:30 PM, Mark Wills wrote: ... > > I think the standard is very nearly there. I would like to see a moratorium > on adding new words to the standard, and a focused effort to eradicate the > use of "may" in the standard and a lot more use of "shall". The disambiguator > code that Hugh developed is a good example of why this is necessary. > If the true goal of the standard is portability (and it is, it's stated right > there in the opening text of the standard) then more focus on removing the > ambiguity is required. You can't blame the vendors for taking advantage of > holes in a standard. You can only blame when their product doesn't conform to > the standard. But at the moment, the standard (in some areas, by no means, > all) is not prescriptive enough. The challenge is to resolve the ambiguities without invalidating a lot of existing code. > I would also develop an appendix showing examples of every word in core, > showing the outputs for given inputs, including corner cases. This is the > essence of a standard (in my opinion): demonstration of compliance. If > the standard itself includes test cases then you can be quite confident > early on that your system is compliant; bugs in the implementation (or > in the standard ;-) notwithstanding. Almost no standards that I have seen > do this though, so the Forth TC is free of blame here, too. The Hays suite, though published separately, was an attempt at this. > We should try and get away from blaming or criticising the TC for the > short-comings, and try to come together, collaboratively, with a spirit > of cooperation. This happens all over the world in the standards "world" > with companies that are fierce competitors coming together to improve > standards, which in turn helps them to focus product development. In > involved with some of this in the water industry right now, and the > members of the DNP3 WITS organisations are ALL competitors, yet they > get on very well and progress is good, and sprits high. > > Why can't we do that in the Forth community? We did. The ANS Forth TC included most active Forth implementers (commercial and free), a number of users including some major ones with extensive applications, and representatives of FIG and IEEE. All those collaborative groups have internal disagreements which they resolve by compromising in various ways, as did the Forth TC. And the non-involved users are sometimes are unhappy with the compromises the group settled on: during the time we were working, both Fortran and COBOL published standards that resulted in multi-million dollar lawsuits and much unrest. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-28 11:30 +1000 |
| Message-ID | <obcavc$166k$1@gioia.aioe.org> |
| In reply to | #55997 |
Mark Wills wrote: > ... > Why can't we do that in the Forth community? Because Forth users have always had the option of disregarding what they see as wrong, and they exercise it. No lawsuits, no fuss and winning is guaranteed. Unlike Standards where ideas and people inevitably clash.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-03-21 16:42 -0400 |
| Message-ID | <20170321164208.70844c64@_> |
| In reply to | #55988 |
On Mon, 20 Mar 2017 19:12:07 -0700 (PDT) hughaguilar96@gmail.com wrote: > With my Straight Forth design, I am getting rid of a lot of cruft. I > don't have DO loops anymore, for example. So, small is beautiful! LOL. Do you really expect to execute existing Forth code without a DO loop? Let's see. Which Forth's have DO loop? ANS 94: Yes. Forth 83: Yes. Forth 79: Yes. fig-Forth: Yes. Forth 70: Yes. Do you intend to recode every Forth app that Straight Forth executes? 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-21 22:56 -0700 |
| Message-ID | <78b86419-1284-411d-92a7-d04f76d45183@googlegroups.com> |
| In reply to | #55968 |
On Monday, March 20, 2017 at 9:58:20 AM UTC-7, Helmar Wodtke wrote: > Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". I don't understand why you care about minimizing the number of core words. What difference does it make? This was done in eForth, but I didn't understand the point then either. I remember at the start of the MiniForth project that there was some thought of building a processor with 32 primitives in hardware (similar to the B16 that Bernd Paysan later developed). So, I gave some thought to what those 32 primitives would be. For example, with >R R@ R> you don't need DUP, but DUP is so commonly used that it seemed like it should be a primitive. This was all foolishness though. We dropped that idea and went with a processor that had a machine-language that primitives could be written in. Eventually I had hundreds of primitives, a lot written by hand and even more meta-compiled. On the x86, the code cache is 32KB --- so, it is a good idea to have few enough primitives that they all fit in 32KB --- if you have too many you end up with cache thrashing, so you program will be slower despite the fact that you have more machine-code. 32KB is quite a lot though --- all the words that seem like they should primitives can be primitives --- you just want to avoid getting carried away with writing words in assembly-language that are rarely used and/or not speed-critical.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-22 04:04 -0700 |
| Message-ID | <aa6a71ab-60b5-4502-85a4-79d5463613f9@googlegroups.com> |
| In reply to | #56076 |
Am Mittwoch, 22. März 2017 06:56:17 UTC+1 schrieb hughag...@gmail.com: > On Monday, March 20, 2017 at 9:58:20 AM UTC-7, Helmar Wodtke wrote: > > Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". > > I don't understand why you care about minimizing the number of core words. What difference does it make? This was done in eForth, but I didn't understand the point then either. > > I remember at the start of the MiniForth project that there was some thought of building a processor with 32 primitives in hardware (similar to the B16 that Bernd Paysan later developed). So, I gave some thought to what those 32 primitives would be. For example, with >R R@ R> you don't need DUP, but DUP is so commonly used that it seemed like it should be a primitive. This was all foolishness though. We dropped that idea and went with a processor that had a machine-language that primitives could be written in. Eventually I had hundreds of primitives, a lot written by hand and even more meta-compiled. > > On the x86, the code cache is 32KB --- so, it is a good idea to have few enough primitives that they all fit in 32KB --- if you have too many you end up with cache thrashing, so you program will be slower despite the fact that you have more machine-code. > > 32KB is quite a lot though --- all the words that seem like they should primitives can be primitives --- you just want to avoid getting carried away with writing words in assembly-language that are rarely used and/or not speed-critical. The process of trying to minimize the needed words is some process of thinking how things work. I personally do have some idea to extremely minimize words that are useful to implement a system. I think in "build patterns" - like ": 2DUP OVER OVER ;" If I implement a system that optimizes last compilation result, it would recognize "OVER OVER". And it would have to recognize it. ROLL and PICK are words for example, that are by first looking at it, relatively slow. But they are build patterns. If you use only DUP OVER SWAP >R R> etc. there is a much more complicated idea behind of for example PICK - automated recognition is not possible for this without extreme efforts. It's for sure useful not to say DUP has to be inside CORE-EXT because it can be implemented by PICK. But the 2xxx-words could be in CORE-EXT. The idea it helps with string handling - well, even Forth has counted strings. I personally prefer to have string pools that return an identifying number. It depends a little bit on input you have, but it can make processing much faster. The used memory is today no real problem. And where it is a problem, it would not be a problem to implement something from CORE-EXT. Inside CORE I understand it from a 1980 point of view. Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-03-23 00:57 -0400 |
| Message-ID | <20170323005733.4b30baca@_> |
| In reply to | #56089 |
On Wed, 22 Mar 2017 04:04:32 -0700 (PDT) Helmar Wodtke <helmwo@gmail.com> wrote: > Am Mittwoch, 22. März 2017 06:56:17 UTC+1 schrieb hughag...@gmail.com: > The process of trying to minimize the needed words is some process of > thinking how things work. Thinking? Is it required? What if I use a Forth optimizer? ... It uses a brute-force algorithm to find the shortest sequence, first. > I personally do have some idea to extremely minimize words that are > useful to implement a system. Do you want as small as is reasonable, but no further? Or, do you want as absolutely as small as is possible? E.g., reasonable would be using AND OR XOR since microprocessors implement that functionality. Whereas, absolute minimalism would use NAND and NOR to create AND OR and XOR . > I think in "build patterns" - like ": 2DUP OVER OVER ;" If I > implement a system that optimizes last compilation result, it would > recognize "OVER OVER". And it would have to recognize it. ROLL and > PICK are words for example, that are by first looking at it, > relatively slow. But they are build patterns. If you use only DUP > OVER SWAP >R R> etc. there is a much more complicated idea behind of > for example PICK - automated recognition is not possible for this > without extreme efforts. If programmers use DUP DROP SWAP OVER >R R> frequently but almost never use PICK and ROLL then should you spend time optimizing PICK and ROLL ? ... (dynamic instruction frequency) There are all sorts of posts on comp.lang.forth on minimal Forth wordsets: https://groups.google.com/d/msg/comp.lang.forth/ESZD4h1prcw/jFXN7dvtCFMJ Message-ID: <1332@massormetrix.ida.liu.se> https://groups.google.com/d/msg/comp.lang.forth/QXNYicMS26U/gZTvERGgzSIJ Message-ID: <3883@cosmo2.UUCP> https://groups.google.com/d/msg/comp.lang.forth/KHw28PKZXUk/JrXcjrYshxAJ Message-ID: <g4gqv4$qk9$1@aioe.org> 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-03-24 02:32 -0700 |
| Message-ID | <b2e57f69-68ec-427d-aa1d-a991a5537f32@googlegroups.com> |
| In reply to | #55968 |
> Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". Reading all discussion, I see the same ideas as has been posted here several times. Maybe I don't agree with all proposals, but I'm agree with whole idea 'make Forth simplier' (smaller, most understandable, whatever else). I think, the very source of these voices is the fact Forth is not a pure programming language, but methodology. It is impossible to cover all possible applications and write a standard for all. This is why many programmers, having a skill to write their own Forth implementation, are asking 'why do we need to study someone's scratches, when we can understand the basic idea and redesign all by own will?'. As usual, there is no black/white world. An important thing is to align efforts with objective trends. For large community of beginners, pretty-looking and standard Forth is useful. For skilled programmers, less fences makes Forth more attractive. A question to standard defenders - who are your auditory, you want to cooperate with?
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-24 10:00 +0000 |
| Message-ID | <ob2qhv$it1$1@dont-email.me> |
| In reply to | #56219 |
On 3/24/2017 09:32, Ilya Tarasov wrote: > A question to standard defenders - who are your auditory, you want to cooperate with? People & companies (on behalf of their end users) seek standards. Those people come together, co-operatively and agreeing to abide by a set of mutually acceptable rules, to make standards if they don't exist, and to promote their benefits once they do. The audience is those that have a need. No-one is forced to adopt them, support them, promote them or contribute to them. Critics of standards, in my experience, don't wanting to put in the needed work. Some do; but they are rare, and very often late to the work. More problematic is an unwillingness to compromise. But they are not the audience, since their needs will never be met except by themselves or those they dictate to. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-03-24 06:46 -0700 |
| Message-ID | <30c31c0b-2973-4ddf-9f02-4b0807c76c11@googlegroups.com> |
| In reply to | #56220 |
пятница, 24 марта 2017 г., 13:00:16 UTC+3 пользователь Alex написал: > On 3/24/2017 09:32, Ilya Tarasov wrote: > > A question to standard defenders - who are your auditory, you want to cooperate with? > > People & companies (on behalf of their end users) seek standards. Those > people come together, co-operatively and agreeing to abide by a set of > mutually acceptable rules, to make standards if they don't exist, and to > promote their benefits once they do. > > The audience is those that have a need. No-one is forced to adopt them, > support them, promote them or contribute to them. > > Critics of standards, in my experience, don't wanting to put in the > needed work. Some do; but they are rare, and very often late to the work. > > More problematic is an unwillingness to compromise. But they are not the > audience, since their needs will never be met except by themselves or > those they dictate to. If you think I don't work with standards at all, it is not true. Also I don't need a 'perfect' Forth standard to continue to work with Forth. I'm trying to explain an objective situation, running at close loop for a long enough time. When you are talking about many vendors and users, it's correct in general. 'Writing a new standard' works fine when you need to organize many vendors properly to boost their activity and make many implementations compatible. What to do in a kind of crysis, when programmers becomes unhappy, and users shows little interest to Forth? The real situation shows there are some programmers who want to review the entire approach and make their Forth-based compiler more adequate to current demands. I know several more programmers who know Forth, can write their own, but feels no interest to any kind of critics, promoting, contributing etc. They just use Forth, their own or downloaded. I want to note you are losing a large group of professionals (including, of course, 99.9% of those who unknown for me), and concentrating on beginners who still can't write Forth from the scratch and forced to use existing ones. They are depending on ANS, but when they get more skill, how can you expect to force them to stay? If you don't plan to force them, make ANS a tutorial, not a final product.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-24 14:41 +0000 |
| Message-ID | <ob3b1g$c1s$1@dont-email.me> |
| In reply to | #56224 |
On 3/24/2017 13:46, Ilya Tarasov wrote: > пятница, 24 марта 2017 г., 13:00:16 UTC+3 пользователь Alex написал: >> On 3/24/2017 09:32, Ilya Tarasov wrote: >>> A question to standard defenders - who are your auditory, you >>> want to cooperate with? >> >> People & companies (on behalf of their end users) seek standards. >> Those people come together, co-operatively and agreeing to abide by >> a set of mutually acceptable rules, to make standards if they don't >> exist, and to promote their benefits once they do. >> >> The audience is those that have a need. No-one is forced to adopt >> them, support them, promote them or contribute to them. >> >> Critics of standards, in my experience, don't wanting to put in the >> needed work. Some do; but they are rare, and very often late to the >> work. >> >> More problematic is an unwillingness to compromise. But they are >> not the audience, since their needs will never be met except by >> themselves or those they dictate to. > > If you think I don't work with standards at all, it is not true. I assumed no such thing. > Also I don't need a 'perfect' Forth standard to continue to work with > Forth. I'm trying to explain an objective situation, running at close > loop for a long enough time. When you are talking about many vendors > and users, it's correct in general. 'Writing a new standard' works > fine when you need to organize many vendors properly to boost their > activity and make many implementations compatible. What to do in a > kind of crysis, when programmers becomes unhappy, and users shows > little interest to Forth? The real situation shows there are some > programmers who want to review the entire approach and make their > Forth-based compiler more adequate to current demands. I know several > more programmers who know Forth, can write their own, but feels no > interest to any kind of critics, promoting, contributing etc. They > just use Forth, their own or downloaded. That's OK; & no-one is trying to stop them doing what they want, and that includes participating or not participating in the standard as they see fit. The market (consumers like you of Forth-as-a-language) decide whether it is useful or not, and what contributions they want to make. MPE, Forth Inc and a number of other Forth system providers think it is useful to continue to develop the standard, and I'm with them on that. > I want to note you are losing a large group of professionals > (including, of course, 99.9% of those who unknown for me), and > concentrating on beginners who still can't write Forth from the > scratch and forced to use existing ones. They are depending on ANS, > but when they get more skill, how can you expect to force them to > stay? What is frankly laughable is to suggest that anyone wants or can force anyone to stay with ANS Forth. Or that you have evidence that promotion of the standard is losing a large group of professionals, 99.9% of whom are unknown to you. > If you don't plan to force them, make ANS a tutorial, not a final > product. > There are tutorials and books provided by MPE and Forth Inc; perhaps you've seen them? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-03-25 15:32 -0700 |
| Message-ID | <5f7166de-1d39-444e-8eb3-a86e581c63b1@googlegroups.com> |
| In reply to | #56229 |
> That's OK; & no-one is trying to stop them doing what they want, and > that includes participating or not participating in the standard as they > see fit. The market (consumers like you of Forth-as-a-language) decide > whether it is useful or not, and what contributions they want to make. > MPE, Forth Inc and a number of other Forth system providers think it is > useful to continue to develop the standard, and I'm with them on that. This is a long-term position here. You are assuming Forth Inc is the only source of 'right' Forth and the only possibility to advance Forth is contributing and write proposals to ANS committee. This is not works for professional or small team. They can forget about any standard and redesign their compiler as they need. It is not a C#-class product, so you really can't prevent modifications. The question: is standard a part of solution or a part of problem? > What is frankly laughable is to suggest that anyone wants or can force > anyone to stay with ANS Forth. Or that you have evidence that promotion > of the standard is losing a large group of professionals, 99.9% of whom > are unknown to you. Several times I have seen a scenario when a skilled enough programmer spent his time to study 'right Forth', when he was slightly disappointed. Seeking for methodology, he got a list of words, with some empty sentences like 'this is non-mandatory'. Indeed, almost every time non-mandatory wordsets becomes irrevocably required :) Just find a threads where I'm asking about FILE IO words or floating point. In both cases I have a zero chance to do as Standard describe, because my customers will not understand me at all. > There are tutorials and books provided by MPE and Forth Inc; perhaps > you've seen them? Yes. Do you want to discuss it closely? A small note - since I'm an author of number of books/tutorials etc, this is not like I can only read and learn. If you want to make another iteration of 'all is done, why don't simple read, learn, implement, sell and contribute', I can just repeat this is don't works for now.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-25 23:10 +0000 |
| Message-ID | <ob6t6s$5id$1@dont-email.me> |
| In reply to | #56301 |
On 3/25/2017 22:32, Ilya Tarasov wrote: >> That's OK; & no-one is trying to stop them doing what they want, >> and that includes participating or not participating in the >> standard as they see fit. The market (consumers like you of >> Forth-as-a-language) decide whether it is useful or not, and what >> contributions they want to make. MPE, Forth Inc and a number of >> other Forth system providers think it is useful to continue to >> develop the standard, and I'm with them on that. > > This is a long-term position here. You are assuming Forth Inc is the > only source of 'right' Forth and the only possibility to advance > Forth is contributing and write proposals to ANS committee. What? Where did I say that? > This is not works for professional or small team. They can forget > about any standard and redesign their compiler as they need. It is > not a C#-class product, so you really can't prevent modifications. You speak in riddles, and frankly I'm having a hard time understanding much of this. What has C# and preventing modifications got to do with it? You're coming across like some Delphic oracle. > The question: is standard a part of solution or a part of problem? Who knows, since you've not described either the solution or the problem. >> What is frankly laughable is to suggest that anyone wants or can >> force anyone to stay with ANS Forth. Or that you have evidence >> that promotion of the standard is losing a large group of >> professionals, 99.9% of whom are unknown to you. > > Several times I have seen a scenario when a skilled enough > programmer spent his time to study 'right Forth', when he was > slightly disappointed. Seeking for methodology, he got a list of > words, with some empty sentences like 'this is non-mandatory'. > Indeed, almost every time non-mandatory wordsets becomes irrevocably > required :) If you know programmers that obsess over "right Forth", or non-mandatory wordsets becoming irrevocably required, they must have been pretty inflexible pedants. Or perhaps they had lousy teachers. Either way, I don't pay much attention to people who (a) employ anecdotes as evidence and (b) claim to speak for others. > Just find a threads where I'm asking about FILE IO words > or floating point. In both cases I have a zero chance to do as > Standard describe, because my customers will not understand me at > all. I won't be searching for your moans and groans about the lumps in your porridge. The internet is full of people complaining about something. You need to be specific in this thread. > >> There are tutorials and books provided by MPE and Forth Inc; >> perhaps you've seen them? > > Yes. Do you want to discuss it closely? A small note - since I'm an > author of number of books/tutorials etc, this is not like I can only > read and learn. If you want to make another iteration of 'all is > done, why don't simple read, learn, implement, sell and contribute', > I can just repeat this is don't works for now. > I get that you're not happy & like to think of yourself as a bit of a guru, but beyond that, what's your point? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-03-25 17:29 -0700 |
| Message-ID | <9eb7f6df-c5fe-4152-8460-4600b3d4747b@googlegroups.com> |
| In reply to | #56304 |
воскресенье, 26 марта 2017 г., 2:10:06 UTC+3 пользователь Alex написал: > On 3/25/2017 22:32, Ilya Tarasov wrote: > >> That's OK; & no-one is trying to stop them doing what they want, > >> and that includes participating or not participating in the > >> standard as they see fit. The market (consumers like you of > >> Forth-as-a-language) decide whether it is useful or not, and what > >> contributions they want to make. MPE, Forth Inc and a number of > >> other Forth system providers think it is useful to continue to > >> develop the standard, and I'm with them on that. > > > > This is a long-term position here. You are assuming Forth Inc is the > > only source of 'right' Forth and the only possibility to advance > > Forth is contributing and write proposals to ANS committee. > > What? Where did I say that? Just one post above. You point looks clear enough - 'there are MPE and Forth Inc, they are big and smart and they are supporting standard. You may contribute or get out'. You are hoping everybody will choose to contribute, but there is an important detail. Forth is very easy to write, so, starting from some point, one may say 'I choose to get out, but not too far away'. This is why we can see here many threads with similar ideas - one claim he can write Forth and want to use it, but asking for more simplicity. This is predictable, because being free from standard requires two things - to be professional and to have smaller todo list. > > This is not works for professional or small team. They can forget > > about any standard and redesign their compiler as they need. It is > > not a C#-class product, so you really can't prevent modifications. > > You speak in riddles, and frankly I'm having a hard time understanding > much of this. What has C# and preventing modifications got to do with > it? You're coming across like some Delphic oracle. Explanation is very easy. If you want to rewrite C#, Microsoft can say 'use C# as is or get out'. Can you write your own C# compiler? For most programmers answer is 'no'. But if you attempt to behave the same manner with Forth, the answer will be 'yes, we can rewrite, so YOU may sitting still with your toys, and we will go to advance with our vision'. > > The question: is standard a part of solution or a part of problem? > > Who knows, since you've not described either the solution or the problem. I repeat this several times :) I know this USA-specific trick to looks smart in any case. If you ignore еру problem, this don't mean you are not impacted. I don't want to ask how smart you feel yourself - just show me objective facts. Trends, Y-t-Y income, number of customers, number of publications etc. If you repeating your arguments, but your business goes low, I will not believe a single word. > If you know programmers that obsess over "right Forth", or non-mandatory > wordsets becoming irrevocably required, they must have been pretty > inflexible pedants. Or perhaps they had lousy teachers. No, usually they try to start their own version, but faces the critics like 'why your solution is non-standard?', followed by hypocrisy like 'of course, nobody can force you, but Forth Inc is so smart, and you are just can't work in team and contribute'. > > Just find a threads where I'm asking about FILE IO words > > or floating point. In both cases I have a zero chance to do as > > Standard describe, because my customers will not understand me at > > all. > > I won't be searching for your moans and groans about the lumps in your > porridge. The internet is full of people complaining about something. > You need to be specific in this thread. So you are ignoring the facts. I'm clearly describe my point - I have a vision how some application-level words may be implemented, but I've met a tons of flood, based on 'ANS already describe it, so just use and don't dare to say a word against'. This is not my problem indeed, because 1. I don't need a single line of code from Forth Inc 2. I'm not alone > I get that you're not happy & like to think of yourself as a bit of a > guru, but beyond that, what's your point? It is your big mistake :) You are thinking there are a place for gurus, but this is completely wrong. No gurus in serious activity, just teams and cross approvement. Freedom is not replacing one lord to another, so attempts to rule is archaic. While Forth Inc is sitting in the far corner, other programmers may think and work. If you think YOU are a guru and can write a complete tutorial for everyone, this is really laughable. Help others as they really need (not as you imagine) or step aside.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-25 18:08 -0700 |
| Message-ID | <87poh4vo7y.fsf@nightsong.com> |
| In reply to | #56305 |
Ilya Tarasov <ilya74.tarasov@gmail.com> writes: > Explanation is very easy. If you want to rewrite C#, Microsoft can say > use C# as is or get out'. Can you write your own C# compiler? For most > programmers answer is 'no'. https://github.com/mono/website/blob/gh-pages/docs/about-mono/languages/csharp.md
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-26 08:30 +0100 |
| Message-ID | <ob7qh9$uql$1@dont-email.me> |
| In reply to | #56306 |
On 3/26/2017 02:08, Paul Rubin wrote: > Ilya Tarasov <ilya74.tarasov@gmail.com> writes: >> Explanation is very easy. If you want to rewrite C#, Microsoft can say >> use C# as is or get out'. Can you write your own C# compiler? For most >> programmers answer is 'no'. > > https://github.com/mono/website/blob/gh-pages/docs/about-mono/languages/csharp.md > http://www.dotgnu.org/ https://github.com/dotnet/roslyn/wiki -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-26 08:50 +0100 |
| Message-ID | <ob7rmv$1pv$1@dont-email.me> |
| In reply to | #56305 |
On 3/26/2017 00:29, Ilya Tarasov wrote: > воскресенье, 26 марта 2017 г., 2:10:06 UTC+3 пользователь Alex > написал: >> On 3/25/2017 22:32, Ilya Tarasov wrote: >>>> That's OK; & no-one is trying to stop them doing what they >>>> want, and that includes participating or not participating in >>>> the standard as they see fit. The market (consumers like you of >>>> Forth-as-a-language) decide whether it is useful or not, and >>>> what contributions they want to make. MPE, Forth Inc and a >>>> number of other Forth system providers think it is useful to >>>> continue to develop the standard, and I'm with them on that. >>> >>> This is a long-term position here. You are assuming Forth Inc is >>> the only source of 'right' Forth and the only possibility to >>> advance Forth is contributing and write proposals to ANS >>> committee. >> >> What? Where did I say that? > > Just one post above. You point looks clear enough - 'there are MPE > and Forth Inc, they are big and smart and they are supporting > standard. You may contribute or get out'. So, having incorrectly accused me of saying it, now you pretend I said it by putting it in quotes. Not cool. [snipped] > > Explanation is very easy. If you want to rewrite C#, Microsoft can > say 'use C# as is or get out'. Can you write your own C# compiler? > For most programmers answer is 'no'. But if you attempt to behave > the same manner with Forth, the answer will be 'yes, we can rewrite, > so YOU may sitting still with your toys, and we will go to advance > with our vision'. I know of at least 3 C# compilers. Mono, dotgnu and roslyn. > >>> The question: is standard a part of solution or a part of >>> problem? >> >> Who knows, since you've not described either the solution or the >> problem. > > I repeat this several times :) I know this USA-specific trick to > looks smart in any case. I am not an American, and this kind of pointless snottery adds nothing to your argument. [snipped] > >> I get that you're not happy & like to think of yourself as a bit >> of a guru, but beyond that, what's your point? > > It is your big mistake :) You are thinking there are a place for > gurus, but this is completely wrong. No gurus in serious activity, > just teams and cross approvement. Standards (cough). Teams love 'em. > Freedom is not replacing one lord to another, so attempts to rule is > archaic. While Forth Inc is sitting in the far corner, other > programmers may think and work. If you think YOU are a guru and can > write a complete tutorial for everyone, this is really laughable. > Help others as they really need (not as you imagine) or step aside. > Step aside? I'm in your way? Wow, I must be more influential than I thought. -- Alex
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web