Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54064 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-01-17 12:17 +1100 |
| Last post | 2017-03-26 01:52 -0700 |
| Articles | 20 on this page of 269 — 27 participants |
Back to article view | Back to comp.lang.forth
EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-17 12:17 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 18:27 -0800
Re: EXIT THEN Pablo Hugo Reda <pabloreda@gmail.com> - 2017-01-16 18:28 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 20:56 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:05 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 23:29 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 11:46 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-19 22:28 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-22 18:45 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-25 09:57 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-25 23:56 -0800
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 03:35 -0600
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-26 11:31 +0100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 11:07 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-05 19:15 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:54 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-02-07 21:14 +0000
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:52 +0000
Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-15 23:49 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-16 14:41 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-16 16:59 +0000
Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-11 15:05 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Matthias Trute <matthias.trute@gmail.com> - 2017-03-13 12:37 -0700
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-13 21:32 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-14 04:42 -0500
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-14 11:45 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-14 12:41 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-14 14:20 +0100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-07 16:15 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:49 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-08 19:43 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:31 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-14 11:12 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-15 17:22 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-17 10:16 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 09:11 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-28 11:07 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-27 18:31 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-29 12:07 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-28 17:37 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-28 21:40 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-29 19:56 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-30 00:30 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:22 -0600
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-31 14:42 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-31 19:16 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-31 21:00 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-01 17:35 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-02 01:31 -0500
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-02 20:09 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-02 18:03 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-02 22:04 -0500
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-02-01 03:15 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-01 17:32 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-30 13:30 +0000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-30 05:56 -0800
Re: EXIT THEN Howerd <howerdo@yahoo.co.uk> - 2017-01-30 12:13 -0800
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-30 22:25 +0000
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-26 10:48 +0000
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 08:41 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-27 21:36 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 17:06 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-16 16:31 -1000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 20:59 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-17 06:11 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-18 10:36 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-20 07:33 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 23:02 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-20 13:47 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-20 18:55 -0800
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-22 09:15 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-22 14:30 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-22 20:58 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 10:47 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:20 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 13:09 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 14:41 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 20:52 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 16:21 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-24 06:55 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 03:56 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-24 09:46 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-22 22:38 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 15:09 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 10:16 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 05:53 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 12:14 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 14:53 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-24 21:37 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 19:54 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-25 03:38 -0600
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-17 08:01 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-17 10:27 -0800
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-17 11:34 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-18 14:35 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-18 10:37 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-17 20:53 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-17 18:02 -1000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 00:15 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-17 19:34 -1000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 03:33 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-18 03:45 -0600
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 14:43 -0500
Re: EXIT THEN albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-18 13:17 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:46 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-18 13:56 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:04 +1100
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-18 18:10 -1000
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 03:51 -0600
Re: EXIT THEN hheinrich.hohl@gmail.com - 2017-01-19 02:28 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 22:23 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-20 13:32 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-20 18:18 -1000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 12:00 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-22 21:10 -0500
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-23 01:22 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:03 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-24 02:27 +0100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 04:00 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-24 07:49 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 20:04 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-24 20:23 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 21:32 -0500
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-24 23:04 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-25 00:45 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-25 07:16 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-25 02:57 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-25 16:55 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-25 09:53 -1000
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-26 22:40 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-26 10:55 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 10:17 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-27 13:09 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-26 21:54 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-27 14:12 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-28 12:32 +1100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-29 10:35 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-22 21:35 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-23 04:15 -0600
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-23 10:29 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 21:48 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:18 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-26 11:34 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-25 22:04 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-25 17:22 -1000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-26 00:55 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-27 13:40 +1100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 11:44 +1100
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-18 08:02 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-18 17:45 +0100
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:02 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-01-22 18:23 -0800
Re: EXIT THEN albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-02 12:24 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-10 12:15 +1100
Re: EXIT THEN mhx@iae.nl - 2017-02-10 10:57 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-11 12:45 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-10 18:13 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-11 07:55 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-02-11 13:16 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-02-11 11:28 -1000
Re: EXIT THEN Paul Rubin <no.email@nospam.invalid> - 2017-02-11 13:40 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-11 18:52 -0800
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-02-12 12:09 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 07:24 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-12 16:42 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-02-12 13:52 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-13 00:02 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-02-12 21:27 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 07:53 +0000
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 16:25 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:11 -0800
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 18:49 -0800
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 18:59 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 21:18 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-12 14:39 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-11 18:47 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-12 00:49 -0500
Re: EXIT THEN Paul Rubin <no.email@nospam.invalid> - 2017-02-11 23:07 -0800
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-02-12 12:36 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-13 11:08 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:04 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:08 -0800
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-16 17:24 -0800
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-17 16:32 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 10:47 +1100
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-18 16:07 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 13:54 +1100
Re: EXIT THEN Heinrich Hohl <hheinrich.hohl@gmail.com> - 2017-02-17 02:40 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-17 19:25 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 12:36 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 06:32 -0700
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-03-21 08:33 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 02:21 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 09:57 -0700
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-03-21 18:17 +0100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:22 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 17:56 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 11:59 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:16 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:24 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:26 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:32 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:51 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:56 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 21:02 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:15 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 21:36 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 15:12 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 16:13 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 09:16 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 03:35 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 13:33 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 17:51 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 18:59 +0000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-03-21 12:07 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:17 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 20:08 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 09:18 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 22:25 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 04:46 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 12:23 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:27 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:36 -0700
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 13:14 +0000
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-03-22 13:43 +0100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:04 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 11:49 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:24 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:00 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:12 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 07:00 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 07:14 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 10:43 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 11:09 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 18:22 +0000
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-03-22 11:42 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 15:45 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 15:57 -0700
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-03-22 16:17 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 12:03 -0700
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 14:27 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 14:31 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-23 14:41 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 14:57 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:11 -0700
Re: EXIT THEN Ron Aaron <rambamist@gmail.com> - 2017-03-26 11:40 +0300
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:57 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-26 09:50 +0100
Re: EXIT THEN foxaudioresearch@gmail.com - 2017-03-22 09:14 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 00:48 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:59 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 09:52 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 16:13 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-23 14:39 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-23 16:33 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-24 14:17 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-24 11:49 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-23 18:12 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-24 08:55 +0000
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 09:14 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-25 13:00 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-24 20:25 -0700
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-03-25 02:10 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-25 12:08 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:59 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 09:53 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-25 07:52 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-26 16:31 +1000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:52 -0700
Page 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-22 14:27 -0500 |
| Message-ID | <Memdnb76Q7-qTU_FnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #56125 |
Helmar Wodtke <helmwo@gmail.com> wrote: > > Hope you do not hate me for my comment, I don't, but I do hate the way you do not trim excess quoted material from your posts. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-22 14:31 -0700 |
| Message-ID | <d211117f-cc02-4983-94f3-cac98037e231@googlegroups.com> |
| In reply to | #56125 |
On Wednesday, March 22, 2017 at 11:09:54 AM UTC-7, Helmar Wodtke wrote: > Am Mittwoch, 22. März 2017 18:43:59 UTC+1 schrieb hughag...@gmail.com: > You are too fast with blaming people to be liars. I think Elisabeth does not like me too - most people that implement a Forth and do have ideas do have this feeling. She is a bit more active in communication than say Charles H. Moore (while I'd say he is also active in communication). She doesn't like anybody who writes a Forth system, even if it is ANS-Forth --- she wants Forth Inc. to be the only standard Forth system --- she is tolerant of MPE with their VFX because Forth Inc. and MPE do joint projects together in which they both make money. You say that Charles Moore is active in communication? He has never been on comp.lang.forth. Are you exchanging private emails with him? He seems to be very reclusive and non-communicative --- I have never communicated with him --- I suppose I could send him an email, but I am not a GA144 customer so it is unlikely that he would respond. > You can not say "liar" just because someone does not like (or even really knows) your system or does not believe that your way is the best and only one. Here is a quote from the Forth-200x mailing list: ---------------------------------------------------------------------------- Hugh has been hanging around c.l.f for several years, now. He originally got mad at FORTH, Inc. because we insisted on charging for an upgrade to SwiftForth 3.0 for people who had bought 2.x > a year earlier. He has had one programming job, paying $10/hr, on which he wrote a cross-compiler for a microcontroller for a project. He was fired at the end of the project, and has since been working as a taxicab driver. He is actively homophobic, and developed his hatred for me when I called him on a particularly vitriolic attack on a c.l.f poster who dared to mention his partner. Pretty much everyone on c.l.f has his number. Hope you are doing well. Ned and i are enjoying life in Hawaii, and hope you are, too! Aloha, Elizabeth ---------------------------------------------------------------------------- As for Alex McDonald, pretty much everything he says is a lie. An egregious example is listing me as a contributor on the Paysan-faked quotation RfD --- I have consistently argued against the Paysan-faked quotations, and this was a big part of why I left the Forth-200x mailing-list. > Beside, I know MFX for some reasons. Quite a nice thing. Fast and good. I think it was even faster than my very simple HelFORTH-JIT. But not so much faster ;) My JIT worked by unrolling definitions, your MFX was more a really optimizing compiler. But as I did some tests, MFX was also a bit complicated as I remember. Some tricks I could do with HelFORTH where not possible - but at this time I came from RetroForth, not from ANS, so I do not complain about it. You have used MFX??? That seems unlikely. MFX is only good for compiling to the MiniForth processor (now called RACE), and that processor is proprietary to Testra, so you can't use MFX unless you are either an employee or a customer of Testra. Also, MFX wasn't an optimizing compiler --- I didn't know how to do code optimization then --- I just wrote a lot of primitives (either hand-written or meta-compiled); all speed problems were resolved by resorting to assembly-language. The assembler/simulator was where most of the complexity of MFX was. The Forth compiler was pretty straight-forward. My "ghost functions" were a cool feature. I also did a lot of meta-compiling in regard to the words related to local variables (this was not used in the motion-control program though). There were some nice features in the Forth cross-compiler, but it wasn't an optimizing compiler; it was a product of the 1990s.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-23 14:41 +0000 |
| Message-ID | <ob0mkl$9ja$2@dont-email.me> |
| In reply to | #56142 |
On 3/22/2017 21:31, hughaguilar96@gmail.com wrote: > As for Alex McDonald, pretty much everything he says is a lie. An > egregious example is listing me as a contributor on the Paysan-faked > quotation RfD --- I have consistently argued against the Paysan-faked > quotations, and this was a big part of why I left the Forth-200x > mailing-list. You didn't leave. You got banned from the mailing list for being offensive. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-22 14:57 +0000 |
| Message-ID | <oau36j$3ok$1@dont-email.me> |
| In reply to | #56109 |
On 3/22/2017 14:00, hughaguilar96@gmail.com wrote: [Mucho madness snipped] > The ANS-Forth CASE doesn't support jump-table implementation for the > following reasons: 1.) The value given to OF isn't required to be a > constant. It could come from a function that is calculated at > run-time. 2.) There can be duplicates of the values given to > different OF statements. You are yet again dictating the implementation, although you have pointed out a (non-exhaustive) number of reasons why a specific CASE/ENDCASE constructs may not be implementable as a jump table. Some can; some can't. The ANS standard is silent on the matter. BTW, one feature of language & thinking that standards writers try to avoid is the negative statement. They are really hard to get right, because describing what something doesn't or can't do assumes you know the entire possible universe of what is possible or can be done. Implementers and users are clever buggers, and negative exhortations make for much standards work filling the holes we didn't anticipate but they fell through. > > I have said many many times that a standard should standardize > behavior rather than implementation. This is a fundamental aspect of > Straight Forth. But you keep breaking your own rules. "In Straight Forth, I will require code and data to be separate". I can't think of another language that requires this, or a language standard that even bothers to mention it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-26 01:11 -0700 |
| Message-ID | <90ec80ad-2358-4ce7-8c0a-7b4093bc5de9@googlegroups.com> |
| In reply to | #56116 |
On Wednesday, March 22, 2017 at 7:57:07 AM UTC-7, Alex wrote: > On 3/22/2017 14:00, hughaguilar96@gmail.com wrote: > > I have said many many times that a standard should standardize > > behavior rather than implementation. This is a fundamental aspect of > > Straight Forth. > > But you keep breaking your own rules. "In Straight Forth, I will require > code and data to be separate". I can't think of another language that > requires this, or a language standard that even bothers to mention it. Requiring code and data to be separate is standardizing behavior not implementation. A Forth system that allows code and data to be intermixed necessarily disallows a lot of code that would work in a system where code and data are required to be separate. For example: create foo 1 , 2 , 3 , create bar 4 , 5 , 6 , In an programmer designed system, where code and data are required to be separate, FOO contains the data: 1 2 3 4 5 6 --- in a sales-clown designed system, where anything goes, FOO can only be counted on to contain room for three items. ANS-Forth is a standard that doesn't standardize anything. Simple questions remain unanswered. For example: "Which functions cause the HERE value to change? Do the : CREATE CONSTANT functions change the HERE value?" This should have been clearly documented. As it is, it will vary from one ANS-Forth compliant system to another --- yet another example of ambiguity in ANS-Forth.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-03-26 11:40 +0300 |
| Message-ID | <ob7uk9$8sb$1@dont-email.me> |
| In reply to | #56326 |
On 26/03/2017 11:11, hughaguilar96@gmail.com wrote: > For example: > > create foo 1 , 2 , 3 , > create bar 4 , 5 , 6 , > > In an programmer designed system, where code and data are required to be separate, FOO contains the data: 1 2 3 4 5 6 --- in a sales-clown designed system, where anything goes, FOO can only be counted on to contain room for three items. Not so. Alignment concerns may dictate that 'bar' is not contiguous with 'foo'.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-26 01:57 -0700 |
| Message-ID | <445d09ac-3e1f-46b9-8bc4-41bfa388c279@googlegroups.com> |
| In reply to | #56327 |
On Sunday, March 26, 2017 at 1:40:27 AM UTC-7, Ron Aaron wrote: > On 26/03/2017 11:11, hughaguilar96@gmail.com wrote: > > > For example: > > > > create foo 1 , 2 , 3 , > > create bar 4 , 5 , 6 , > > > > In an programmer designed system, where code and data are required to be separate, FOO contains the data: 1 2 3 4 5 6 --- in a sales-clown designed system, where anything goes, FOO can only be counted on to contain room for three items. > > Not so. Alignment concerns may dictate that 'bar' is not contiguous > with 'foo'. In Straight Forth I don't support C, --- it is impossible for the HERE value to ever be unaligned.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-26 09:50 +0100 |
| Message-ID | <ob7v7m$ap3$1@dont-email.me> |
| In reply to | #56326 |
On 3/26/2017 09:11, hughaguilar96@gmail.com wrote: > On Wednesday, March 22, 2017 at 7:57:07 AM UTC-7, Alex wrote: >> On 3/22/2017 14:00, hughaguilar96@gmail.com wrote: >>> I have said many many times that a standard should standardize >>> behavior rather than implementation. This is a fundamental aspect >>> of Straight Forth. >> >> But you keep breaking your own rules. "In Straight Forth, I will >> require code and data to be separate". I can't think of another >> language that requires this, or a language standard that even >> bothers to mention it. > > Requiring code and data to be separate is standardizing behavior not > implementation. > > A Forth system that allows code and data to be intermixed necessarily > disallows a lot of code that would work in a system where code and > data are required to be separate. > > For example: > > create foo 1 , 2 , 3 , create bar 4 , 5 , 6 , > > In an programmer designed system, where code and data are required to > be separate, FOO contains the data: 1 2 3 4 5 6 --- in a sales-clown > designed system, where anything goes, FOO can only be counted on to > contain room for three items. (Apart from the extremely bad programming practise this represents) There is no code (or at least, in my system it generates none) in those statements; they're all data. What you are now insisting on is implementation detail. 1. There are two data spaces, one for the dictionary and one for other data, and a separate code area. 2. The programmer has to understand (and the standard has to specify) what is built in what space. For example; 10 value x \ or variable 20 value y Does a two data space model make 10 and 20 contiguous? Is there any code generated by VALUE? All these are implementation issues. > > ANS-Forth is a standard that doesn't standardize anything. Simple > questions remain unanswered. For example: "Which functions cause the > HERE value to change? Do the : CREATE CONSTANT functions change the > HERE value?" This should have been clearly documented. As it is, it > will vary from one ANS-Forth compliant system to another --- yet > another example of ambiguity in ANS-Forth. > Why is that information needed by the programmer? Do you have any examples of why it is needed? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-03-22 09:14 -0700 |
| Message-ID | <b1ab00ca-db4e-413c-8d80-e68024aebf9d@googlegroups.com> |
| In reply to | #56109 |
But if everything Alex says is a lie then... what he saying is true... but if he is lying then it can't be true but if... Abort: stack overflow
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-23 00:48 +1100 |
| Message-ID | <oatv6v$1e9d$1@gioia.aioe.org> |
| In reply to | #56093 |
Alex wrote: > On 3/22/2017 11:25, HAA wrote: > > Alex wrote: > >> On 3/22/2017 09:08, HAA wrote: > >>> Helmar Wodtke wrote: > >>>> ... > >>>> I btw. also try to avoid ELSE. I use AND: and OR: if possible. By using ;THEN there > >>>> is the ELSE-part behind ;THEN. But I still have ELSE too and use it from time to > >>>> time... > >>>> > >>>> Regards, > >>>> -Helmar > >>> > >>> Agreed. There is a difference between having ELSE and misusing it. ANS-CASE is > >>> an example of misusing ELSE. > >>> > >> > >> ANS Forth doesn't tell you how to implement CASE. > > > > How many ways are there to implement a straight-jacket? > > You keep making Hugh's mistake with his Straitjacketforth; you think > standards tell you *how* to implement something, rather than describing > what they must do, so you assume ANS requires using ELSE, and you were > so sure you didn't bother checking. The fact is ANS *describes* a nested IF ELSE CASE. Whichever way you may choose to implement it, you cannot avoid the inefficiencies implicit in such a structure. ANS *requires* all ENDOFs to point to a common exit point. This will *require* using a jump or other mechanism to achieve. This is waste if all you needed was an immediate Exit. > > I leave the various implementations to your imagination (or lack of). As > does the standard. Don't leave it to me. You're the one with the imagination. You turn it into reality :)
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-22 13:59 +0000 |
| Message-ID | <oatvpl$n8m$1@dont-email.me> |
| In reply to | #56105 |
On 3/22/2017 13:48, HAA wrote: > Alex wrote: >> On 3/22/2017 11:25, HAA wrote: >>> Alex wrote: >>>> On 3/22/2017 09:08, HAA wrote: >>>>> Helmar Wodtke wrote: >>>>>> ... >>>>>> I btw. also try to avoid ELSE. I use AND: and OR: if possible. By using ;THEN there >>>>>> is the ELSE-part behind ;THEN. But I still have ELSE too and use it from time to >>>>>> time... >>>>>> >>>>>> Regards, >>>>>> -Helmar >>>>> >>>>> Agreed. There is a difference between having ELSE and misusing it. ANS-CASE is >>>>> an example of misusing ELSE. >>>>> >>>> >>>> ANS Forth doesn't tell you how to implement CASE. >>> >>> How many ways are there to implement a straight-jacket? >> >> You keep making Hugh's mistake with his Straitjacketforth; you think >> standards tell you *how* to implement something, rather than describing >> what they must do, so you assume ANS requires using ELSE, and you were >> so sure you didn't bother checking. > > The fact is ANS *describes* a nested IF ELSE CASE. Whichever way > you may choose to implement it, you cannot avoid the inefficiencies > implicit in such a structure. ANS *requires* all ENDOFs to point to a > common exit point. This will *require* using a jump or other mechanism > to achieve. This is waste if all you needed was an immediate Exit. No, it doesn't require the generation of a jump. Any code ending up jumping to a THEN ; can be replaced by an exit; it can (and is in my compiler) trivially optimized away by ; looking for memoized branch targets to immediately preceding THENs. > >> >> I leave the various implementations to your imagination (or lack of). As >> does the standard. > > Don't leave it to me. You're the one with the imagination. You turn it into > reality :) I am. I've been working for some time on an SSA based optimizer. It's not a trivial exercise, but it is achievable (and as an intellectual exercise, it is an immensely interesting challenge). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-23 09:52 +1100 |
| Message-ID | <oauv3l$1l1q$1@gioia.aioe.org> |
| In reply to | #56107 |
Alex wrote: > On 3/22/2017 13:48, HAA wrote: > > ... > > The fact is ANS *describes* a nested IF ELSE CASE. Whichever way > > you may choose to implement it, you cannot avoid the inefficiencies > > implicit in such a structure. ANS *requires* all ENDOFs to point to a > > common exit point. This will *require* using a jump or other mechanism > > to achieve. This is waste if all you needed was an immediate Exit. > > No, it doesn't require the generation of a jump. Any code ending up > jumping to a THEN ; can be replaced by an exit; it can (and is in my > compiler) trivially optimized away by ; looking for memoized branch > targets to immediately preceding THENs. I said "jump or other mechanism" to catch any joker who imagines replacing a jump with something equally unnecessary was an achievement. > >> > >> I leave the various implementations to your imagination (or lack of). As > >> does the standard. > > > > Don't leave it to me. You're the one with the imagination. You turn it into > > reality :) > > I am. I've been working for some time on an SSA based optimizer. It's > not a trivial exercise, but it is achievable (and as an intellectual > exercise, it is an immensely interesting challenge). So you're going to 'solve' the problem of the bad specification that is ANS CASE with a great big fancy optimizer. This is deserving of a Darwin Award.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-22 16:13 -0700 |
| Message-ID | <04b19a70-cc2f-4118-8cdc-2b6c8ae034ef@googlegroups.com> |
| In reply to | #56144 |
On Wednesday, March 22, 2017 at 3:50:34 PM UTC-7, HAA wrote: > Alex wrote: > > I've been working for some time on an SSA based optimizer. It's > > not a trivial exercise, but it is achievable (and as an intellectual > > exercise, it is an immensely interesting challenge). > > So you're going to 'solve' the problem of the bad specification that is ANS > CASE with a great big fancy optimizer. This is deserving of a Darwin Award. LOL That was hilarious! Good point, HAA --- Captain Obvious to the rescue! My <SWITCH doesn't require a big fancy optimizer to work efficiently --- it could have been written in Forth-83 in the 1980s --- too bad I didn't do so... Well, IIRC, Forth-83 didn't have anything like :NONAME in it, so that would have been problematic --- still though, my <SWITCH is pretty basic Forth programming that doesn't rely on any fancy tricks --- it is the kind of code that got written in the 1980s pretty routinely by average Forth programmers. I could have written :NONAME in UR/Forth easily --- back in those days, nobody really cared if you knew Forth-83, because Forth-83 was pretty basic --- people cared if you knew UR/Forth (when I interviewed at Testra, all of the questions involved carnal knowledge of UR/Forth).
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-23 14:39 +0000 |
| Message-ID | <ob0mh7$9ja$1@dont-email.me> |
| In reply to | #56144 |
On 3/22/2017 22:52, HAA wrote: > Alex wrote: >> On 3/22/2017 13:48, HAA wrote: >>> ... > >>>> >>>> I leave the various implementations to your imagination (or lack of). As >>>> does the standard. >>> >>> Don't leave it to me. You're the one with the imagination. You turn it into >>> reality :) >> >> I am. I've been working for some time on an SSA based optimizer. It's >> not a trivial exercise, but it is achievable (and as an intellectual >> exercise, it is an immensely interesting challenge). > > So you're going to 'solve' the problem of the bad specification that is ANS > CASE with a great big fancy optimizer. This is deserving of a Darwin Award. > No, of course that's not my goal. CASE is just one example of where high level constructs (and it's pretty true of any language) and in Forth, low level constructs too, don't map effectively onto the computer architectures we have. Forth is a two stack zero address operand language, but most processors are multiple operand register based and many don't have built in stacks, far less two. Constructs like (qv OF) OVER = IF DROP are inefficient on a register based machine when naively compiled, so code rewriting (which is what optimizing compilers do) is something that can pay enormous dividends. There are lots of techniques for building & processing code, and one of them, SSA, uses graphs which are reorganized to make the code generated far more efficient than a simple compile of each token. This is something other compiler writers and compilers have been doing for decades, yet we're still largely stuck on simpler optimisations like peephole or superinstructions. (Although some compilers, like VFX, do a pretty good job of generating code that's far better than naive compilers, I'm not aware that MPE's code generators use graph representations or optimizations.) There's nothing wrong with the specification of CASE/ENDCASE. It's just tough (but not impossible) to generate decent code with the simple code generation tools we currently have. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-23 16:33 -0700 |
| Message-ID | <6f5c9c24-f213-4528-be11-1ae0be406931@googlegroups.com> |
| In reply to | #56182 |
On Thursday, March 23, 2017 at 7:39:20 AM UTC-7, Alex wrote: > On 3/22/2017 22:52, HAA wrote: > > Alex wrote: > >> I've been working for some time on an SSA based optimizer. It's > >> not a trivial exercise, but it is achievable (and as an intellectual > >> exercise, it is an immensely interesting challenge). > > > > So you're going to 'solve' the problem of the bad specification that is ANS > > CASE with a great big fancy optimizer. This is deserving of a Darwin Award. > > > > No, of course that's not my goal. > > CASE is just one example of where high level constructs (and it's pretty > true of any language) and in Forth, low level constructs too, don't map > effectively onto the computer architectures we have. Forth is a two > stack zero address operand language, but most processors are multiple > operand register based and many don't have built in stacks, far less two. > > Constructs like (qv OF) OVER = IF DROP are inefficient on a register > based machine when naively compiled, so code rewriting (which is what > optimizing compilers do) is something that can pay enormous dividends. > There are lots of techniques for building & processing code, and one of > them, SSA, uses graphs which are reorganized to make the code generated > far more efficient than a simple compile of each token. > > This is something other compiler writers and compilers have been doing > for decades, yet we're still largely stuck on simpler optimisations like > peephole or superinstructions. (Although some compilers, like VFX, do a > pretty good job of generating code that's far better than naive > compilers, I'm not aware that MPE's code generators use graph > representations or optimizations.) > > There's nothing wrong with the specification of CASE/ENDCASE. It's just > tough (but not impossible) to generate decent code with the simple code > generation tools we currently have. A jump-table is O(1) whereas testing the values sequentially is O(n) --- it doesn't matter if the processor is register-based or stack-based or whatever --- the problem is that the ANS-Forth CASE requires the values to be tested sequentially.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-24 14:17 +0000 |
| Message-ID | <ob39jd$6rr$1@dont-email.me> |
| In reply to | #56207 |
On 3/23/2017 23:33, hughaguilar96@gmail.com wrote: > On Thursday, March 23, 2017 at 7:39:20 AM UTC-7, Alex wrote: >> >> There's nothing wrong with the specification of CASE/ENDCASE. It's >> just tough (but not impossible) to generate decent code with the >> simple code generation tools we currently have. > > A jump-table is O(1) whereas testing the values sequentially is O(n) > --- it doesn't matter if the processor is register-based or > stack-based or whatever --- the problem is that the ANS-Forth CASE > requires the values to be tested sequentially. > You're assuming that an compiler can't make discoveries about the statements beyond what can be seen at the source level. In most modern compilers, source -> IL in SSA form --> thru transformation & optimization stages --> code, where IL is an intermediate language that is better suited that the source or the code for performing these kind of optimizations. The standard Eaker implementation uses POSTPONE to generate Forth as an IL. (Lots of words can be though of that way; think of your investment in macros that generate Forth from Forth. They are using Forth as the IL.) Although Forth as an IL is easy to use for optimization to a stack based architecture, Forth isn't that useful as an IL on a register based machine (although some optimizations can be done, like constant folding). As an example, I've mentioned before about SSA as an IL between Forth and the eventual machine code. It allows for much more significant optimizations. For example, a tree of generated ILs can be scanned for constructions that are suitable for a jump table by an optimizing phase; say, a CASE statement where every OF is preceded by integer literals in a small range. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-24 11:49 +1100 |
| Message-ID | <ob1qdj$12gi$1@gioia.aioe.org> |
| In reply to | #56182 |
Alex wrote: > On 3/22/2017 22:52, HAA wrote: > > Alex wrote: > >> On 3/22/2017 13:48, HAA wrote: > >>> ... > > > >>>> > >>>> I leave the various implementations to your imagination (or lack of). As > >>>> does the standard. > >>> > >>> Don't leave it to me. You're the one with the imagination. You turn it into > >>> reality :) > >> > >> I am. I've been working for some time on an SSA based optimizer. It's > >> not a trivial exercise, but it is achievable (and as an intellectual > >> exercise, it is an immensely interesting challenge). > > > > So you're going to 'solve' the problem of the bad specification that is ANS > > CASE with a great big fancy optimizer. This is deserving of a Darwin Award. > > > > No, of course that's not my goal. > > CASE is just one example of where high level constructs (and it's pretty > true of any language) and in Forth, low level constructs too, don't map > effectively onto the computer architectures we have. Forth is a two > stack zero address operand language, but most processors are multiple > operand register based and many don't have built in stacks, far less two. > > Constructs like (qv OF) OVER = IF DROP are inefficient on a register > based machine when naively compiled, so code rewriting (which is what > optimizing compilers do) is something that can pay enormous dividends. Dividends come in various forms e.g. technical and political. ANS CASE wasn't defined for technical excellence, it was defined to secure a political outcome - namely accommodating as many existing CASE implementations as possible. > ... > There's nothing wrong with the specification of CASE/ENDCASE. It's just > tough (but not impossible) to generate decent code with the simple code > generation tools we currently have. Implement ANS CASE by whatever means you wish but understand the specification was based on political considerations. I reject any CASE specification that mandates ENDOF. And I might add, so does Forth.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-23 18:12 -0700 |
| Message-ID | <ac6b1e6e-9bfb-4458-8312-fd3e79cf2e86@googlegroups.com> |
| In reply to | #56208 |
On Thursday, March 23, 2017 at 5:48:56 PM UTC-7, HAA wrote: > Dividends come in various forms e.g. technical and political. ANS CASE > wasn't defined for technical excellence, it was defined to secure a political > outcome - namely accommodating as many existing CASE implementations > as possible. Eaker's CASE was commonly provided by Forth systems. UR/Forth provided it. This doesn't mean that anybody actually used it. Testra wrote their own that was efficient. Lots of people wrote their own that generated a jump table. I recently wrote <SWITCH FAST-SWITCH> that generates a jump-table and <SWITCH SLOW-SWITCH> that does a binary search. This kind of programming is pretty easy. The problem with <SWITCH is that the code blocks can't share local variables. This is a failure of ANS-Forth --- Forth-200x also fails in the same way --- no quotations! Every time I write ANS-Forth code, this shines a spotlight on some problem in the ANS-Forth standard --- this is why I say that I'm killing ANS-Forth by writing ANS-Forth code.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-24 08:55 +0000 |
| Message-ID | <ob2mo2$7a3$1@dont-email.me> |
| In reply to | #56208 |
On 3/24/2017 00:49, HAA wrote: > Alex wrote: >> On 3/22/2017 22:52, HAA wrote: >>> Alex wrote: >>>> On 3/22/2017 13:48, HAA wrote: >>>>> ... >> >> Constructs like (qv OF) OVER = IF DROP are inefficient on a >> register based machine when naively compiled, so code rewriting >> (which is what optimizing compilers do) is something that can pay >> enormous dividends. > > Dividends come in various forms e.g. technical and political. ANS > CASE wasn't defined for technical excellence, it was defined to > secure a political outcome - namely accommodating as many existing > CASE implementations as possible. That sounds like a technical outcome. To have as a goal accommodating as few implementations as possible sounds political to me. > >> ... There's nothing wrong with the specification of CASE/ENDCASE. >> It's just tough (but not impossible) to generate decent code with >> the simple code generation tools we currently have. > > Implement ANS CASE by whatever means you wish but understand the > specification was based on political considerations. I reject any > CASE specification that mandates ENDOF. And I might add, so does > Forth. > Forth rejects ENDOF? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-24 09:14 -0500 |
| Message-ID | <O8ednWh6IJVMtEjFnZ2dnUU7-bGdnZ2d@supernews.com> |
| In reply to | #56218 |
Alex <alex@rivadpm.com> wrote: > On 3/24/2017 00:49, HAA wrote: >> Alex wrote: >>> On 3/22/2017 22:52, HAA wrote: >> >> Dividends come in various forms e.g. technical and political. ANS >> CASE wasn't defined for technical excellence, it was defined to >> secure a political outcome - namely accommodating as many existing >> CASE implementations as possible. > > That sounds like a technical outcome. To have as a goal accommodating as > few implementations as possible sounds political to me. But what HAA says about CASE is not true anyway. The Eaker case statement was the result of an open competition, in http://www.forth.org/fd/FD-V02N3.pdf I don't like the standard Eaker case structure, but to call it a "political" decision is bullshit. It was standardized because it was already widely adopted. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web