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 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-16 16:59 +0000 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <o84lma$ifa$1@dont-email.me> |
| In reply to | #54882 |
On 2/16/2017 14:41, Alex wrote: > On 2/15/2017 23:49, Alex wrote: >> On 2/13/2017 16:52, Anton Ertl wrote: >>>> Much easier than having to stack balance; apropos the recognizer >>>> proposal, it's a better technique IMHO than expensive stack cleaning >>>> and >>>> returning R:FAIL. >> >>> Matthias Trute gives a pretty convincing comparison of R:FAIL >>> vs. returning 0 in his proposal. Work out an example (maybe the same >>> one) with a alternative based on THROW. Maybe you can convince us >>> all. >>> >> >> This uses the example from the appendix of >> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf >> >> First, we remove the definition of DT:NULL and replace it with DT:FAIL; >> >> : DT:FAIL -13 THROW ; >> >> The example uses a float conversion: >> >> : REC:FLOAT ( addr len -- DT:FLOAT | DT:NULL ) ( F: -- f ) >> >FLOAT IF DT:FLOAT ELSE DT:NULL THEN ; >> >> : REC:FLOAT ( addr len -- DT:FLOAT ) ( F: -- f ) >> >FLOAT IF DT:FLOAT ELSE DT:FAIL THEN ; >> >> There is no effective difference between the two, since the stack is >> unperturbed. Here's a toy example where the stack cleanup to provide a >> DT:NULL adds to the clutter: >> >> : REC:NUM ( addr len -- d DT:NUM | DT:NULL ) >> 0 0 2SWAP >NUMBER IF DROP 2DROP DT:NULL ELSE DROP DT:NUM THEN ; >> >> : REC:NUM ( addr len -- d DT:NUM ) >> 0 0 2SWAP >NUMBER IF DT:FAIL ELSE DROP DT:NUM THEN ; >> >> The DT:FAIL version is shorter, in that it simply junks the stack and >> the rstack, which would require R> DROPs, later & automatically in the >> CATCHing word rather than in the recognizer. >> >> The only other changes in the proposal are to RECOGNIZE: >> >> : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN | DT:NULL ) >> DUP >R @ >> BEGIN >> DUP >> WHILE >> DUP CELLS R@ + @ >> 2OVER 2>R SWAP 1- >R >> EXECUTE DUP >> DT:NULL <> IF >> 2R> 2DROP 2R> 2DROP EXIT >> THEN >> DROP R> 2R> ROT >> REPEAT >> DROP 2DROP R> DROP >> DT:NULL ; >> >> : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN ) >> DUP >R @ >> BEGIN >> DUP >> WHILE >> DUP CELLS R@ + @ >> 2OVER 2>R SWAP 1- >R >> CATCH 0= IF >> 2R> 2DROP 2R> 2DROP EXIT >> THEN >> DROP R> 2R> ROT > > I think this may need to be 2DROP R> 2R> ROT. It's untested. > >> REPEAT >> DT:FAIL ; >> >> In RECOGNIZE the CATCH 0= replaces EXECUTE DUP DT:NULL <> >> and DT:FAIL replaces DROP 2DROP R> DROP DT:NULL >> >> All this assumes that the interpreter has a CATCH of last resort that >> prints a suitable not found. >> > > The advantages are: > > 1. The code required for each REC:x is shorter and easier to code in the > failure case. There may be multiple DT:NULL exits required in more > complex REC:x cases. There are no issues about stack or rstack cleanup, > since it's handled in THROW/CATCH. The REC:x word does not have variable > stack effects of ( i*x DT:something | DT:NULL ). > > 2. Should the conversion fail for any other reason (bug, complexity) > then the whole system doesn't crash; the error is isolated to the REC:x > word in question. > > Neutral: > > 3. The advantage fo RECOGNIZE being shorter is not that material, since > it's probably only written once. > > Downsides: > > 4. Requires the EXCEPTION wordset. > > But then: > > 5. This could be provided as an alternative implementation for REC:x > words; cleaning the stacks and returning DT:NULL is exactly equivaent to > cleaning the stacks and having DT:NULL do a -13 THROW. As long as > RECOGNIZE is set up to handle it, the REC:x programmer need not account > for what DT:NULL does. > I do like this proposal, and it has certainly simplified much of my code. Matthias Trute is to be complimented on documenting this. There are certain aspects that I'm less keen on however. Here I make a general observations about names in the proposal. 1. REC-STACK should be RECOGNIZER-STACK. Yes, it's longer, but it's clearer and less ambiguous. REC could be short for RECORD. 2. FORTH-RECOGNIZER is misnamed, since it's not a recognizer. I also can't see why it needs to be standardised, notwithstanding the explanations provided. 3. Using : in DT:type and REC:type names is the first use I have seen of special characters used to prefix and *classify* sets of words, see A.XY.4. REC: and DT: prefixes are largely eye-candy, since apart from DT:NULL none of the DT:type words is standardised, and there are no standardised REC: words. I can see an opportunity to use imbedded : for objects, classes or somesuch. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-11 15:05 +0000 |
| Subject | Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <oa13hj$57b$1@dont-email.me> |
| In reply to | #54841 |
On 2/13/2017 16:52, Anton Ertl wrote:
>> Much easier than having to stack balance; apropos the recognizer
>> proposal, it's a better technique IMHO than expensive stack cleaning and
>> returning R:FAIL.
> Matthias Trute gives a pretty convincing comparison of R:FAIL
> vs. returning 0 in his proposal. Work out an example (maybe the same
> one) with a alternative based on THROW. Maybe you can convince us
> all.
>
This uses the example from the appendix of
http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf
First, we remove the definition of DT:NULL and replace it with REC:FAIL;
: REC:FAIL -13 THROW ;
The example uses a float conversion:
: REC:FLOAT ( addr len -- DT:FLOAT | DT:NULL ) ( F: -- f )
>FLOAT IF DT:FLOAT ELSE DT:NULL THEN ;
: REC:FLOAT ( addr len -- DT:FLOAT ) ( F: -- f )
>FLOAT IF DT:FLOAT ELSE REC:FAIL THEN ;
There is no effective difference between the two, since the stack is
unperturbed. Here's a toy example where the stack cleanup to provide a
DT:NULL adds to the clutter:
: REC:NUM ( addr len -- d DT:NUM | DT:NULL )
0 0 2SWAP >NUMBER IF DROP 2DROP DT:NULL ELSE DROP DT:NUM THEN ;
: REC:NUM ( addr len -- d DT:NUM )
0 0 2SWAP >NUMBER IF REC:FAIL ELSE DROP DT:NUM THEN ;
The REC:FAIL version is shorter, in that it simply junks the stack and
the rstack, which would require R> DROPs, later & automatically in the
CATCHing word rather than in the recognizer.
The only other changes in the proposal are to RECOGNIZE:
: RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN | DT:NULL )
DUP >R @
BEGIN
DUP
WHILE
DUP CELLS R@ + @
2OVER 2>R SWAP 1- >R
EXECUTE DUP
DT:NULL <> IF
2R> 2DROP 2R> 2DROP EXIT
THEN
DROP R> 2R> ROT
REPEAT
DROP 2DROP R> DROP
DT:NULL ;
: RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN )
DUP >R @
BEGIN
DUP
WHILE
DUP CELLS R@ + @
2OVER 2>R SWAP 1- >R
CATCH 0= IF
2R> 2DROP 2R> 2DROP EXIT
THEN
DROP R> 2R> ROT
REPEAT
REC:FAIL ;
In RECOGNIZE the CATCH 0= replaces EXECUTE DUP DT:NULL <>
and REC:FAIL replaces DROP 2DROP R> DROP DT:NULL
All this assumes that the interpreter has a CATCH of last resort that
prints a suitable not found.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-03-13 12:37 -0700 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <a2aefa58-1405-4c1d-8928-ce011a37c626@googlegroups.com> |
| In reply to | #55630 |
Am Samstag, 11. März 2017 16:05:03 UTC+1 schrieb Alex: > On 2/13/2017 16:52, Anton Ertl wrote: > >> Much easier than having to stack balance; apropos the recognizer > >> proposal, it's a better technique IMHO than expensive stack cleaning and > >> returning R:FAIL. > > > Matthias Trute gives a pretty convincing comparison of R:FAIL > > vs. returning 0 in his proposal. Work out an example (maybe the same > > one) with a alternative based on THROW. Maybe you can convince us > > all. > > > > This uses the example from the appendix of > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf > > First, we remove the definition of DT:NULL and replace it with REC:FAIL; > > : REC:FAIL -13 THROW ; > > The example uses a float conversion: > > : REC:FLOAT ( addr len -- DT:FLOAT | DT:NULL ) ( F: -- f ) > >FLOAT IF DT:FLOAT ELSE DT:NULL THEN ; > > : REC:FLOAT ( addr len -- DT:FLOAT ) ( F: -- f ) > >FLOAT IF DT:FLOAT ELSE REC:FAIL THEN ; > > There is no effective difference between the two, since the stack is > unperturbed. Here's a toy example where the stack cleanup to provide a > DT:NULL adds to the clutter: > > : REC:NUM ( addr len -- d DT:NUM | DT:NULL ) > 0 0 2SWAP >NUMBER IF DROP 2DROP DT:NULL ELSE DROP DT:NUM THEN ; > > : REC:NUM ( addr len -- d DT:NUM ) > 0 0 2SWAP >NUMBER IF REC:FAIL ELSE DROP DT:NUM THEN ; > > The REC:FAIL version is shorter, in that it simply junks the stack and > the rstack, which would require R> DROPs, later & automatically in the > CATCHing word rather than in the recognizer. > > The only other changes in the proposal are to RECOGNIZE: > > : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN | DT:NULL ) > DUP >R @ > BEGIN > DUP > WHILE > DUP CELLS R@ + @ > 2OVER 2>R SWAP 1- >R > EXECUTE DUP > DT:NULL <> IF > 2R> 2DROP 2R> 2DROP EXIT > THEN > DROP R> 2R> ROT > REPEAT > DROP 2DROP R> DROP > DT:NULL ; > > : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN ) > DUP >R @ > BEGIN > DUP > WHILE > DUP CELLS R@ + @ > 2OVER 2>R SWAP 1- >R > CATCH 0= IF > 2R> 2DROP 2R> 2DROP EXIT > THEN > DROP R> 2R> ROT > REPEAT > REC:FAIL ; > > In RECOGNIZE the CATCH 0= replaces EXECUTE DUP DT:NULL <> > and REC:FAIL replaces DROP 2DROP R> DROP DT:NULL > > All this assumes that the interpreter has a CATCH of last resort that > prints a suitable not found. I highly appreciate your work. Thank you for doing it. Really My major concern with the exceptions is not that they are not available everywhere or that they would not solve the problem. No: I think that they are not the right tool to implement a control work flow. Would you use exceptions to LEAVE a counted loop? I won't. The RFD has a section why I don't like and won't use exceptions for recognizers. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-13 21:32 +0000 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <oa7307$1fe$1@dont-email.me> |
| In reply to | #55737 |
On 3/13/2017 19:37, Matthias Trute wrote:
> Am Samstag, 11. März 2017 16:05:03 UTC+1 schrieb Alex:
>> On 2/13/2017 16:52, Anton Ertl wrote:
>>>> Much easier than having to stack balance; apropos the recognizer
>>>> proposal, it's a better technique IMHO than expensive stack cleaning and
>>>> returning R:FAIL.
>>
>>> Matthias Trute gives a pretty convincing comparison of R:FAIL
>>> vs. returning 0 in his proposal. Work out an example (maybe the same
>>> one) with a alternative based on THROW. Maybe you can convince us
>>> all.
>>>
>>
>> This uses the example from the appendix of
>> http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf
>>
>> First, we remove the definition of DT:NULL and replace it with REC:FAIL;
>>
>> : REC:FAIL -13 THROW ;
>>
[snipped]
>
> I highly appreciate your work. Thank you for doing it. Really
You're welcome. Overall, I like the concept. I have implemented the
recognizer asis, and a modified version (the header in the word controls
the recognition), and with REC:FAIL in the place of DT:NULL.
>
> My major concern with the exceptions is not that they are not
> available everywhere or that they would not solve
> the problem. No: I think that they are not the right tool
> to implement a control work flow. Would you use exceptions
> to LEAVE a counted loop? I won't. The RFD has a section why
> I don't like and won't use exceptions for recognizers.
I think your concern lies here (from
http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf):
"In addition, an exception is a somewhat elaborate error handling tool
and usually means than something unexpected has happened. Matching a
string to a sequence of patterns means that exceptions are used in a
normal sequence of compare operations."
I have never seen CATCH/THROW as indicating "unexpected" operation, nor
as being terribly elaborate (perhaps to implement, but to use it is
simplicity itself). Maybe it's because the standard describes it as the
exception wordset, and the word "exception" is overloaded with an
implication of complexity or infrequency or wrongness.
I see CATCH/THROW as a very normal way of regaining control of an
unknown or annoyingly complex flow. Without having to program a way out
of the maze, we simply hop over all the hedges to where we started.
Here's an example of parsing an IP address of the form n.n.n.n
: ip-seg ( addr len -- addr' len' n ) \ IP segment before dot .
dup >r \ save length
0 0 2swap >number \ convert to number
2swap d>s \ save string & convert to single
over r> <> \ check lengths differ before & after
over 0 256 within \ and range check it
and 0= if rec:fail then \ flag; true=error
;
: ip-number? ( addr len -- d ) \ convert ip address
8 24 do \ 3 dotted segments
ip-seg \ convert up to dot
i lshift \ shift the value,
-rot \ addr string to top
dup 0= if rec:fail then \ string too short?
over c@ '.' <> if rec:fail then \ check for a dot, error if not
1 /string \ move past .
-8 +loop \ next shift
ip-seg \ convert what's left
-rot if rec:fail then \ should be nothing left
drop or or or dt:single \ or in to get result, make single
;
This (yes, it's terrible) code has 4 fail points. If I was to use
DT:NULL I have little confidence I know exactly what's on the stack, and
it will make the code really messy & less clear with multiple UNLOOPs
and DROPs and EXITs.
I'll continue to experiment. I'm moving on to writing & testing parsing
recognizers.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-14 04:42 -0500 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <voCdnWqkrOGMJlrFnZ2dnUU7-S3NnZ2d@supernews.com> |
| In reply to | #55738 |
Alex <alex@rivadpm.com> wrote: > > I have never seen CATCH/THROW as indicating "unexpected" operation, nor > as being terribly elaborate (perhaps to implement, but to use it is > simplicity itself). Maybe it's because the standard describes it as the > exception wordset, and the word "exception" is overloaded with an > implication of complexity or infrequency or wrongness. > > I see CATCH/THROW as a very normal way of regaining control of an > unknown or annoyingly complex flow. Without having to program a way out > of the maze, we simply hop over all the hedges to where we started. That's an interesting view. The Forth CATCH/THROW mechanism is the simplest exception-handling mechanism that I have seen, and may be almost the simplest possible. (Having said that, there is the business about restoring the input source specification, which is usually unnecessary. But never mind.) The mechanism generally used by C++ and Java implementations is, in contrast, very complex. > This (yes, it's terrible) code has 4 fail points. If I was to use > DT:NULL I have little confidence I know exactly what's on the stack, > and it will make the code really messy & less clear with multiple > UNLOOPs and DROPs and EXITs. That's a perfectly reasonable explanation, but throwing an exception in order not to have to remember how many items are on the stack is a bit meh. Put everything in locals? ;-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-14 11:45 +0000 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <oa8kvs$8an$1@dont-email.me> |
| In reply to | #55754 |
On 3/14/2017 09:42, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> >> I have never seen CATCH/THROW as indicating "unexpected" operation, >> nor as being terribly elaborate (perhaps to implement, but to use >> it is simplicity itself). Maybe it's because the standard describes >> it as the exception wordset, and the word "exception" is overloaded >> with an implication of complexity or infrequency or wrongness. >> >> I see CATCH/THROW as a very normal way of regaining control of an >> unknown or annoyingly complex flow. Without having to program a way >> out of the maze, we simply hop over all the hedges to where we >> started. > > That's an interesting view. The Forth CATCH/THROW mechanism is the > simplest exception-handling mechanism that I have seen, and may be > almost the simplest possible. (Having said that, there is the > business about restoring the input source specification, which is > usually unnecessary. But never mind.) As noted here http://www.forth200x.org/input-source-restoration.html, nobody seems to bother, and the standard is ignored (in fact, the standard THROW may be unimplementable). I also asked a (long winded) question in 2011 about restoring STATE on CATCH/THROW and got a variety of answers. My take is THROW should not try & unwind the side effects, just the stacks, and leave all other recovery twiddles to the programmer. > The mechanism generally used by C++ and Java implementations is, in > contrast, very complex. That's a problem for them (or you if that's your bag). Ours is one of reluctance to use a simple & available mechanism. If it was described as checkpointing, I think it might have more acceptance as a regular technique. > >> This (yes, it's terrible) code has 4 fail points. If I was to use >> DT:NULL I have little confidence I know exactly what's on the >> stack, and it will make the code really messy & less clear with >> multiple UNLOOPs and DROPs and EXITs. > > That's a perfectly reasonable explanation, but throwing an exception > in order not to have to remember how many items are on the stack is a > bit meh. Put everything in locals? ;-) The loop is building up a number of entries on the stack. For each iteration, the number to DROP is only known by inspecting either DEPTH, maintaining a marker on the stack, or calculating it from I and doing a loop to DROP them. It could be coded differently, but just to support DT:FAIL? Double meh. Code with abandon, use THROW and be damned. As for locals... You're 'avin a giraffe. Besides, my locals implementation is currently broken, and I don't really have any interest in finding out why right now, since I don't use them. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-14 12:41 +0000 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <oa8o83$jpv$1@dont-email.me> |
| In reply to | #55761 |
On 3/14/2017 11:45, Alex wrote:
> On 3/14/2017 09:42, Andrew Haley wrote:
>>
>> That's a perfectly reasonable explanation, but throwing an exception
>> in order not to have to remember how many items are on the stack is a
>> bit meh. Put everything in locals? ;-)
>
> The loop is building up a number of entries on the stack. For each
> iteration, the number to DROP is only known by inspecting either DEPTH,
> maintaining a marker on the stack, or calculating it from I and doing a
> loop to DROP them. It could be coded differently, but just to support
> DT:FAIL? Double meh. Code with abandon, use THROW and be damned.
On reflection, there is a compromise that allows for DT:NULL and THROW
to co-exist. The recognizer just needs to use CATCH in the place of
EXECUTE and extend the test for success;
: RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN )
DUP >R @
BEGIN
DUP
WHILE
DUP CELLS R@ + @
2OVER 2>R SWAP 1- >R
CATCH 0= OVER DT:NULL <> AND IF \ extended test
2R> 2DROP 2R> 2DROP EXIT
THEN
DROP R> 2R> ROT
REPEAT
DROP 2DROP R> DROP DT:NULL ;
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-03-14 14:20 +0100 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <oa8qnp$ulg$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55761 |
In article <oa8kvs$8an$1@dont-email.me>, Alex <alex@rivadpm.com> wrote:
>On 3/14/2017 09:42, Andrew Haley wrote:
>> Alex <alex@rivadpm.com> wrote:
>>>
>>> I have never seen CATCH/THROW as indicating "unexpected" operation,
>>> nor as being terribly elaborate (perhaps to implement, but to use
>>> it is simplicity itself). Maybe it's because the standard describes
>>> it as the exception wordset, and the word "exception" is overloaded
>>> with an implication of complexity or infrequency or wrongness.
>>>
>>> I see CATCH/THROW as a very normal way of regaining control of an
>>> unknown or annoyingly complex flow. Without having to program a way
>>> out of the maze, we simply hop over all the hedges to where we
>>> started.
>>
>> That's an interesting view. The Forth CATCH/THROW mechanism is the
>> simplest exception-handling mechanism that I have seen, and may be
>> almost the simplest possible. (Having said that, there is the
>> business about restoring the input source specification, which is
>> usually unnecessary. But never mind.)
>
>As noted here http://www.forth200x.org/input-source-restoration.html,
>nobody seems to bother, and the standard is ignored (in fact, the
>standard THROW may be unimplementable). I also asked a (long winded)
>question in 2011 about restoring STATE on CATCH/THROW and got a variety
>of answers. My take is THROW should not try & unwind the side effects,
>just the stacks, and leave all other recovery twiddles to the programmer.
In ciforth I circumvented the problem. All input streams except the
console ( the input stream used by QUIT), are fully read in, so
a stream is defined by an area in memory plus a pointer (aka >IN).
These 3 numbers can be remembered by SAVE and restored by RESTORE.
No attempt is done to make that mechanism part of THROW.
You probably know by now that I want recognizers to be able to discriminate
using the first part of a denotation (the prefix). This means a
recognizer may throw, because normally there is no alternative.
This runs into a slight trouble with numbers, because if I add a floating
point package now denotations become ambiguous.
If it starts with 7, recognized by the prefix 7, it
can be either an integer or a fp number.
7 formerly calls (NUMBER) , to do the parsing, and then does or doesn't
compile as a LITERAL depending on STATE.
We now can add floating point numbers as a loadable extension, putting
CATCH / THROW to good use.
[ PP replace >IN , EPL is the place of the exponentiation sign,
XC is the the character used for exponentiation, say &E ]
' (NUMBER) ALIAS PARSE-INT
\ Handle a number in the input stream. EPL show whether it is fp or not.
: NEW-(NUMBER) 0 EPL ! \ default: an integer
'PARSE-INT CATCH
\ Error 10, not a digit, and we are at an XC exponentiation char?
DUP 10 = PP @ 1- C@ XC = AND IF
\ May not be an error, but an fp number,
DROP PP @ 1- EPL ! PARSE-FLOAT \ PARSE-FLOAT may THROW
ELSE THROW THEN ; \ Fault is for real.
' NEW-(NUMBER) >DFA @ ' (NUMBER) >DFA ! \ Revector (NUMBER)
<SNIP>
>
>As for locals... You're 'avin a giraffe. Besides, my locals
>implementation is currently broken, and I don't really have any interest
>in finding out why right now, since I don't use them.
Based on the recent discussion, I looked up the definition of (LOCAL).
By implementing it , one doubles/destroys the elegant wordlist design,
introduce foreign concepts, and have a mixin of reentrancy where you
least expect.
For less implementation effort I have nestable definitions which gives
me a local equivalent for everything, VARIABLE's,CONSTANT's, colon
definitions and user defined CREATEons. Then such colon definitions
can have their own local anything's.
There is a reason to hate locals!
>
>--
>Alex
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 16:15 -0500 |
| Message-ID | <o7ddag$9it$1@dont-email.me> |
| In reply to | #54690 |
On 2/7/2017 12:54 PM, Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: >> I would just write: >> >> begin >> n1 of ... end >> n2 of ... end >> condition if ... end >> again > > Interestingly, I had to look at this for quite a while to understand > that; despite this END being discussed recently and quite at length > here, the usage here just slipped past my radar. That might change if > it catches on, but I don't see it as beneficial enough to justify the > transition cost. > > That being said, I like the general concept better than ?EXIT, because > there often is cleanup work that has to be done before EXITing, so > ?EXIT is really wrong factoring, but at least the ?EXIT name does not > need any getting-used to in order to see what's going on. I don't follow. What cleanup work is needed with ?EXIT that isn't with END? How would this be factored otherwise? > Which brings me to the benefits of using THROW. THROW does the stack > and DO..LOOP cleanup by itself, and that really lowers the programming > burden. E.g., if you have > > IF 2drop rdrop true EXIT THEN > or > IF nip nip unloop exit THEN > > (taken from real code), you first have to write this code to clean up > the stacks, and when you change something in the word, you may have to > update it. By contrast, when you exit with > > ( flag ) condition# and throw > > all that goes away, and you can mostly think about the word (or at > least that part of the word) as if you were dealing with straight-line > code. Another advantage is that, like straight-line code, you can > factor parts of the code (including the THROW) out into separate > words, unlike code containing EXIT. > > The downsides are that you need to CATCH the conditions, and that > CATCH and THROW are typically not the fastest words around around. > >> It's 2017. Not 1994 when nobody knew any better. > > I don't see that using EXIT THEN or a macro for it is anything that we > learned after 1994. The main reason for not using END and even ?EXIT unless it is really needed is the ease of understanding control flow in a program. I recall reading this being discussed by one of the pioneers in programming, maybe Knuth. He admitted that while structured programming was good, there are always exceptions. For me, I'm just not seeing the utility in this. Yes, it can be a bit shorter to type, but I don't agree that it makes any other aspect easier. I'm used to VHDL (one of the most verbose languages I've ever used) and so a bit of extra typing to preserve the visual cues is no problem. But the biggest issue with using END for me is that it is one more thing to learn. The looping controls are a bit of a PITA because they are mix and match so that you have to really understand them to know how to properly use them. I prefer to not have to remember the rules for using a much less standard control structure. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-13 16:49 +0000 |
| Message-ID | <2017Feb13.174907@mips.complang.tuwien.ac.at> |
| In reply to | #54695 |
rickman <gnuarm@gmail.com> writes:
>On 2/7/2017 12:54 PM, Anton Ertl wrote:
>> That being said, I like the general concept better than ?EXIT, because
>> there often is cleanup work that has to be done before EXITing, so
>> ?EXIT is really wrong factoring, but at least the ?EXIT name does not
>> need any getting-used to in order to see what's going on.
>
>I don't follow. What cleanup work is needed with ?EXIT that isn't with
>END?
You often need to clean up the stack (and possibly other things)
between the IF and the EXIT; ?EXIT does not allow you to do that, END
does.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-08 19:43 +1100 |
| Message-ID | <o7em03$u84$1@gioia.aioe.org> |
| In reply to | #54690 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >I would just write: > > > >begin > > n1 of ... end > > n2 of ... end > > condition if ... end > >again > > Interestingly, I had to look at this for quite a while to understand > that; despite this END being discussed recently and quite at length > here, the usage here just slipped past my radar. That might change if > it catches on, but I don't see it as beneficial enough to justify the > transition cost. There is no transition cost as far as I can see. Everything remains backward compatible. CASE OF ENDOF ENDCASE in old code works just as before. END does for Case statements what ELSE elimination does elsewhere. It would be fair to ask how often does it occur. In my experience more often than not. In a recent application I employed 11 case statements. Of these, 9 were using ENDOF for no other reason than ANS expected it. With a suitable implementation of OF, END can replace ENDOF and as a bonus CASE and ENDCASE in these definitions can also be removed. No more issues with the built-in DROP in ENDCASE which most agree was more trouble than it was worth. > > That being said, I like the general concept better than ?EXIT, because > there often is cleanup work that has to be done before EXITing, so > ?EXIT is really wrong factoring, but at least the ?EXIT name does not > need any getting-used to in order to see what's going on. Would ?EXIT have existed had somebody noticed EXIT THEN occurs far more frequently? I doubt it. > ... > The downsides are that you need to CATCH the conditions, and that > CATCH and THROW are typically not the fastest words around around. Hence the word UNLOOP. But at least you can replace the EXIT THEN that follows with END. > > >It's 2017. Not 1994 when nobody knew any better. > > I don't see that using EXIT THEN or a macro for it is anything that we > learned after 1994. > > - anton Perhaps it is now clearer. Adding new Case words in 2017 based on a 1994 definition of OF would be tantamount to having learnt nothing. Better to deal with the problem that prompted these words.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-13 16:31 +0000 |
| Message-ID | <2017Feb13.173130@mips.complang.tuwien.ac.at> |
| In reply to | #54712 |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >I would just write:
>> >
>> >begin
>> > n1 of ... end
>> > n2 of ... end
>> > condition if ... end
>> >again
>>
>> Interestingly, I had to look at this for quite a while to understand
>> that; despite this END being discussed recently and quite at length
>> here, the usage here just slipped past my radar. That might change if
>> it catches on, but I don't see it as beneficial enough to justify the
>> transition cost.
>
>There is no transition cost as far as I can see.
I pointed out the transition cost in the above: Forth programmers
would need to learn what END means now.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-14 11:12 +1100 |
| Message-ID | <o7thti$flp$1@gioia.aioe.org> |
| In reply to | #54839 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >Anton Ertl wrote: > >> "HAA" <someone@microsoft.com> writes: > >> >I would just write: > >> > > >> >begin > >> > n1 of ... end > >> > n2 of ... end > >> > condition if ... end > >> >again > >> > >> Interestingly, I had to look at this for quite a while to understand > >> that; despite this END being discussed recently and quite at length > >> here, the usage here just slipped past my radar. That might change if > >> it catches on, but I don't see it as beneficial enough to justify the > >> transition cost. > > > >There is no transition cost as far as I can see. > > I pointed out the transition cost in the above: Forth programmers > would need to learn what END means now. > > - anton You expressed no such concerns when promoting ACTION-OF DEFER@ DEFER! ?OF CONTOF NEXT-CASE. Unlike the above which add complexity to Forth, END aims to simplify Forth by removing redundancy where it exists and removing restrictions from CASE which required Forth programmers to engage in inefficient coding practices and invent specialized words such as the above.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-15 17:22 +0000 |
| Message-ID | <2017Feb15.182251@mips.complang.tuwien.ac.at> |
| In reply to | #54844 |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >Anton Ertl wrote:
>> >> "HAA" <someone@microsoft.com> writes:
>> >> >I would just write:
>> >> >
>> >> >begin
>> >> > n1 of ... end
>> >> > n2 of ... end
>> >> > condition if ... end
>> >> >again
>> >>
>> >> Interestingly, I had to look at this for quite a while to understand
>> >> that; despite this END being discussed recently and quite at length
>> >> here, the usage here just slipped past my radar. That might change if
>> >> it catches on, but I don't see it as beneficial enough to justify the
>> >> transition cost.
>> >
>> >There is no transition cost as far as I can see.
>>
>> I pointed out the transition cost in the above: Forth programmers
>> would need to learn what END means now.
>>
>> - anton
>
>You expressed no such concerns when promoting ACTION-OF DEFER@
>DEFER! ?OF CONTOF NEXT-CASE.
DEFER@ and DEFER! are normal words without particular influence on the
control flow. ACTION-OF was not my idea; I don't need it, but the
choice appeared to be to have either a standard with ACTION-OF, or a
standard without DEFER.
?OF CONTOF and NEXT-CASE have not been suggested for standardization.
In any case, with usual indentation, it's obvious that they are
control-flow words. That's also obvious with END, but the hidden EXIT
is non-obvious.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-17 10:16 +1100 |
| Message-ID | <o85boo$djr$1@gioia.aioe.org> |
| In reply to | #54864 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >Anton Ertl wrote: > >> "HAA" <someone@microsoft.com> writes: > >> >Anton Ertl wrote: > >> >> "HAA" <someone@microsoft.com> writes: > >> >> >I would just write: > >> >> > > >> >> >begin > >> >> > n1 of ... end > >> >> > n2 of ... end > >> >> > condition if ... end > >> >> >again > >> >> > >> >> Interestingly, I had to look at this for quite a while to understand > >> >> that; despite this END being discussed recently and quite at length > >> >> here, the usage here just slipped past my radar. That might change if > >> >> it catches on, but I don't see it as beneficial enough to justify the > >> >> transition cost. > >> > > >> >There is no transition cost as far as I can see. > >> > >> I pointed out the transition cost in the above: Forth programmers > >> would need to learn what END means now. > >> > >> - anton > > > >You expressed no such concerns when promoting ACTION-OF DEFER@ > >DEFER! ?OF CONTOF NEXT-CASE. > > DEFER@ and DEFER! are normal words without particular influence on the > control flow. ACTION-OF was not my idea; I don't need it, but the > choice appeared to be to have either a standard with ACTION-OF, or a > standard without DEFER. > > ?OF CONTOF and NEXT-CASE have not been suggested for standardization. That's just as well. ACTION-OF DEFER@ DEFER! ?OF CONTOF NEXT-CASE are the consequences of TC's failure to provide simplicity for Forth users. > In any case, with usual indentation, it's obvious that they are > control-flow words. That's also obvious with END, but the hidden EXIT > is non-obvious. > > - anton Users of END no more need to know there is a built-in EXIT than do users of semicolon ';' Saying END replaces EXIT THEN is the practical effect and suffices for all but raw beginners. Standards however leave nothing to guess requiring each word be accompanied by a formal definition. I strongly recommend END and the simplification of CASE but it's a decision for each implementer. I've provided examples of the benefits in other posts.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-01-26 09:11 -0800 |
| Message-ID | <76c35132-352c-4325-ab31-70cf664c8a7e@googlegroups.com> |
| In reply to | #54414 |
On Thursday, 26 January 2017 09:35:55 UTC, Andrew Haley wrote: > It can do that even if OF is a synonym for OVER = IF . And ENDOF is a > synonym for ELSE. Which it damn well should be, IMO. > Probably. And there's no reason why it shouldn't, /outside of a CASE structure/ But it's just syntax: OVER = IF is an easily understood phrase. But if you mandate that OF ... END must be possible /within/ a CASE then it does make jump tables and NEXTCASE (see Anton above) a lot more complex than they might be for little gain. I was responding to Hugh's statement: >CASE is one of the major blunders in ANS-Forth design --- the standard is supposed to standardize behavior rather than implementation --- CASE has to be nested IF statements though, which is horribly inefficient. >I has to be nested IF statements because the possibility of having two conditionals for the same value wasn't explicitly disallowed. I didn't quote it because I was on a tablet.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-28 11:07 +1100 |
| Message-ID | <o6gna5$3ls$1@gioia.aioe.org> |
| In reply to | #54431 |
JennyB wrote: > On Thursday, 26 January 2017 09:35:55 UTC, Andrew Haley wrote: > > > > It can do that even if OF is a synonym for OVER = IF . And ENDOF is a > > synonym for ELSE. Which it damn well should be, IMO. > > > Probably. And there's no reason why it shouldn't, /outside of a CASE structure/ But > it's just syntax: OVER = IF is an easily understood phrase. But if you mandate that OF > ... END must be possible /within/ a CASE then it does make jump tables and NEXTCASE > (see Anton above) a lot more complex than they might be for little gain. > > I was responding to Hugh's statement: > > >CASE is one of the major blunders in ANS-Forth design --- the standard is supposed to > >standardize behavior rather than implementation --- CASE has to be nested IF > >statements though, which is horribly inefficient. > > >I has to be nested IF statements because the possibility of having two conditionals > >for the same value wasn't explicitly disallowed. > > I didn't quote it because I was on a tablet. IMO the classic nested Case will do for many situations provided it's flexible. Should a faster or specialized Case be needed it can be loaded. One such is Rick VanNorman's extensible case (FD 20/3) which uses fetches instead of jumps to traverse the list.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-27 18:31 -0800 |
| Message-ID | <7c3a6cc5-17dd-4139-930d-77e96ab816b7@googlegroups.com> |
| In reply to | #54431 |
On Thursday, January 26, 2017 at 10:11:18 AM UTC-7, JennyB wrote: > On Thursday, 26 January 2017 09:35:55 UTC, Andrew Haley wrote: > > > > It can do that even if OF is a synonym for OVER = IF . And ENDOF is a > > synonym for ELSE. Which it damn well should be, IMO. > > > Probably. And there's no reason why it shouldn't, /outside of a CASE structure/ But it's just syntax: OVER = IF is an easily understood phrase. But if you mandate that OF ... END must be possible /within/ a CASE then it does make jump tables and NEXTCASE (see Anton above) a lot more complex than they might be for little gain. > > I was responding to Hugh's statement: > > >CASE is one of the major blunders in ANS-Forth design --- the standard is supposed to standardize behavior rather than implementation --- CASE has to be nested IF statements though, which is horribly inefficient. > > >I has to be nested IF statements because the possibility of having two conditionals for the same value wasn't explicitly disallowed. > > I didn't quote it because I was on a tablet. The CASE in ANS-Forth can not compile into a jump-table. ANS-Forth is a cult! Now, over two decades later we have ANS-Forth enthusiasts claiming that CASE can compile into a jump-table, which is blatantly untrue, but all of the cult members just nod and say nothing --- they assume that any positive thing said about ANS-Forth is helping ANS-Forth --- they are not considering how blatant lies such as this make the entire Forth community look like a pack of liars. The standard is supposed to standardize behavior, not implementation, but CASE standardizes implementation (it requires the CASE construct to be syntactic sugar for nested IF ELSE THEN constructs) --- it is obvious that Elizabeth Rather doesn't know what a jump-table is --- it is obvious that she doesn't know C and didn't make any effort to give standard Forth comparable features.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-29 12:07 +1100 |
| Message-ID | <o6jf6g$i0$1@gioia.aioe.org> |
| In reply to | #54476 |
hughaguilar96@gmail.com wrote: > ... > The standard is supposed to standardize behavior, not implementation, but CASE > standardizes implementation > ... It also standardizes common practice which is why ANS CASE was defined as it was. Anything else would have broken somebody's CASE. ANS is not a cult. It's an investment with a poor dividend and high turnover of management and investors :)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-28 17:37 -0800 |
| Message-ID | <15e0edde-b0f6-4811-bb32-55144c6751de@googlegroups.com> |
| In reply to | #54506 |
On Saturday, January 28, 2017 at 6:06:29 PM UTC-7, HAA wrote: > hughaguilar96@gmail.com wrote: > > ... > > The standard is supposed to standardize behavior, not implementation, but CASE > > standardizes implementation > > ... > > It also standardizes common practice which is why ANS CASE was defined as > it was. Anything else would have broken somebody's CASE. ANS is not a cult. > It's an investment with a poor dividend and high turnover of management and > investors :) Eaker's CASE didn't have to be put in the standard because it is trivial to write using ordinary meta-compiling --- it is just some macros wrapping IF ELSE THEN --- similarly, your END is trivial to write using ordinary meta-compiling. OTOH a SWITCH that generates a jump-table can't be written using ordinary meta-compiling --- this is something that has to be built into the language --- my <SWITCH is written in ANS-Forth using ordinary meta-compiling, but it isn't very good because the table entries can't share local variables like in C. My <SWITCH is mostly provided to support simulating a VM --- the lack of local variables isn't a big problem, because it is unlikely that the user will be simulating more than one VM simultaneously (possible though, for something like the Parallax Propeller). My <SWITCH it isn't very useful for the kind of things that CASE is used for, because it creates a stand-alone colon-word rather than generate code inside of a colon word --- the same criticism however, can be made of using a series of IF ... END in a stand-alone colon-word. All in all, putting Eaker's CASE in ANS-Forth in 1994 was a big blunder --- defending CASE in 2016 is cult behavior --- these are the hallmarks of cult behavior: 1.) Continuing to defend mistakes after they have become obvious. 2.) Belief that their cult leader is always right, even as this "leading expert" becomes increasingly arrogant and nonsensical over the years. 3.) Attacking people who know better, or at least have different opinions.
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web