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 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-24 03:56 -0500 |
| Message-ID | <o674ov$en7$2@dont-email.me> |
| In reply to | #54338 |
On 1/24/2017 1:55 AM, Gerry Jackson wrote: > 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. Was there some point to this discussion? You don't seem to be interested in anything I have to say. You provide a pointless piece of code and talk about how it must be supported while no one would have any reason to write it. What is all this about? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-24 09:46 +0000 |
| Message-ID | <o677li$o2k$1@dont-email.me> |
| In reply to | #54340 |
On 24/01/2017 08:56, rickman wrote: > On 1/24/2017 1:55 AM, Gerry Jackson wrote: >> 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. > > Was there some point to this discussion? Evidently not. Not so much a discussion as answering a seemingly infinite sequence of questions from you. > You don't seem to be > interested in anything I have to say. It's heading that way. > You provide a pointless piece of > code and talk about how it must be supported while no one would have any > reason to write it. I answered your original question. > > What is all this about? See what I mean. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-22 22:38 -0500 |
| Message-ID | <o63tos$rah$1@dont-email.me> |
| In reply to | #54255 |
On 1/22/2017 17:30, hughaguilar96@gmail.com wrote: > 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. I would very much like to see the source of this statement. COBOL 74 has a CALL statement to pass control to an external library routine. I'll let you guess the year this was standardised. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-23 15:09 +1100 |
| Message-ID | <o63vjl$nn4$1@gioia.aioe.org> |
| In reply to | #54202 |
Gerry Jackson 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. > > 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. END is whatever you declare it to be, preferably something appropriate. Your criticism could apply to many Forth words. COUNT is notorious for its ambiguity - yet you understand what it is not. > > - 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. So we can assume your second objection is eliminated. > > - 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. I believe in reason over standards. Why use ENDOF when EXIT will do? The point of my question, which you avoided, is that EXIT is not always preceded by an IF. END gets away from the notion that it must. Any preceding conditional that has a built-in IF will do, including OF.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-23 10:16 +0000 |
| Message-ID | <o64l3b$97h$1@dont-email.me> |
| In reply to | #54268 |
On 23/01/2017 04:09, HAA wrote: > Gerry Jackson 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. >>> 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. > > END is whatever you declare it to be, preferably something appropriate. Well, as the definition of END may not be readily available, the problem is that people may have different interpretations of what END does. > Your criticism could apply to many Forth words. COUNT is notorious for > its ambiguity - yet you understand what it is not. COUNT is ambiguous? In my ignorance I didn't know that, please enlighten me. I know it can be mis-used to step through a byte array when 1 CHARS = 1 but that doesn't make it ambiguous. > >>> - 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. > > So we can assume your second objection is eliminated. No, I don't think that follows - but you'll assume what you want. I remember seeing one Forth where END was heavily overloaded as a terminating word for all control structures - I doubt if the author of that Forth would agree with you. > >>> - 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. > > I believe in reason over standards. Why use ENDOF when EXIT will do? > The point of my question, which you avoided, is that EXIT is not always > preceded by an IF. END gets away from the notion that it must. Any > preceding conditional that has a built-in IF will do, including OF. > But with a given Forth system you cannot guarantee that OF has a "built-in IF". Suppose I use your end-of-line? example and I'm using GForth - it works so you're correct, I try it on SwiftForth and it still works. Suppose I am so impressed that I use something similar in several places in an application I'm developing and make the application available on the internet. Someone downloads it and wants it to run on VFX Forth or Win32 Forth and the application fails to even compile. Result, a lot of hassle for me and the user, that application gets a bad name, I acquire a bad reputation, some people will unfairly blame VFX Forth and Win32 Forth for not compiling non-standard code. Consider the alternative. From the start I rigidly keep to the ANS Forth standard, avoiding all the pitfalls I know about, I test it on all standard systems I can get hold of. Result my application works for everybody, no hassle, a usable tool etc. Sorry but your approach is just for lone wolf amateurs/hobbyists which is perfectly OK if that's all you aspire to. Supporting a standard doesn't mean opposing change e.g. witness the proposals for quotations and recognisers from supporters of the standard and the violent objections from some who hate the standard. Regarding your belief in reason over standards - anyone can use your END to replace EXIT THEN if they wish, provided they define it first. Furthermore if they then wish to use the construct OF ... END they can easily redefine OF to do that using standard code and it will run on a standard system. e.g. : of postpone over postpone = postpone if postpone drop ; immediate -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 05:53 -0500 |
| Message-ID | <o64n8v$hj1$1@dont-email.me> |
| In reply to | #54287 |
On 1/23/2017 5:16 AM, Gerry Jackson wrote: > On 23/01/2017 04:09, HAA wrote: >> Gerry Jackson 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. >>>> 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. >> >> END is whatever you declare it to be, preferably something appropriate. > > Well, as the definition of END may not be readily available, the problem > is that people may have different interpretations of what END does. > >> Your criticism could apply to many Forth words. COUNT is notorious for >> its ambiguity - yet you understand what it is not. > > COUNT is ambiguous? In my ignorance I didn't know that, please enlighten > me. I know it can be mis-used to step through a byte array when 1 CHARS > = 1 but that doesn't make it ambiguous. > >> >>>> - 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. >> >> So we can assume your second objection is eliminated. > > No, I don't think that follows - but you'll assume what you want. I > remember seeing one Forth where END was heavily overloaded as a > terminating word for all control structures - I doubt if the author of > that Forth would agree with you. > >> >>>> - 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. >> >> I believe in reason over standards. Why use ENDOF when EXIT will do? >> The point of my question, which you avoided, is that EXIT is not always >> preceded by an IF. END gets away from the notion that it must. Any >> preceding conditional that has a built-in IF will do, including OF. >> > > But with a given Forth system you cannot guarantee that OF has a > "built-in IF". Suppose I use your end-of-line? example and I'm using > GForth - it works so you're correct, I try it on SwiftForth and it still > works. Suppose I am so impressed that I use something similar in several > places in an application I'm developing and make the application > available on the internet. Someone downloads it and wants it to run on > VFX Forth or Win32 Forth and the application fails to even compile. > Result, a lot of hassle for me and the user, that application gets a bad > name, I acquire a bad reputation, some people will unfairly blame VFX > Forth and Win32 Forth for not compiling non-standard code. I'm not sure why you are saying OF doesn't have a "built in IF". Looking at the two definitions the only difference is that OF compares the two two items on the stack removing the top one while IF just checks the top item for being zero. In other words OF is just OVER = IF. Why would that fail? BTW, neither definition of IF or OF require the terminating word to be a particular one. IF - The semantics are incomplete until orig is resolved, e.g., by THEN or ELSE. OF - The semantics are incomplete until resolved by a consumer of of-sys such as ENDOF They are clearly leaving room for something other than the expected words to terminate the control structure. > Consider the alternative. From the start I rigidly keep to the ANS Forth > standard, avoiding all the pitfalls I know about, I test it on all > standard systems I can get hold of. Result my application works for > everybody, no hassle, a usable tool etc. > > Sorry but your approach is just for lone wolf amateurs/hobbyists which > is perfectly OK if that's all you aspire to. Supporting a standard > doesn't mean opposing change e.g. witness the proposals for quotations > and recognisers from supporters of the standard and the violent > objections from some who hate the standard. > > Regarding your belief in reason over standards - anyone can use your END > to replace EXIT THEN if they wish, provided they define it first. > Furthermore if they then wish to use the construct OF ... END they can > easily redefine OF to do that using standard code and it will run on a > standard system. e.g. > > : of postpone over postpone = postpone if postpone drop ; immediate I'm lost. How is this different from the standard? What am I missing? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-23 12:14 +0000 |
| Message-ID | <o64rv4$5n2$1@dont-email.me> |
| In reply to | #54291 |
On 23/01/2017 10:53, rickman wrote: >> But with a given Forth system you cannot guarantee that OF has a >> "built-in IF". Suppose I use your end-of-line? example and I'm using >> GForth - it works so you're correct, I try it on SwiftForth and it still >> works. Suppose I am so impressed that I use something similar in several >> places in an application I'm developing and make the application >> available on the internet. Someone downloads it and wants it to run on >> VFX Forth or Win32 Forth and the application fails to even compile. >> Result, a lot of hassle for me and the user, that application gets a bad >> name, I acquire a bad reputation, some people will unfairly blame VFX >> Forth and Win32 Forth for not compiling non-standard code. > > I'm not sure why you are saying OF doesn't have a "built in IF". Looking > at the two definitions the only difference is that OF compares the two > two items on the stack removing the top one while IF just checks the top > item for being zero. In other words OF is just OVER = IF. > > Why would that fail? BTW, neither definition of IF or OF require the > terminating word to be a particular one. > > IF - The semantics are incomplete until orig is resolved, e.g., by THEN > or ELSE. > > OF - The semantics are incomplete until resolved by a consumer of > of-sys such as ENDOF > > They are clearly leaving room for something other than the expected > words to terminate the control structure. When compiling ENDOF some systems check that there is an of-sys on the control stack and throw an error if there isn't. Similarly compiling THEN requires an orig on the control stack. Other systems such as GForth and SwiftForth are more lenient and either don't check the control stack or permit non-standard usage of THEN. >> Regarding your belief in reason over standards - anyone can use your END >> to replace EXIT THEN if they wish, provided they define it first. >> Furthermore if they then wish to use the construct OF ... END they can >> easily redefine OF to do that using standard code and it will run on a >> standard system. e.g. >> >> : of postpone over postpone = postpone if postpone drop ; immediate > > I'm lost. How is this different from the standard? What am I missing? See above about the control stack. Also systems may not compile Forth code but machine code (possibly optimised), or have an OF primitive or ... The behaviour to the user will be the same but with a different implementation. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 14:53 -0500 |
| Message-ID | <o65ms3$ejp$1@dont-email.me> |
| In reply to | #54298 |
On 1/23/2017 7:14 AM, Gerry Jackson wrote: > On 23/01/2017 10:53, rickman wrote: >>> But with a given Forth system you cannot guarantee that OF has a >>> "built-in IF". Suppose I use your end-of-line? example and I'm using >>> GForth - it works so you're correct, I try it on SwiftForth and it still >>> works. Suppose I am so impressed that I use something similar in several >>> places in an application I'm developing and make the application >>> available on the internet. Someone downloads it and wants it to run on >>> VFX Forth or Win32 Forth and the application fails to even compile. >>> Result, a lot of hassle for me and the user, that application gets a bad >>> name, I acquire a bad reputation, some people will unfairly blame VFX >>> Forth and Win32 Forth for not compiling non-standard code. >> >> I'm not sure why you are saying OF doesn't have a "built in IF". Looking >> at the two definitions the only difference is that OF compares the two >> two items on the stack removing the top one while IF just checks the top >> item for being zero. In other words OF is just OVER = IF. >> >> Why would that fail? BTW, neither definition of IF or OF require the >> terminating word to be a particular one. >> >> IF - The semantics are incomplete until orig is resolved, e.g., by THEN >> or ELSE. >> >> OF - The semantics are incomplete until resolved by a consumer of >> of-sys such as ENDOF >> >> They are clearly leaving room for something other than the expected >> words to terminate the control structure. > > When compiling ENDOF some systems check that there is an of-sys on the > control stack and throw an error if there isn't. Similarly compiling > THEN requires an orig on the control stack. Other systems such as GForth > and SwiftForth are more lenient and either don't check the control stack > or permit non-standard usage of THEN. I didn't realize it was not guaranteed that OF works the same way as the way IF works. I see now there is no guarantee they will be inter-compatible with THEN and ENDOF. So this usage of OF EXIT THEN is not even an ANS supported feature. >>> Regarding your belief in reason over standards - anyone can use your END >>> to replace EXIT THEN if they wish, provided they define it first. >>> Furthermore if they then wish to use the construct OF ... END they can >>> easily redefine OF to do that using standard code and it will run on a >>> standard system. e.g. >>> >>> : of postpone over postpone = postpone if postpone drop ; immediate >> >> I'm lost. How is this different from the standard? What am I missing? > > See above about the control stack. Also systems may not compile Forth > code but machine code (possibly optimised), or have an OF primitive or > ... The behaviour to the user will be the same but with a different > implementation. Not sure what you are trying to say. Why do I care about implementation if the result is the same? The only difference is that OF and IF do not necessarily use the same flags on the control flow stack and so may not be interchangable. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-24 21:37 +1100 |
| Message-ID | <o67ao4$8ng$1@gioia.aioe.org> |
| In reply to | #54287 |
Gerry Jackson wrote: > ... > Sorry but your approach is just for lone wolf amateurs/hobbyists which > is perfectly OK if that's all you aspire to. It took a "lone wolf" software engineer to create the language you now use.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-24 19:54 -0500 |
| Message-ID | <o68sso$otg$2@dont-email.me> |
| In reply to | #54350 |
On 1/24/2017 5:37 AM, HAA wrote: > Gerry Jackson wrote: >> ... >> Sorry but your approach is just for lone wolf amateurs/hobbyists which >> is perfectly OK if that's all you aspire to. > > It took a "lone wolf" software engineer to create the language you now use. So please go and create a new language that includes all the things you want and let us know when you are done. Bye. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-25 03:38 -0600 |
| Message-ID | <M6KdnTlY2bmL7xXFnZ2dnUU7-bHNnZ2d@supernews.com> |
| In reply to | #54350 |
HAA <someone@microsoft.com> wrote: > Gerry Jackson wrote: >> ... >> Sorry but your approach is just for lone wolf amateurs/hobbyists which >> is perfectly OK if that's all you aspire to. > > It took a "lone wolf" software engineer to create the language you > now use. Primordial Forth, yes, but the Forth in use now is a collaboration, and that collaboration drove the design of the language and its standardization. Apart from Chuck Moore, Dean Sanderson in particular was important: he was the architect of microForth, on which fig-FORTH was based. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-01-17 08:01 -0800 |
| Message-ID | <d58bbb8d-6f70-41b7-9b2f-c2c1240852ef@googlegroups.com> |
| In reply to | #54064 |
On Tuesday, 17 January 2017 01:18:25 UTC, 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 some_condition IF EXIT THEN reduced to: some_condition IF END is quite nice. However, how about removing the IF: some_condition TERMINATES Super nice. macro: TERMINATES IF EXIT THEN ;
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-17 10:27 -0800 |
| Message-ID | <e596d1e5-5fef-45d8-a973-83b6f5d1a4da@googlegroups.com> |
| In reply to | #54078 |
On Tuesday, January 17, 2017 at 9:01:35 AM UTC-7, Mark Wills wrote: > On Tuesday, 17 January 2017 01:18:25 UTC, 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 > > some_condition IF EXIT THEN > reduced to: > some_condition IF END > is quite nice. > > However, how about removing the IF: > > some_condition TERMINATES > > Super nice. > > macro: TERMINATES IF EXIT THEN ; That is possible! In my experience though, there is usually something inside of the conditional. For example: IF FALSE EXIT THEN Or: IF FALSE END I can put TERMINATES in the novice-package too though --- maybe it will get some use...
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-17 11:34 -0800 |
| Message-ID | <o5lrgg$t9q$1@dont-email.me> |
| In reply to | #54082 |
On 1/17/2017 10:27, hughaguilar96@gmail.com wrote: > On Tuesday, January 17, 2017 at 9:01:35 AM UTC-7, Mark Wills wrote: >> On Tuesday, 17 January 2017 01:18:25 UTC, 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 >> >> some_condition IF EXIT THEN reduced to: some_condition IF END is >> quite nice. >> >> However, how about removing the IF: >> >> some_condition TERMINATES >> >> Super nice. >> >> macro: TERMINATES IF EXIT THEN ; > > That is possible! > > In my experience though, there is usually something inside of the > conditional. For example: > > IF FALSE EXIT THEN > > Or: > > IF FALSE END > > I can put TERMINATES in the novice-package too though --- maybe it > will get some use... > Some compilers may provide a POSTPONE EXIT that doesn't work. I believe this was true of Gforth prior to 2015: http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf, since ' EXIT EXECUTE was not equivalent to EXIT. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-18 14:35 +0000 |
| Message-ID | <2017Jan18.153542@mips.complang.tuwien.ac.at> |
| In reply to | #54083 |
Alex <alex@rivadpm.com> writes:
>Some compilers may provide a POSTPONE EXIT that doesn't work.
On a standard system POSTPONE EXIT works, and that includes all
versions of Gforth.
>I believe
>this was true of Gforth prior to 2015:
>http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf,
>since ' EXIT EXECUTE was not equivalent to EXIT.
That has nothing to do with POSTPONE EXIT. EXIT was implemented as an
IMMEDIATE COMPILE-ONLY word, and that's why ['] EXIT EXECUTE was not
equivalent to EXIT.
We then tried to make ['] EXIT EXECUTE work and equivalent to EXIT,
and that attempt is described in the paper refernced above.
However, there are so many interacting features that we have reverted
much of the related changes. The straw that broke the camel's back
was:
: test dup 0> IF 1- recurse ELSE { a } a . THEN 'x' emit ;
Yes, this does not even contain EXIT, much less ['] EXIT EXECUTE, but
the infrastructure we installed to make ['] EXIT EXECUTE work (see the
paper for details) failed in this case. One could have added even
more infrastructure, but we gave up on making ['] EXIT EXECUTE
equivalent to EXIT.
However, at the moment ['] EXIT EXECUTE superficially appears to work
as expected, but silently fails in corner cases:
: foo 1 { a } ['] exit execute ;
: bar 2 { b } foo b . ;
bar \ should print 2, but prints 1
: foo1 1 {: a :} exit ;
: bar1 2 {: b :} foo1 b . ;
bar1 \ prints 2
I think that's a bad idea.
Concerning the DOES> part of the paper, that turned out nicely, so at
least something good has come out of this.
- 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-01-18 10:37 +1100 |
| Message-ID | <o5m9qq$1mpm$1@gioia.aioe.org> |
| In reply to | #54078 |
Mark Wills wrote: > ... > some_condition IF EXIT THEN > reduced to: > some_condition IF END > is quite nice. > > However, how about removing the IF: > > some_condition TERMINATES > > Super nice. > > macro: TERMINATES IF EXIT THEN ; This already exists in many Forth under the name ?EXIT
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-17 20:53 -0500 |
| Message-ID | <o5mhno$cdl$1@dont-email.me> |
| In reply to | #54089 |
On 1/17/2017 6:37 PM, HAA wrote: > Mark Wills wrote: >> ... >> some_condition IF EXIT THEN >> reduced to: >> some_condition IF END >> is quite nice. >> >> However, how about removing the IF: >> >> some_condition TERMINATES >> >> Super nice. >> >> macro: TERMINATES IF EXIT THEN ; > > This already exists in many Forth under the name ?EXIT I am no Forth expert by any stretch of the imagination. Maybe someone can explain to me the utility of EXIT THEN? I was raised on "structured" programming where we relish something like IF stuff ELSE more stuff THEN ; Why is this better? IF stuff EXIT THEN more stuff ; Or even IF stuff END more stuff ; Or is the whole thing whizzing over my head? Puzzled in CS-101... -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-17 18:02 -1000 |
| Message-ID | <NaWdnXHjxp4mdePFnZ2dnUU7-bfNnZ2d@supernews.com> |
| In reply to | #54090 |
On 1/17/17 3:53 PM, rickman wrote: > On 1/17/2017 6:37 PM, HAA wrote: >> Mark Wills wrote: >>> ... >>> some_condition IF EXIT THEN >>> reduced to: >>> some_condition IF END >>> is quite nice. >>> >>> However, how about removing the IF: >>> >>> some_condition TERMINATES >>> >>> Super nice. >>> >>> macro: TERMINATES IF EXIT THEN ; >> >> This already exists in many Forth under the name ?EXIT > > I am no Forth expert by any stretch of the imagination. Maybe someone > can explain to me the utility of EXIT THEN? > > I was raised on "structured" programming where we relish something like > > IF stuff ELSE more stuff THEN ; > > Why is this better? > > IF stuff EXIT THEN more stuff ; > > Or even > > IF stuff END more stuff ; > > Or is the whole thing whizzing over my head? > > Puzzled in CS-101... There's a faint whizzing sound. EXIT leaves the definition in which it appears, so if the END executes the 'more stuff' after would not be executed. In other words, in the definition: : foo [test] IF stuff END more stuff ; ...'more stuff' will only execute if the [test] gives a false. It avoids the need for an ELSE. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-18 00:15 -0500 |
| Message-ID | <o5mti8$vb2$1@dont-email.me> |
| In reply to | #54092 |
On 1/17/2017 11:02 PM, Elizabeth D. Rather wrote: > On 1/17/17 3:53 PM, rickman wrote: >> On 1/17/2017 6:37 PM, HAA wrote: >>> Mark Wills wrote: >>>> ... >>>> some_condition IF EXIT THEN >>>> reduced to: >>>> some_condition IF END >>>> is quite nice. >>>> >>>> However, how about removing the IF: >>>> >>>> some_condition TERMINATES >>>> >>>> Super nice. >>>> >>>> macro: TERMINATES IF EXIT THEN ; >>> >>> This already exists in many Forth under the name ?EXIT >> >> I am no Forth expert by any stretch of the imagination. Maybe someone >> can explain to me the utility of EXIT THEN? >> >> I was raised on "structured" programming where we relish something like >> >> IF stuff ELSE more stuff THEN ; >> >> Why is this better? >> >> IF stuff EXIT THEN more stuff ; >> >> Or even >> >> IF stuff END more stuff ; >> >> Or is the whole thing whizzing over my head? >> >> Puzzled in CS-101... > > There's a faint whizzing sound. EXIT leaves the definition in which it > appears, so if the END executes the 'more stuff' after would not be > executed. In other words, in the definition: > > : foo [test] IF stuff END more stuff ; > > ...'more stuff' will only execute if the [test] gives a false. It avoids > the need for an ELSE. I think the whizzing sound is not me. I get what what END does. My examples show that, no? What I don't get is why anyone doesn't like IF ELSE THEN (other than the odd use of THEN [vs conventional languages]). IF ... ELSE ... THEN I think that is pretty clear. IF ... END ... ; That is not at all clear to me in any useful way. If END is the end, why would there be more stuff after it? Not at all intuitive, *especially* for someone familiar with programming in other languages... and as I said, versed in structured programming. What is the point of END? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-17 19:34 -1000 |
| Message-ID | <iISdnR6cRIbNY-PFnZ2dnUU7-XHNnZ2d@supernews.com> |
| In reply to | #54094 |
On 1/17/17 7:15 PM, rickman wrote: > On 1/17/2017 11:02 PM, Elizabeth D. Rather wrote: >> On 1/17/17 3:53 PM, rickman wrote: >>> On 1/17/2017 6:37 PM, HAA wrote: >>>> Mark Wills wrote: >>>>> ... >>>>> some_condition IF EXIT THEN >>>>> reduced to: >>>>> some_condition IF END >>>>> is quite nice. >>>>> >>>>> However, how about removing the IF: >>>>> >>>>> some_condition TERMINATES >>>>> >>>>> Super nice. >>>>> >>>>> macro: TERMINATES IF EXIT THEN ; >>>> >>>> This already exists in many Forth under the name ?EXIT >>> >>> I am no Forth expert by any stretch of the imagination. Maybe someone >>> can explain to me the utility of EXIT THEN? >>> >>> I was raised on "structured" programming where we relish something like >>> >>> IF stuff ELSE more stuff THEN ; >>> >>> Why is this better? >>> >>> IF stuff EXIT THEN more stuff ; >>> >>> Or even >>> >>> IF stuff END more stuff ; >>> >>> Or is the whole thing whizzing over my head? >>> >>> Puzzled in CS-101... >> >> There's a faint whizzing sound. EXIT leaves the definition in which it >> appears, so if the END executes the 'more stuff' after would not be >> executed. In other words, in the definition: >> >> : foo [test] IF stuff END more stuff ; >> >> ...'more stuff' will only execute if the [test] gives a false. It avoids >> the need for an ELSE. > > I think the whizzing sound is not me. I get what what END does. My > examples show that, no? What I don't get is why anyone doesn't like IF > ELSE THEN (other than the odd use of THEN [vs conventional languages]). > > IF ... ELSE ... THEN > > I think that is pretty clear. > > IF ... END ... ; > > That is not at all clear to me in any useful way. If END is the end, > why would there be more stuff after it? Not at all intuitive, > *especially* for someone familiar with programming in other languages... > and as I said, versed in structured programming. > > What is the point of END? END is a pretty minor enhancement, which is why I questioned its value. But ELSE costs a couple of cells, and the OP thinks END is prettier than ELSE EXIT THEN. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web