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 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-27 21:36 -0800 |
| Message-ID | <bd5e98ad-547a-4f55-8de9-842c58a59da4@googlegroups.com> |
| In reply to | #54429 |
On Thursday, January 26, 2017 at 9:41:57 AM UTC-7, JennyB wrote: > On Thursday, 26 January 2017 10:48:10 UTC, Gerry wrote: > > On 26/01/2017 07:56, JennyB wrote: > > > I've just realised why OF isn't necessarily just a synonym of OVER = IF (that has bugged me for years). > > > > > > CASE can compile a jump table thus: > > > > > > OF checks if the selector if a constant > > > If is is, OF ... ENDOF compiles a quotation and remembers it and the selector > > > If the selector is the same as an existing constant it is ignored (the code is unreachable) > > > > That's not necessarily true, code can be executed between an ENDOF and > > the next OF such that a selector has the same value as a previous selector. > > > > Yes, that's another case of Otherwise. > > > > > > > Otherwise or at ENDCASE > > > It checks for existing selector/quotation pairs and compiles a suitable table. > > > > Jump tables only work when there is nothing but a constant between OF ... ENDOF clauses. > > The point is that Eaker's CASE can accomodate either or a mixture of both in the same structure. I'm never going to become an ANS-Forth programmer! I don't want to be obliged to spout such highly contorted argument justifying Eaker's CASE --- none of these tortured arguments are true --- CASE can't compile into jump-tables; this was a major blunder in ANS-Forth design which contributed significantly to Forth's demise. CASE was the winner of a "Forth Dimensions" contest for a CASE way back in the late 1980s. The contest rules required the code to be written in Forth-83 --- no assembly-language, and no carnal knowledge --- this prevented any of the contest entries from supporting jump-tables --- then Elizabeth Rather put CASE in ANS-Forth because it was "common practice," meaning that she needs to use somebody else's code that is already written because she can't write code herself. Jump-tables were well known in the 1970s, or at least the 1980s. The 65c02 had a JMP (adr,X) instruction that was provided to support jump-tables. They screwed up though, as they should have used Y rather than X --- because X was already used for the Forth data-stack pointer, whereas Y was always the general-purpose register --- the 65c02 could have been a lot better design than it was, and this could have killed the Intel 8088 and MS-DOS which would have been a good thing.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-17 17:06 +0000 |
| Message-ID | <2017Jan17.180642@mips.complang.tuwien.ac.at> |
| In reply to | #54066 |
Pablo Hugo Reda <pabloreda@gmail.com> writes:
>Charles Moore say in firechat (I not remember when) ColorForth not have ELS=
>E because this produce better factorization.
Looking at the code in Gforth, there are lots of cases where
ELSE...THEN is directly followed by ";". In these cases, the absence
of ELSE certainly would not result in a better factoring.
Here's one of the rare examples where an ELSE...THEN is followed by
some straight-line code and then by ";":
: same-as-in? ( item -- f )
\ f is true iff the offset and stack of item is the same as on input
>r
r@ item-stack @ stack-prim-stacks-sync @ if
rdrop false exit
endif
r@ item-first @ if
rdrop false exit
endif
r@ item-name 2@ prim prim-items-wordlist @ search-wordlist 0= abort" bug"
execute @
dup r@ =
if \ item first appeared in output
drop false
else
dup item-stack @ r@ item-stack @ =
swap item-offset @ r@ item-offset @ = and
endif
rdrop ;
I think the RDROP at the end is better than duplicating it in the
branches, resulting in
: same-as-in? ( item -- f )
\ f is true iff the offset and stack of item is the same as on input
>r
r@ item-stack @ stack-prim-stacks-sync @ if
rdrop false exit
endif
r@ item-first @ if
rdrop false exit
endif
r@ item-name 2@ prim prim-items-wordlist @ search-wordlist 0= abort" bug"
execute @
dup r@ =
if \ item first appeared in output
drop false rdrop exit
dup item-stack @ r@ item-stack @ =
swap item-offset @ r@ item-offset @ = and
rdrop ;
Here's another one:
: output-profile ( -- )
\ generate code for postprocessing the VM block profile stuff
." if (VM_IS_INST(*ip, " function-number @ 0 .r ." )) {" cr
." add_inst(b, " quote prim prim-name 2@ type quote ." );" cr
." ip += " inst-stream stack-in @ 1+ 0 .r ." ;" cr
prim prim-c-code 2@ s" SET_IP" search nip nip
prim prim-c-code 2@ s" SUPER_END" search nip nip or if
." return;" cr
else
." goto _endif_;" cr
endif
." }" cr ;
One could refactor this as follows:
: output-profile1 ( -- )
." add_inst(b, " quote prim prim-name 2@ type quote ." );" cr
." ip += " inst-stream stack-in @ 1+ 0 .r ." ;" cr
prim prim-c-code 2@ s" SET_IP" search nip nip
prim prim-c-code 2@ s" SUPER_END" search nip nip or if
." return;" cr exit then
." goto _endif_;" cr ;
: output-profile ( -- )
\ generate code for postprocessing the VM block profile stuff
." if (VM_IS_INST(*ip, " function-number @ 0 .r ." )) {" cr
output-profile1
." }" cr ;
Is this really better?
There are a number of cases where an IF...ELSE...THEN is inside
another control structure. Having to factor the IF out certainly
leads to more factoring, but I am too lazy to look closely at whether
it leads to better factoring.
--
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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-16 16:31 -1000 |
| Message-ID | <c9mdna2rjq9qHODFnZ2dnUU7-WXNnZ2d@supernews.com> |
| In reply to | #54064 |
On 1/16/17 3:17 PM, HAA wrote: > Noticing how many times I was using the sequence EXIT THEN I did some > research and discovered not surprisingly I was not alone. > > SwiftForth 227 > VFX 533 > GForth 358 > Win32Forth 359 > > Typically found in IF conditionals EXIT THEN avoids the need for ELSE and > the unnecessary jump it would otherwise compile. > > Given the frequent usage and my use of screens, I'm considering a macro > to replace EXIT THEN. I've chosen the name END. END was once a > synonym for UNTIL (FigForth & F79/83 reference words) but who even > remembers that today let alone uses it. IMO the new use for END better > befits the name. > > : END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE > > alternatively > > : END S" POSTPONE EXIT POSTPONE THEN" EVALUATE ; IMMEDIATE Other than syntactic sugar, I'm not sure what the advantage of this END would be. And, why would anyone prefer the second definition, with all its attendant perils associated with EVALUATE? Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-16 20:59 -0800 |
| Message-ID | <0f260ed2-0949-4b62-a1a5-1f075d010498@googlegroups.com> |
| In reply to | #54067 |
On Monday, January 16, 2017 at 7:31:25 PM UTC-7, Elizabeth D. Rather wrote: > On 1/16/17 3:17 PM, HAA wrote: > > Noticing how many times I was using the sequence EXIT THEN I did some > > research and discovered not surprisingly I was not alone. > > > > SwiftForth 227 > > VFX 533 > > GForth 358 > > Win32Forth 359 > > > > Typically found in IF conditionals EXIT THEN avoids the need for ELSE and > > the unnecessary jump it would otherwise compile. > > > > Given the frequent usage and my use of screens, I'm considering a macro > > to replace EXIT THEN. I've chosen the name END. END was once a > > synonym for UNTIL (FigForth & F79/83 reference words) but who even > > remembers that today let alone uses it. IMO the new use for END better > > befits the name. > > > > : END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE > > > > alternatively > > > > : END S" POSTPONE EXIT POSTPONE THEN" EVALUATE ; IMMEDIATE > > Other than syntactic sugar, I'm not sure what the advantage of this END > would be. And, why would anyone prefer the second definition, with all > its attendant perils associated with EVALUATE? There aren't any "attendant perils associated with EVALUATE" --- nobody is going to redefine POSTPONE EXIT or THEN --- you are just making a knee-jerk criticism without being realistic. This is not to say that I like either of these versions. I would do this: macro: end exit then ; This has the advantage of being short and readable.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-17 06:11 -0800 |
| Message-ID | <264d42ab-7c0b-4127-9a7a-f45f75d14034@googlegroups.com> |
| In reply to | #54069 |
On Monday, January 16, 2017 at 10:00:00 PM UTC-7, hughag...@gmail.com wrote: > On Monday, January 16, 2017 at 7:31:25 PM UTC-7, Elizabeth D. Rather wrote: > > On 1/16/17 3:17 PM, HAA wrote: > > > : END POSTPONE EXIT POSTPONE THEN ; IMMEDIATE > > > > > > alternatively > > > > > > : END S" POSTPONE EXIT POSTPONE THEN" EVALUATE ; IMMEDIATE > > > > Other than syntactic sugar, I'm not sure what the advantage of this END > > would be. And, why would anyone prefer the second definition, with all > > its attendant perils associated with EVALUATE? > > There aren't any "attendant perils associated with EVALUATE" --- nobody is going to redefine POSTPONE EXIT or THEN --- you are just making a knee-jerk criticism without being realistic. I was so annoyed by Elizabeth Rather's pseudo-intellectual criticism that I didn't even notice that the code was incorrect anyway. Here are correct versions: : end1 postpone exit postpone then ; immediate ok : end2 s" exit then" evaluate ; immediate ok : ttt1 if 5 . end1 6 . ; ok : ttt2 if 5 . end2 6 . ; ok 1 ttt1 5 ok 0 ttt1 6 ok 1 ttt2 5 ok 0 ttt2 6 ok > This is not to say that I like either of these versions. I would do this: > > macro: end exit then ; > > This has the advantage of being short and readable. This is what I will put in the novice package --- giving HAA credit, of course.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-18 10:36 +1100 |
| Message-ID | <o5m9or$1mnt$2@gioia.aioe.org> |
| In reply to | #54067 |
Elizabeth D. Rather wrote: > ... > Other than syntactic sugar, I'm not sure what the advantage of this END > would be. Apart from the sheer number of them do you mean? The advantage is conciseness and readability. In the same way Forth replaced the 'how' of AGAIN THEN with a single word REPEAT that described the effect, so can the 'how' of EXIT THEN be replaced by the single word END. Few today would call for the removal of REPEAT arguing it is technically redundant. So it would be with END. A few minutes using END is all it takes for EXIT THEN to be seen for the clumsiness it always was. EXIT THEN is at least as deserving of action as REPEAT was. In SwiftForth REPEAT occurs 213 times which is *less* than EXIT THEN. The only question is how all this has remained in plain sight for decades apparently without anybody noticing. > And, why would anyone prefer the second definition, with all > its attendant perils associated with EVALUATE? > Cheers, > Elizabeth There are trade-offs with any implementation. The first version is compact but will fail should EXIT need to change later e.g. when locals are loaded. For my usage the size outweighs the disadvantage, for others it may not.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-20 07:33 +0000 |
| Message-ID | <o5sedf$394$1@dont-email.me> |
| In reply to | #54088 |
On 17/01/2017 23:36, HAA wrote:
> Elizabeth D. Rather wrote:
>> ...
>> Other than syntactic sugar, I'm not sure what the advantage of this END
>> would be.
>
> Apart from the sheer number of them do you mean? The advantage is
> conciseness and readability. In the same way Forth replaced the 'how'
> of AGAIN THEN with a single word REPEAT that described the effect,
> so can the 'how' of EXIT THEN be replaced by the single word END.
>
> Few today would call for the removal of REPEAT arguing it is technically
> redundant. So it would be with END. A few minutes using END is all it
> takes for EXIT THEN to be seen for the clumsiness it always was.
>
Using REPEAT replacing AGAIN THEN is a poor justification for END
replacing EXIT THEN. If REPEAT hadn't been standardised a while loop
would be:
BEGIN ... WHILE ... AGAIN THEN
where there are two words to terminate a single control structure. Of
course the WHILE could be unwound to IF 1 CS-ROLL to balance things but
I doubt that anyone would advocate that.
Replacing EXIT THEN with END is bad in my view because:
- in IF ... EXIT THEN the THEN terminates a control structure and the
EXIT is doing a operation, so END is doing two completely different jobs.
- the word END is a very general term that could be used to end other
control structures and is in some Forth dialects
- END gives no indication that control leaves the enclosing colon
definition.
More concise yes, but saving a few characters of storage is irrelevant.
Readable no, not even syntactic sugar.
> EXIT THEN is at least as deserving of action as REPEAT was. In
> SwiftForth REPEAT occurs 213 times which is *less* than EXIT THEN.
> The only question is how all this has remained in plain sight for decades
> apparently without anybody noticing.
Perhaps they considered it but rejected the idea for the reasons above.
>
>> And, why would anyone prefer the second definition, with all
>> its attendant perils associated with EVALUATE?
>> Cheers,
>> Elizabeth
>
> There are trade-offs with any implementation. The first version is compact
> but will fail should EXIT need to change later e.g. when locals are loaded.
> For my usage the size outweighs the disadvantage, for others it may not.
You're free to do what you want, I don't think anyone would argue
against that. But if you post code using END don't expect others to
understand it without accompanying explanation.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-20 23:02 +1100 |
| Message-ID | <o5su75$1v83$1@gioia.aioe.org> |
| In reply to | #54194 |
Gerry Jackson wrote: > On 17/01/2017 23:36, HAA wrote: > > Elizabeth D. Rather wrote: > >> ... > >> Other than syntactic sugar, I'm not sure what the advantage of this END > >> would be. > > > > Apart from the sheer number of them do you mean? The advantage is > > conciseness and readability. In the same way Forth replaced the 'how' > > of AGAIN THEN with a single word REPEAT that described the effect, > > so can the 'how' of EXIT THEN be replaced by the single word END. > > > > Few today would call for the removal of REPEAT arguing it is technically > > redundant. So it would be with END. A few minutes using END is all it > > takes for EXIT THEN to be seen for the clumsiness it always was. > > > > Using REPEAT replacing AGAIN THEN is a poor justification for END > replacing EXIT THEN. If REPEAT hadn't been standardised a while loop > would be: > BEGIN ... WHILE ... AGAIN THEN > where there are two words to terminate a single control structure. Of > course the WHILE could be unwound to IF 1 CS-ROLL to balance things but > I doubt that anyone would advocate that. REPEAT is factor. So is END. Both hide the trailing THEN because it's clear what each of them do without it. > Replacing EXIT THEN with END is bad in my view because: > - in IF ... EXIT THEN the THEN terminates a control structure and the > EXIT is doing a operation, so END is doing two completely different jobs. > - the word END is a very general term that could be used to end other > control structures and is in some Forth dialects > - END gives no indication that control leaves the enclosing colon > definition. In reverse order: - END means end. What's so hard to understand about that? - When was last time you used END in Fig-Forth? - Take a look at the Case example I gave earlier. Replace END with EXIT THEN. Explain, if you can, what you think you gained by doing so.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-20 13:47 +0000 |
| Message-ID | <o5t4as$bl4$1@dont-email.me> |
| In reply to | #54200 |
On 20/01/2017 12:02, HAA wrote:
>> Replacing EXIT THEN with END is bad in my view because:
>> - in IF ... EXIT THEN the THEN terminates a control structure and the
>> EXIT is doing a operation, so END is doing two completely different jobs.
>> - the word END is a very general term that could be used to end other
>> control structures and is in some Forth dialects
>> - END gives no indication that control leaves the enclosing colon
>> definition.
> In reverse order:
>
> - END means end. What's so hard to understand about that?
Nothing, but END of what, the IF? the definition? both? an enclosing
loop? the program? It's ambiguous to a reader unless they habitually use
END themselves when, of course, as it's non-standard they may attach a
totally different meaning to it. I would naturally think it ended the
previous control structure only - the IF.
> - When was last time you used END in Fig-Forth?
I've never used Fig Forth, why would I do so now it's obsolete and a
good thing too? My introduction to Forth was Forth 79.
> - Take a look at the Case example I gave earlier. Replace END with
> EXIT THEN. Explain, if you can, what you think you gained by doing so.
You mean this code:
<quote>
: end-of-line? ( char -- 2|1|0 )
$0D of 2 end
$0A of 1 end
drop 0 ;
</quote>
It's non-standard so why should I explain anything about it? As a
believer in a standard I wouldn't write it like that.
You're free to do what you want with your own system and programs, I
don't care and wouldn't say you must not do that. I don't understand why
you and the other standard Forth haters persist in continually attacking
the ANS/2012 Forth standards, why not just ignore it. Collectively
you've all made your points, carrying on griping and sniping about the
standard is tedious and will lead to your posts being ignored. Certainly
there are many things wrong with the standard but it's much better than
no standard. Elsewhere you've made a point about Ciforth being obscure -
that's what non-adherence to a standard leads to - mutual incomprehension.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-20 18:55 -0800 |
| Message-ID | <fd063455-92d7-4f19-907c-0b0e2ecb877f@googlegroups.com> |
| In reply to | #54202 |
On Friday, January 20, 2017 at 6:47:45 AM UTC-7, Gerry wrote:
> On 20/01/2017 12:02, HAA wrote:
> >> Replacing EXIT THEN with END is bad in my view because:
> >> - in IF ... EXIT THEN the THEN terminates a control structure and the
> >> EXIT is doing a operation, so END is doing two completely different jobs.
> >> - the word END is a very general term that could be used to end other
> >> control structures and is in some Forth dialects
> >> - END gives no indication that control leaves the enclosing colon
> >> definition.
I mostly agree with this --- I'm not planning on using END myself --- I have put END in the novice-package though, as doing so was the work of about 20 seconds and it might get some use (from HAA if nobody else).
> > - Take a look at the Case example I gave earlier. Replace END with
> > EXIT THEN. Explain, if you can, what you think you gained by doing so.
>
> You mean this code:
> <quote>
> : end-of-line? ( char -- 2|1|0 )
> $0D of 2 end
> $0A of 1 end
> drop 0 ;
> </quote>
>
> It's non-standard so why should I explain anything about it? As a
> believer in a standard I wouldn't write it like that.
Gerry is talking nonsense when he says that END is "non-standard" --- END is define with MACRO: which is ANS-Forth compliant:
macro: end exit then ;
Also, END can be defined with raw ANS-Forth like this:
: end
postpone exit
postpone then
; immediate
> You're free to do what you want with your own system and programs, I
> don't care and wouldn't say you must not do that. I don't understand why
> you and the other standard Forth haters persist in continually attacking
> the ANS/2012 Forth standards, why not just ignore it. Collectively
> you've all made your points, carrying on griping and sniping about the
> standard is tedious and will lead to your posts being ignored. Certainly
> there are many things wrong with the standard but it's much better than
> no standard. Elsewhere you've made a point about Ciforth being obscure -
> that's what non-adherence to a standard leads to - mutual incomprehension.
Elizabeth Rather's only programming experience is in COBOL --- one of the worst crimes that she has committed is to force a COBOL-type outlook on the Forth community.
Here we have Gerry accusing HAA of being a "standard Forth hater" and saying that his use of END will "lead to your posts being ignored." These are strong words --- also idiotic --- END is trivial to write in standard ANS-Forth.
How is HAA's END any different from my SORT in the novice-package? Both are trivial extensions of ANS-Forth. Does Gerry expect all ANS-Forth programs to be written in raw ANS-Forth without any help from any code-library whatsoever? This is what Elizabeth Rather demands --- this is the same as in COBOL in which all programs were written in raw COBOL without any help from any code-library whatsoever --- this was done in COBOL because the stated goal was that the programs would be readable by non-programmers (mostly business majors) who have learned raw COBOL but who haven't learned about any extensions (called "subroutines").
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-22 09:15 +0000 |
| Message-ID | <o61t4a$vg4$1@dont-email.me> |
| In reply to | #54215 |
On 21/01/2017 02:55, hughaguilar96@gmail.com wrote: > On Friday, January 20, 2017 at 6:47:45 AM UTC-7, Gerry wrote: >> On 20/01/2017 12:02, HAA wrote: >>>> Replacing EXIT THEN with END is bad in my view because: >>>> - in IF ... EXIT THEN the THEN terminates a control structure and the >>>> EXIT is doing a operation, so END is doing two completely different jobs. >>>> - the word END is a very general term that could be used to end other >>>> control structures and is in some Forth dialects >>>> - END gives no indication that control leaves the enclosing colon >>>> definition. > > I mostly agree with this --- I'm not planning on using END myself --- I have put END in the novice-package though, as doing so was the work of about 20 seconds and it might get some use (from HAA if nobody else). > >>> - Take a look at the Case example I gave earlier. Replace END with >>> EXIT THEN. Explain, if you can, what you think you gained by doing so. >> >> You mean this code: >> <quote> >> : end-of-line? ( char -- 2|1|0 ) >> $0D of 2 end >> $0A of 1 end >> drop 0 ; >> </quote> >> >> It's non-standard so why should I explain anything about it? As a >> believer in a standard I wouldn't write it like that. > > Gerry is talking nonsense when he says that END is "non-standard" I don't think so. That code was presented in isolation. Without redefining OF it may not compile in a standard Forth system (e.g. VFX Forth, Win32 Forth) because of a mismatched control structure. To my surprise it does work in GForth and SwiftForth but that doesn't make it standard usage - it just shows that they accept non-standard code and are a bit lacking in control structure checks. --- END is define with MACRO: which is ANS-Forth compliant: > > macro: end exit then ; > > Also, END can be defined with raw ANS-Forth like this: > > : end > postpone exit > postpone then > ; immediate > Tell us something we didn't know already >> You're free to do what you want with your own system and programs, I >> don't care and wouldn't say you must not do that. I don't understand why >> you and the other standard Forth haters persist in continually attacking >> the ANS/2012 Forth standards, why not just ignore it. Collectively >> you've all made your points, carrying on griping and sniping about the >> standard is tedious and will lead to your posts being ignored. Certainly >> there are many things wrong with the standard but it's much better than >> no standard. Elsewhere you've made a point about Ciforth being obscure - >> that's what non-adherence to a standard leads to - mutual incomprehension. > > Elizabeth Rather's only programming experience is in COBOL --- one of > the worst crimes that she has committed is to force a COBOL-type outlook > on the Forth community. What's this got do with the current discussion - keep to the point. > Here we have Gerry accusing HAA of being a "standard Forth hater" and > saying that his use of END will "lead to your posts being ignored." > These are strong words --- also idiotic --- END is trivial to write > in standard ANS-Forth. Don't you ever read a post properly? Or do you just take in a sample of words from a sentence and then enter attack mode, inventing things people didn't write? I wrote "carrying on griping and sniping about the standard is tedious and will lead to your posts being ignored". I suspect you've already achieved that status with many people. > > How is HAA's END any different from my SORT in the novice-package? Well END is truly trivial, SORT isn't. END is technically bad, ambiguous and a waste of time. Its only advantage, saving 6 characters is trivial. > Both are trivial extensions of ANS-Forth. Does Gerry expect all > ANS-Forth programs to be written in raw ANS-Forth without any help > from any code-library whatsoever? No and why do you think I did - you're inventing stuff again? > This is what Elizabeth Rather > demands --- this is the same as in COBOL in which all programs > were written in raw COBOL without any help from any code-library > whatsoever --- this was done in COBOL because the stated goal was > that the programs would be readable by non-programmers (mostly > business majors) who have learned raw COBOL but who haven't learned > about any extensions (called "subroutines"). > I don't understand why you waste your time writing crap like this, nobody reads it, you'd be better off spending your time getting on with Straight Forth - or even finding a garage with some screws that need sorting :) -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-22 14:30 -0800 |
| Message-ID | <d741c5a1-7626-45de-bb8d-6804b0898751@googlegroups.com> |
| In reply to | #54240 |
On Sunday, January 22, 2017 at 2:15:27 AM UTC-7, Gerry wrote: > On 21/01/2017 02:55, hughaguilar96@gmail.com wrote: > > On Friday, January 20, 2017 at 6:47:45 AM UTC-7, Gerry wrote: > >> You mean this code: > >> <quote> > >> : end-of-line? ( char -- 2|1|0 ) > >> $0D of 2 end > >> $0A of 1 end > >> drop 0 ; > >> </quote> > >> > >> It's non-standard so why should I explain anything about it? As a > >> believer in a standard I wouldn't write it like that. > > > > Gerry is talking nonsense when he says that END is "non-standard" > > I don't think so. That code was presented in isolation. Without > redefining OF it may not compile in a standard Forth system (e.g. VFX > Forth, Win32 Forth) because of a mismatched control structure. To my > surprise it does work in GForth and SwiftForth but that doesn't make it > standard usage - it just shows that they accept non-standard code and > are a bit lacking in control structure checks. I didn't notice that the code had OF rather than IF inside of it. I agree that using OF outside of a CASE is non-standard. Maybe that was a typo originally when Wil Baden wrote it, and it was supposed to be IF which makes sense. > > Elizabeth Rather's only programming experience is in COBOL --- one of > > the worst crimes that she has committed is to force a COBOL-type outlook > > on the Forth community. > > What's this got do with the current discussion - keep to the point. All of you seem to be attacking END because it will make the code unreadable, because people don't know what it is and will assume that it is non-standard --- this is no different than saying that SORT should be banned because it it not in the ANS-Forth standard and nobody knows what it is and nobody has the time to look it up in whatever code-library it came from --- in my first-ever ANS-Forth program (LowDraw.4th) I hand-coded a bubble-sort because there was no SORT function available and I didn't have time to write a general-purpose SORT myself (because I was in the middle of writing LowDraw.4th and didn't want to be distracted). This is very similar to the stated goal of COBOL that programs would be readable because they only contained raw COBOL code --- they didn't contain any code that was located in a code-library somewhere and which the reader of the source-code would not be familiar with. > > Here we have Gerry accusing HAA of being a "standard Forth hater" and > > saying that his use of END will "lead to your posts being ignored." > > These are strong words --- also idiotic --- END is trivial to write > > in standard ANS-Forth. > > Don't you ever read a post properly? Or do you just take in a sample of > words from a sentence and then enter attack mode, inventing things > people didn't write? I wrote "carrying on griping and sniping about the > standard is tedious and will lead to your posts being ignored". I > suspect you've already achieved that status with many people. ANS-Forth has achieved that status with the entire world! Ever since ANS-Forth became the standard in 1994, Forth has been totally ignored by the programming world. When I tell programmers that I'm a Forth programmer, they almost always assume that I misspelled "Fortran" --- programmers go all the way through college and well into their careers without having ever heard of Forth --- Studebaker is more well known than Forth. Studebaker made most of the covered wagons that were used by settlers heading west in the late 19th century gold rush --- after cars were invented in the early 20th century, Studebaker failed to compete against Ford Motors etc. --- this is similar to how, after personal computers were invented, ANS-Forth failed to compete against C etc.. > > How is HAA's END any different from my SORT in the novice-package? > > Well END is truly trivial, SORT isn't. END is technically bad, ambiguous > and a waste of time. Its only advantage, saving 6 characters is trivial. CASE is technically bad and a waste of time. I don't know why you say that END is ambiguous, because it isn't. CASE is ambiguous though because it allows redundant test values, so it is not clear which one is supposed to be found (in practice, it is the first one). The history on CASE is that, sometime in the late 1980s, "Forth Dimensions" had a contest for a CASE statement. This CASE that is now in ANS-Forth was the winner. The rules of the contest however, required that the code be written in standard Forth-83. This is why CASE OF ENDOF and ENDCASE are just macros that produce nested IF ELSE THEN statements. This was just a toy! Nobody expected this to become part of standard Forth! I don't have a SWITCH that compiles into a jump-table, because everything in the novice-package is ANS-Forth --- I don't know how to implement this without resorting to assembly-language --- if I knew how, I would do so, as this would be hugely useful. When the standard was being designed, an obvious goal would have been to provide Forth with features comparable to C, as C was the main competition. C has a SWITCH statement that compiles into a jump-table and is very efficient. Forth needed this to be competitive. Instead we got CASE which is defined in such a way (the standard case allows redundancy in the case values) that it has to be implemented as nested IF ELSE THEN statements --- that is utterly useless! Most likely, Elizabeth Rather doesn't know C and also doesn't know what a jump-table is. She really doesn't know any more about programming than a typical marketing genius (a.k.a.: sales-idiot). She just put this toy CASE construct in ANS-Forth because it was supposedly "common practice" --- it was common practice because it could be written in Forth-83 --- but a SWITCH that compiles a jump-table would have to be written in assembly-language. Lots of people had written a SWITCH that compiled into a jump-table, but none of their efforts were Forth-83 because all of them were written in assembly-language, and so Elizabeth Rather ignored all of them. Testra had done this, and they used it extensively in their machine-code simulators (the test values were opcodes) --- I didn't use it though, when I wrote the MiniForth simulator in MFX (I almost never use other people's code, because I expect my own to be better, and it generally is). I almost never use CASE --- I typically just factor out the control-structure into a function of its own, then I use IF ... EXIT THEN for each case (I could use IF ... END though for better readability, at least according to HAA) --- this has the advantage that the conditional test can be something other than comparing two integers (for example, comparing two strings or two floats) --- this doesn't work though, when the code uses locals because a sub-function can't access them. > > This is what Elizabeth Rather > > demands --- this is the same as in COBOL in which all programs > > were written in raw COBOL without any help from any code-library > > whatsoever --- this was done in COBOL because the stated goal was > > that the programs would be readable by non-programmers (mostly > > business majors) who have learned raw COBOL but who haven't learned > > about any extensions (called "subroutines"). > > I don't understand why you waste your time writing crap like this, > nobody reads it, you'd be better off spending your time getting on with > Straight Forth - or even finding a garage with some screws that need > sorting :) I don't understand why you waste your time defending crap like ANS-Forth. Nobody uses ANS-Forth --- you'd be better off spending your time helping me with Straight Forth --- or just become a COBOL programmer, as there is some employment opportunities still available for COBOL, which is not true of ANS-Forth. ANS-Forth is total crap!!! Just press the flush lever --- I think the ANS-Forth enthusiasts can't admit a mistake and so they continue to defend ANS-Forth decades after it became obvious that it was a mistake --- this is very similar to a bad poker player who continues betting on his pocket tens after the flop comes all faces and aces and the opponents have begun betting and raising.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-22 20:58 -0500 |
| Message-ID | <o63ntb$gg6$1@dont-email.me> |
| In reply to | #54255 |
On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: > On Sunday, January 22, 2017 at 2:15:27 AM UTC-7, Gerry wrote: >> On 21/01/2017 02:55, hughaguilar96@gmail.com wrote: >>> On Friday, January 20, 2017 at 6:47:45 AM UTC-7, Gerry wrote: >>>> You mean this code: <quote> : end-of-line? ( char -- 2|1|0 ) >>>> $0D of 2 end $0A of 1 end drop 0 ; </quote> >>>> >>>> It's non-standard so why should I explain anything about it? As >>>> a believer in a standard I wouldn't write it like that. >>> >>> Gerry is talking nonsense when he says that END is >>> "non-standard" >> >> I don't think so. That code was presented in isolation. Without >> redefining OF it may not compile in a standard Forth system (e.g. >> VFX Forth, Win32 Forth) because of a mismatched control structure. >> To my surprise it does work in GForth and SwiftForth but that >> doesn't make it standard usage - it just shows that they accept >> non-standard code and are a bit lacking in control structure >> checks. > > I didn't notice that the code had OF rather than IF inside of it. I > agree that using OF outside of a CASE is non-standard. Maybe that was > a typo originally when Wil Baden wrote it, and it was supposed to be > IF which makes sense. IF wouldn't work unless it were preceded by OVER =. OF is exactly the correct word to use. This is simply a CASE statement that exits the word at the end of each case rather than jumping to the end of the structure. Yes, it is more streamlined in terms of typing and potentially executed code (assuming the proper CASE statement isn't optimized), but it comes at the cost of being an uncommon structure that is not at all clear to anyone who hasn't used it. > All of you seem to be attacking END because it will make the code > unreadable, because people don't know what it is and will assume that > it is non-standard --- this is no different than saying that SORT > should be banned because it it not in the ANS-Forth standard and > nobody knows what it is and nobody has the time to look it up in > whatever code-library it came from --- in my first-ever ANS-Forth > program (LowDraw.4th) I hand-coded a bubble-sort because there was no > SORT function available and I didn't have time to write a > general-purpose SORT myself (because I was in the middle of writing > LowDraw.4th and didn't want to be distracted). I don't know why you need to use words like "attack". We are discussing the pros and cons of an idea. There is nothing personal about this. I think people are saying it should not be added to the standard because it is superfluous and not particularly beneficial. >>> How is HAA's END any different from my SORT in the >>> novice-package? >> >> Well END is truly trivial, SORT isn't. END is technically bad, >> ambiguous and a waste of time. Its only advantage, saving 6 >> characters is trivial. > > CASE is technically bad and a waste of time. I don't know why you say > that END is ambiguous, because it isn't. CASE is ambiguous though > because it allows redundant test values, so it is not clear which one > is supposed to be found (in practice, it is the first one). I don't understand what you are saying. Are you suggesting you can use the same test value more than once and the result is not fully specified in the standard? CASE 1 OF stuff ENDOF 1 OF other stuff ENDOF ENDCASE So it is not specified if stuff or other stuff would be executed? Why is this a problem? Why would anyone want to write this code? How could it be used usefully? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-23 10:47 +0000 |
| Message-ID | <o64mt5$fj4$1@dont-email.me> |
| In reply to | #54262 |
On 23/01/2017 01:58, rickman wrote:
> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote:
>> CASE is technically bad and a waste of time. I don't know why you say
>> that END is ambiguous, because it isn't. CASE is ambiguous though
>> because it allows redundant test values, so it is not clear which one
>> is supposed to be found (in practice, it is the first one).
>
> I don't understand what you are saying. Are you suggesting you can use
> the same test value more than once and the result is not fully specified
> in the standard?
>
> CASE
> 1 OF stuff ENDOF
> 1 OF other stuff ENDOF
> ENDCASE
>
> So it is not specified if stuff or other stuff would be executed? Why
> is this a problem? Why would anyone want to write this code? How could
> it be used usefully?
>
Code can be executed before the OF constant that result in the same
value for different OFs e.g.
case
code-sequence-1 3 of stuff-1 endof
code-sequence-2 3 of stuff-2 endof
...
code-sequence-n 3 of stuff-n endof
endcase
The standard allows this.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 06:20 -0500 |
| Message-ID | <o64ora$n3u$2@dont-email.me> |
| In reply to | #54290 |
On 1/23/2017 5:47 AM, Gerry Jackson wrote: > On 23/01/2017 01:58, rickman wrote: >> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: > >>> CASE is technically bad and a waste of time. I don't know why you say >>> that END is ambiguous, because it isn't. CASE is ambiguous though >>> because it allows redundant test values, so it is not clear which one >>> is supposed to be found (in practice, it is the first one). >> >> I don't understand what you are saying. Are you suggesting you can use >> the same test value more than once and the result is not fully specified >> in the standard? >> >> CASE >> 1 OF stuff ENDOF >> 1 OF other stuff ENDOF >> ENDCASE >> >> So it is not specified if stuff or other stuff would be executed? Why >> is this a problem? Why would anyone want to write this code? How could >> it be used usefully? >> > > Code can be executed before the OF constant that result in the same > value for different OFs e.g. > > case > code-sequence-1 3 of stuff-1 endof > code-sequence-2 3 of stuff-2 endof > ... > code-sequence-n 3 of stuff-n endof > endcase > > The standard allows this. So the "code-sequence-x" would be operating on the value of the case selector? What is the value in that? Once you OF finds a match, the ENDOF continues at ENDCASE and the rest of the cases are skipped, no? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-23 13:09 +0000 |
| Message-ID | <o64v7e$hco$1@dont-email.me> |
| In reply to | #54294 |
On 23/01/2017 11:20, rickman wrote: > On 1/23/2017 5:47 AM, Gerry Jackson wrote: >> On 23/01/2017 01:58, rickman wrote: >>> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: >> >>>> CASE is technically bad and a waste of time. I don't know why you say >>>> that END is ambiguous, because it isn't. CASE is ambiguous though >>>> because it allows redundant test values, so it is not clear which one >>>> is supposed to be found (in practice, it is the first one). >>> >>> I don't understand what you are saying. Are you suggesting you can use >>> the same test value more than once and the result is not fully specified >>> in the standard? >>> >>> CASE >>> 1 OF stuff ENDOF >>> 1 OF other stuff ENDOF >>> ENDCASE >>> >>> So it is not specified if stuff or other stuff would be executed? Why >>> is this a problem? Why would anyone want to write this code? How could >>> it be used usefully? >>> >> >> Code can be executed before the OF constant that result in the same >> value for different OFs e.g. >> >> case >> code-sequence-1 3 of stuff-1 endof >> code-sequence-2 3 of stuff-2 endof >> ... >> code-sequence-n 3 of stuff-n endof >> endcase >> >> The standard allows this. > > So the "code-sequence-x" would be operating on the value of the case > selector? What is the value in that? Once you OF finds a match, the > ENDOF continues at ENDCASE and the rest of the cases are skipped, no? > Yes, the first code-sequence returning 3 will have its stuff run and the case statement exited. The programmer wouldn't write it like that if he didn't want that to happen. I'm not giving a use for it but the compiler has to be able to handle it. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 14:41 -0500 |
| Message-ID | <o65m5v$asp$3@dont-email.me> |
| In reply to | #54301 |
On 1/23/2017 8:09 AM, Gerry Jackson wrote: > On 23/01/2017 11:20, rickman wrote: >> On 1/23/2017 5:47 AM, Gerry Jackson wrote: >>> On 23/01/2017 01:58, rickman wrote: >>>> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: >>> >>>>> CASE is technically bad and a waste of time. I don't know why you say >>>>> that END is ambiguous, because it isn't. CASE is ambiguous though >>>>> because it allows redundant test values, so it is not clear which one >>>>> is supposed to be found (in practice, it is the first one). >>>> >>>> I don't understand what you are saying. Are you suggesting you can use >>>> the same test value more than once and the result is not fully >>>> specified >>>> in the standard? >>>> >>>> CASE >>>> 1 OF stuff ENDOF >>>> 1 OF other stuff ENDOF >>>> ENDCASE >>>> >>>> So it is not specified if stuff or other stuff would be executed? Why >>>> is this a problem? Why would anyone want to write this code? How >>>> could >>>> it be used usefully? >>>> >>> >>> Code can be executed before the OF constant that result in the same >>> value for different OFs e.g. >>> >>> case >>> code-sequence-1 3 of stuff-1 endof >>> code-sequence-2 3 of stuff-2 endof >>> ... >>> code-sequence-n 3 of stuff-n endof >>> endcase >>> >>> The standard allows this. >> >> So the "code-sequence-x" would be operating on the value of the case >> selector? What is the value in that? Once you OF finds a match, the >> ENDOF continues at ENDCASE and the rest of the cases are skipped, no? >> > > Yes, the first code-sequence returning 3 will have its stuff run and the > case statement exited. The programmer wouldn't write it like that if he > didn't want that to happen. I'm not giving a use for it but the compiler > has to be able to handle it. Yeah, what compiler can't handle it? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-23 20:52 +0000 |
| Message-ID | <o65qbm$sjn$1@dont-email.me> |
| In reply to | #54314 |
On 23/01/2017 19:41, rickman wrote: > On 1/23/2017 8:09 AM, Gerry Jackson wrote: >> On 23/01/2017 11:20, rickman wrote: >>> On 1/23/2017 5:47 AM, Gerry Jackson wrote: >>>> On 23/01/2017 01:58, rickman wrote: >>>>> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: >>>> >>>>>> CASE is technically bad and a waste of time. I don't know why you say >>>>>> that END is ambiguous, because it isn't. CASE is ambiguous though >>>>>> because it allows redundant test values, so it is not clear which one >>>>>> is supposed to be found (in practice, it is the first one). >>>>> >>>>> I don't understand what you are saying. Are you suggesting you can >>>>> use >>>>> the same test value more than once and the result is not fully >>>>> specified >>>>> in the standard? >>>>> >>>>> CASE >>>>> 1 OF stuff ENDOF >>>>> 1 OF other stuff ENDOF >>>>> ENDCASE >>>>> >>>>> So it is not specified if stuff or other stuff would be executed? Why >>>>> is this a problem? Why would anyone want to write this code? How >>>>> could >>>>> it be used usefully? >>>>> >>>> >>>> Code can be executed before the OF constant that result in the same >>>> value for different OFs e.g. >>>> >>>> case >>>> code-sequence-1 3 of stuff-1 endof >>>> code-sequence-2 3 of stuff-2 endof >>>> ... >>>> code-sequence-n 3 of stuff-n endof >>>> endcase >>>> >>>> The standard allows this. >>> >>> So the "code-sequence-x" would be operating on the value of the case >>> selector? What is the value in that? Once you OF finds a match, the >>> ENDOF continues at ENDCASE and the rest of the cases are skipped, no? >>> >> >> Yes, the first code-sequence returning 3 will have its stuff run and the >> case statement exited. The programmer wouldn't write it like that if he >> didn't want that to happen. I'm not giving a use for it but the compiler >> has to be able to handle it. > > Yeah, what compiler can't handle it? > Don't know, why don't you find out. I merely answered the first question you asked which was: >>>>> CASE >>>>> 1 OF stuff ENDOF >>>>> 1 OF other stuff ENDOF >>>>> ENDCASE >>>>> >>>>> So it is not specified if stuff or other stuff would be executed? Why >>>>> is this a problem? Why would anyone want to write this code? How >>>>> could >>>>> it be used usefully? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 16:21 -0500 |
| Message-ID | <o65s1v$3ve$1@dont-email.me> |
| In reply to | #54320 |
On 1/23/2017 3:52 PM, Gerry Jackson wrote: > On 23/01/2017 19:41, rickman wrote: >> On 1/23/2017 8:09 AM, Gerry Jackson wrote: >>> On 23/01/2017 11:20, rickman wrote: >>>> On 1/23/2017 5:47 AM, Gerry Jackson wrote: >>>>> On 23/01/2017 01:58, rickman wrote: >>>>>> On 1/22/2017 5:30 PM, hughaguilar96@gmail.com wrote: >>>>> >>>>>>> CASE is technically bad and a waste of time. I don't know why you >>>>>>> say >>>>>>> that END is ambiguous, because it isn't. CASE is ambiguous though >>>>>>> because it allows redundant test values, so it is not clear which >>>>>>> one >>>>>>> is supposed to be found (in practice, it is the first one). >>>>>> >>>>>> I don't understand what you are saying. Are you suggesting you can >>>>>> use >>>>>> the same test value more than once and the result is not fully >>>>>> specified >>>>>> in the standard? >>>>>> >>>>>> CASE >>>>>> 1 OF stuff ENDOF >>>>>> 1 OF other stuff ENDOF >>>>>> ENDCASE >>>>>> >>>>>> So it is not specified if stuff or other stuff would be executed? >>>>>> Why >>>>>> is this a problem? Why would anyone want to write this code? How >>>>>> could >>>>>> it be used usefully? >>>>>> >>>>> >>>>> Code can be executed before the OF constant that result in the same >>>>> value for different OFs e.g. >>>>> >>>>> case >>>>> code-sequence-1 3 of stuff-1 endof >>>>> code-sequence-2 3 of stuff-2 endof >>>>> ... >>>>> code-sequence-n 3 of stuff-n endof >>>>> endcase >>>>> >>>>> The standard allows this. >>>> >>>> So the "code-sequence-x" would be operating on the value of the case >>>> selector? What is the value in that? Once you OF finds a match, the >>>> ENDOF continues at ENDCASE and the rest of the cases are skipped, no? >>>> >>> >>> Yes, the first code-sequence returning 3 will have its stuff run and the >>> case statement exited. The programmer wouldn't write it like that if he >>> didn't want that to happen. I'm not giving a use for it but the compiler >>> has to be able to handle it. >> >> Yeah, what compiler can't handle it? >> > > Don't know, why don't you find out. I merely answered the first question > you asked which was: > >>>>>> CASE >>>>>> 1 OF stuff ENDOF >>>>>> 1 OF other stuff ENDOF >>>>>> ENDCASE >>>>>> >>>>>> So it is not specified if stuff or other stuff would be executed? > Why >>>>>> is this a problem? Why would anyone want to write this code? How >>>>>> could >>>>>> it be used usefully? Ok, but you sort of failed the "usefully" part. I also don't see any "problem". I don't see an answer to the "why" part. So what was the question and what was the answer again? You say a compiler would have to "handle" the code you wrote, but I don't see anything addressing my first question, "it is not specified"??? I think the definitions of OF and ENDOF are clear enough that the action in your example is fully specified. Am I missing something? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-24 06:55 +0000 |
| Message-ID | <o66tmo$qv3$1@dont-email.me> |
| In reply to | #54323 |
On 23/01/2017 21:21, rickman wrote: >>> Yeah, what compiler can't handle it? >>> >> >> Don't know, why don't you find out. I merely answered the first question >> you asked which was: >> >>>>>>> CASE >>>>>>> 1 OF stuff ENDOF >>>>>>> 1 OF other stuff ENDOF >>>>>>> ENDCASE >>>>>>> >>>>>>> So it is not specified if stuff or other stuff would be executed? >> Why >>>>>>> is this a problem? Why would anyone want to write this code? How >>>>>>> could >>>>>>> it be used usefully? > > Ok, but you sort of failed the "usefully" part. I didn't realise I was on trial, oh well failed again > I also don't see any > "problem". Then why did you start all this and why continue? > I don't see an answer to the "why" part. No, any answer will be met with a chorus of "don't do it like that"s so I can't be bothered as I have no wish to defend it. Try using your imagination. > > So what was the question and what was the answer again? You say a > compiler would have to "handle" the code you wrote, but I don't see > anything addressing my first question, "it is not specified"??? I think > the definitions of OF and ENDOF are clear enough that the action in your > example is fully specified. Am I missing something? I think the specification are OK. An implementer has to realise that the integers (not necessarily constants) presented to different OFs can be the same as it doesn't seem to be stated explicitly. -- Gerry
[toc] | [prev] | [next] | [standalone]
Page 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web