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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-23 21:48 +1100 |
| Message-ID | <o64mvk$1qc6$1@gioia.aioe.org> |
| In reply to | #54265 |
Alex wrote: > On 1/22/2017 20:00, HAA wrote: > > ... > > Change is never popular but it will become apparent THEN in EXIT > > THEN is not needed by the end-user. It was just a prop used by the > > compiler at compile-time to complete an address. Nobody is worried > > the THEN in REPEAT is not visible because it's not necessary in > > understanding what occurs at run-time. It's the same with END. The > > compiler's need for THEN should not be the burden of the programmer. > > All he needs to know is the effect at run-time, which is to exit the > > definition. By hiding THEN within END the result is simpler, more > > effect looking code. And given the numbers involved it will be > > dramatic. > > > > You're conflating two effects in a single word END. > > The THEN indicates the termination of the effect of the IF; No. EXIT terminates the statements following IF. THEN is just for the compiler's benefit. Because Forth had no END you were forced to write EXIT THEN. You got used to it and believe it's 'normal'. A language designer wouldn't have EXIT THEN because it makes no sense - if it EXITs why the THEN ? EXIT THEN conflates the requirements of the compiler and the needs of the programmer. If it didn't occur as often as it does then you could say who cares I'll put up with the lack of logic. But it does occur very frequently and that suggests an omission in the language which is END.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 06:18 -0500 |
| Message-ID | <o64omr$n3u$1@dont-email.me> |
| In reply to | #54289 |
On 1/23/2017 5:48 AM, HAA wrote: > Alex wrote: >> On 1/22/2017 20:00, HAA wrote: >>> ... >>> Change is never popular but it will become apparent THEN in EXIT >>> THEN is not needed by the end-user. It was just a prop used by the >>> compiler at compile-time to complete an address. Nobody is worried >>> the THEN in REPEAT is not visible because it's not necessary in >>> understanding what occurs at run-time. It's the same with END. The >>> compiler's need for THEN should not be the burden of the programmer. >>> All he needs to know is the effect at run-time, which is to exit the >>> definition. By hiding THEN within END the result is simpler, more >>> effect looking code. And given the numbers involved it will be >>> dramatic. >>> >> >> You're conflating two effects in a single word END. >> >> The THEN indicates the termination of the effect of the IF; > > No. EXIT terminates the statements following IF. THEN is just for > the compiler's benefit. Because Forth had no END you were forced > to write EXIT THEN. You got used to it and believe it's 'normal'. > A language designer wouldn't have EXIT THEN because it makes > no sense - if it EXITs why the THEN ? Are you serious? Do you really not get why the THEN is needed? How do you handle the case of *not* exiting? That is when the THEN marks the location of execution flow from the IF. > EXIT THEN conflates the requirements of the compiler and the > needs of the programmer. If it didn't occur as often as it does > then you could say who cares I'll put up with the lack of logic. > But it does occur very frequently and that suggests an omission > in the language which is END. Non-sequitur. The fact that 0= IF is a hugely common idiom in Forth, there is no IFNOT that I am aware of. Or did I miss that too? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-26 11:34 +1100 |
| Message-ID | <o6bg4r$1tnk$1@gioia.aioe.org> |
| In reply to | #54293 |
rickman wrote: > > ... > > No. EXIT terminates the statements following IF. THEN is just for > > the compiler's benefit. Because Forth had no END you were forced > > to write EXIT THEN. You got used to it and believe it's 'normal'. > > A language designer wouldn't have EXIT THEN because it makes > > no sense - if it EXITs why the THEN ? > > Are you serious? Very serious > Do you really not get why the THEN is needed? Elizabeth doesn't appear to think so. THEN is needed by the compiler as I've stated. The user definitely doesn't need it. It follows EXIT around in Forth code like the useless tail it is. > How do > you handle the case of *not* exiting? That is when the THEN marks the > location of execution flow from the IF. THEN is hidden within END in the same way REPEAT hid the THEN from WHILE. The precedence in Forth exists.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-25 22:04 -0500 |
| Message-ID | <o6botl$eci$1@dont-email.me> |
| In reply to | #54402 |
On 1/25/2017 7:34 PM, HAA wrote: > rickman wrote: >>> ... >>> No. EXIT terminates the statements following IF. THEN is just for >>> the compiler's benefit. Because Forth had no END you were forced >>> to write EXIT THEN. You got used to it and believe it's 'normal'. >>> A language designer wouldn't have EXIT THEN because it makes >>> no sense - if it EXITs why the THEN ? >> >> Are you serious? > > Very serious > >> Do you really not get why the THEN is needed? > > Elizabeth doesn't appear to think so. THEN is needed by the compiler as > I've stated. The user definitely doesn't need it. It follows EXIT around in > Forth code like the useless tail it is. > >> How do >> you handle the case of *not* exiting? That is when the THEN marks the >> location of execution flow from the IF. > > THEN is hidden within END in the same way REPEAT hid the THEN > from WHILE. The precedence in Forth exists. : TEST IF EXIT THEN STUFF ; So if you don't have a THEN, how does execution ever reach STUFF? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-25 17:22 -1000 |
| Message-ID | <Erqdnd9tWNrh9hTFnZ2dnUU7-d_NnZ2d@supernews.com> |
| In reply to | #54405 |
On 1/25/17 5:04 PM, rickman wrote: > On 1/25/2017 7:34 PM, HAA wrote: >> rickman wrote: >>>> ... >>>> No. EXIT terminates the statements following IF. THEN is just for >>>> the compiler's benefit. Because Forth had no END you were forced >>>> to write EXIT THEN. You got used to it and believe it's 'normal'. >>>> A language designer wouldn't have EXIT THEN because it makes >>>> no sense - if it EXITs why the THEN ? >>> >>> Are you serious? >> >> Very serious >> >>> Do you really not get why the THEN is needed? >> >> Elizabeth doesn't appear to think so. THEN is needed by the compiler as >> I've stated. The user definitely doesn't need it. It follows EXIT >> around in >> Forth code like the useless tail it is. >> >>> How do >>> you handle the case of *not* exiting? That is when the THEN marks the >>> location of execution flow from the IF. >> >> THEN is hidden within END in the same way REPEAT hid the THEN >> from WHILE. The precedence in Forth exists. > > : TEST IF EXIT THEN STUFF ; > > So if you don't have a THEN, how does execution ever reach STUFF? > You would reach STUFF if your argument to IF is false. And that's quite a plausible scenario. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-01-26 00:55 -0800 |
| Message-ID | <70783e20-ccf5-4c91-8181-e71b74a532e4@googlegroups.com> |
| In reply to | #54402 |
On Thursday, 26 January 2017 00:33:36 UTC, HAA wrote: > rickman wrote: > > > ... > > > No. EXIT terminates the statements following IF. THEN is just for > > > the compiler's benefit. Because Forth had no END you were forced > > > to write EXIT THEN. You got used to it and believe it's 'normal'. > > > A language designer wouldn't have EXIT THEN because it makes > > > no sense - if it EXITs why the THEN ? > > > > Are you serious? > > Very serious > > > Do you really not get why the THEN is needed? > > Elizabeth doesn't appear to think so. THEN is needed by the compiler as > I've stated. The user definitely doesn't need it. It follows EXIT around in > Forth code like the useless tail it is. > > > How do > > you handle the case of *not* exiting? That is when the THEN marks the > > location of execution flow from the IF. > > THEN is hidden within END in the same way REPEAT hid the THEN > from WHILE. The precedence in Forth exists. some_condition if end more_stuff some_condition ?exit more_stuff Second one is much nicer and is a recognised Forth idiom, even if it's not ANS.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-27 13:40 +1100 |
| Message-ID | <o6ebtk$aet$1@gioia.aioe.org> |
| In reply to | #54412 |
Mark Wills wrote: > ... > some_condition if end more_stuff > > some_condition ?exit more_stuff > > Second one is much nicer and is a recognised Forth idiom, even if it's > not ANS. Forth doesn't recognize 'nice' :) It is a lean programming environment. END removes redundancy and can replace both EXIT (mostly) and ?EXIT. I notice SwiftForth has and uses ?EXIT a lot, while others get by without it. It may be just programming style.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-20 11:44 +1100 |
| Message-ID | <o5rmh8$7p4$1@gioia.aioe.org> |
| In reply to | #54142 |
Elizabeth D. Rather wrote:
> On 1/18/17 4:04 PM, HAA wrote:
> > Elizabeth D. Rather wrote:
> >> On 1/17/17 7:15 PM, rickman wrote:
> >>> ...
> >>> What is the point of END?
> >>
> >> END is a pretty minor enhancement, which is why I questioned its value.
> >
> > Minor in what way? Not in frequency where Forth Inc's own usage exceeds
> > that of REPEAT, or readability where it replaces means with effect, or in
> > typing where it reduces character count from nine or more to three. By any
> > measure I can find the enhancement looks substantial.
>
> Minor in that it offers no advantage in size or performance, only a very
> minor syntactic sugar. All those uses have already been typed; it isn't
> really worth it to retype them.
I care about how my *future* code will look and given the extensive use
Forth makes of EXIT THEN, I think only the best will do.
As an exercise I went through some of my existing code, changing instances
of EXIT THEN to END. I was particularly interested to see whether I could find
examples where the change was detrimental. In all but one the change was
immediately noticeable and beneficial. I'll mention the exception for anyone
interested. It was this:
Original code:
begin
A
while
B if
C
else
D exit
then
repeat
Replace with END:
begin
A
while
B if
C
else
D
end
repeat
It may be unfamiliarity but I had a problem with it. It didn't read so well. I was
expecting a THEN for ELSE to resolve but there was none. After a while I realized
it was a matter placement. I reformatted the code so that END followed D (similar
to the original).
begin
A
while
B if
C
else D end
repeat
The mental block vanished and I was completely fine with it. The code even looked
more compact. Code involving EXIT THEN tends to preceded by an IF. This was
an exception which required more than mindless replacement. Now that I know
where END should be placed, I'll have no problems in the future.
> > This just may be the first worthwhile control flow addition Forth has seen
> > since ANS WHILE. I'm conservative when it comes to Forth so I don't say
> > that lightly. If there are any issues with END, I want to hear about it. I've
> > seen too many additions to Forth that have languished unused. I don't
> > want it to be the case with END.
>
> It's one more word to teach and remember, and people already complain
> there are too many. I wouldn't oppose it, I'm just not cheering for it.
>
> Cheers,
> Elizabeth
BUFFER: was one more word to learn and it occurs only 105 times in
SwiftForth - less than half the number of EXIT THENs. There are places
where BUFFER: can't be used and you need to revert to CREATE. That's
not true of END which can always replace EXIT THEN. BUFFER: I can do
without. EXIT THEN I can do without. END I no longer can, such has been
the visual improvement to code.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-18 08:02 -0500 |
| Message-ID | <20170118080251.08615130@_> |
| In reply to | #54064 |
On Tue, 17 Jan 2017 12:17:01 +1100 "HAA" <someone@microsoft.com> 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 > > [from a later post] > > 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. For threaded code, migrating to END would conserve some memory, which might be useful for an embedded environment. But, defining END and using it instead of EXIT THEN would also slow down the address interpreter. There is additional overhead to switch the thread being interpreted from one word to another and back. So, AISI, if speed is a concern, using END could make sense for threaded code, if END is implemented as a primitive or low-level word, i.e., not defined in high-level Forth. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-01-18 17:45 +0100 |
| Message-ID | <1d1339lle659d$.1o5q92umqydzl$.dlg@40tude.net> |
| In reply to | #54116 |
Op Wed, 18 Jan 2017 08:02:51 -0500 schreef Rod Pemberton: <snip> > For threaded code, migrating to END would conserve some memory, which > might be useful for an embedded environment. But, defining END and > using it instead of EXIT THEN would also slow down the address > interpreter. Both methods compile the runtime of EXIT and resolve THEN. In threaded code it's the same produced code. That goes for native code as well. What do you mean with slowing down the address interpreter? If you mean NEXT there is no difference whatsoever. > There is additional overhead to switch the thread being > interpreted from one word to another and back. I can't follow this sentence at all. > So, AISI, if speed is > a concern, using END could make sense for threaded code, if END is > implemented as a primitive or low-level word, i.e., not defined in > high-level Forth. No. > > Rod Pemberton groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-19 20:02 -0500 |
| Message-ID | <20170119200236.6354406f@_> |
| In reply to | #54123 |
On Wed, 18 Jan 2017 17:45:37 +0100 Coos Haak <htrofhc@gmail.com> wrote: > Op Wed, 18 Jan 2017 08:02:51 -0500 schreef Rod Pemberton: > <snip> > > For threaded code, migrating to END would conserve some memory, > > which might be useful for an embedded environment. But, defining > > END and using it instead of EXIT THEN would also slow down the > > address interpreter. > > Both methods compile the runtime of EXIT and resolve THEN. > In threaded code it's the same produced code. That goes for native > code as well. What do you mean with slowing down the address > interpreter? If you mean NEXT there is no difference whatsoever. Sorry, that was my mistake. For some reason, I was thinking he had posted this when I replied: : END EXIT THEN ; Never mind, Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-01-22 18:23 -0800 |
| Message-ID | <006f7c9a-3ded-4d45-bd00-cfd992df0651@googlegroups.com> |
| In reply to | #54064 |
On Monday, January 16, 2017 at 7:18:25 PM UTC-6, 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 > There was a recent 'flat earth' controversy in certain online communities, which went like this: take the same language and rhetoric that skeptics and revisionists apply to more serious subjects, and apply them to something completely absurd, and then see how far you get. How much trouble will people have with arguing against their own styles of argumentation? This thread reads very similarly. Good work, if that was deliberate. gforth has ?EXIT : ?EXIT POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE I've come to prefer IF EXIT THEN , for these reasons: 1. this isn't some high level contruct, like a syntax to loop over some data. It's just an abbreviation. Using POSTPONE for abbreviations feels like leetspeek in code. 2. it's no big deal if IF EXIT THEN becomes IF 0 EXIT THEN , but unpacking and extending ?EXIT changes the appearance of the code a great deal. You are tempted to add an additional abbreviation. 3. IF EXIT THEN isn't great either. Seeing that in your code, you wonder if it's really necessary to have a construct like that. Maybe some refactoring is in order. That refactoring would probably result in a much nicer design. I'd rather leave temptations like that in, to improve things later, rather than paper over them. IF END though is ugly, and a waste of a nice three-letter word. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-02 12:24 +0100 |
| Message-ID | <o6v4tf$k59$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54064 |
In article <o5jrct$1r41$1@gioia.aioe.org>, HAA <someone@microsoft.com> 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 > Much more sensible is replacing the sequence '' BOUNDS ?DO '' by FOR : FOR POSTPONE SWAP POSTPONE OVER POSTPONE + POSTPONE ?DO ; Now we can do : test "AAP" FOR I C@ EMIT LOOP ; We could come up with an endless stream of those macro's. The rule must be: if in some project some macro can be used so often that it makes sense to introduce it, define it in the project prelude. I DO NOT PROPOSE `` FOR '' AS AN ADDITION TO THE STANDARD OR ANYTHING. I JUST STATE THAT IN SOME PROJECTS IT MIGHT BE APPROPRIATE IN A PROJECT PRELUDE. I FIRMLY REJECT PROPOSALS LIKE ``FOR'' AND ``END'' AS A PERMANENT ADDITION TO A FORTH. (Not that it helps to prevent this thread to go in the direction of the pro's and con's of FOR.) Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-10 12:15 +1100 |
| Message-ID | <o7j45j$19ee$1@gioia.aioe.org> |
| In reply to | #54595 |
Albert van der Horst wrote:
> In article <o5jrct$1r41$1@gioia.aioe.org>, HAA <someone@microsoft.com> 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
> >
>
> Much more sensible is replacing the sequence '' BOUNDS ?DO '' by FOR
>
> : FOR POSTPONE SWAP POSTPONE OVER POSTPONE + POSTPONE ?DO ;
>
> Now we can do
>
> : test "AAP" FOR I C@ EMIT LOOP ;
>
> We could come up with an endless stream of those macro's.
>
> The rule must be:
> if in some project some macro can be used so often that it makes
> sense to introduce it, define it in the project prelude.
>
> I DO NOT PROPOSE `` FOR '' AS AN ADDITION TO THE STANDARD OR ANYTHING.
> I JUST STATE THAT IN SOME PROJECTS IT MIGHT BE APPROPRIATE IN A
> PROJECT PRELUDE.
> I FIRMLY REJECT PROPOSALS LIKE ``FOR'' AND ``END'' AS A PERMANENT
> ADDITION TO A FORTH.
>
> (Not that it helps to prevent this thread to go in the direction
> of the pro's and con's of FOR.)
>
> Groetjes Albert
Yet there are respected Forths which define ?EXIT on relatively few counts.
Numbers matter but also the idea.
When the numbers are very high as they are with EXIT THEN and the usage
exceeds that of other conditionals such as BEGIN REPEAT then you begin
wondering, as I did, whether Forth missed something. When you can point
to potentially further use in Case statements then you realize it has gone
cosmetics and convenience. For me, END is part of the Forth language.
It's always been there - just hidden.
Here's an example from SwiftForth that makes use of both END and a
broadened definition for OF. Which version would you prefer to code?
\ original code
...
begin
0 key $20 or case
[char] n of ... 1- endof
[char] s of ... 1- endof
[char] r of ... 1- endof
[char] f of ... 1- endof
endcase
until ;
\ using END
...
begin
key $20 or
[char] n of ... end
[char] s of ... end
[char] r of ... end
[char] f of ... end
drop
again ;
BTW a check of SwiftForth for BOUNDS DO/?DO reveals a count of 22 out
of 300+ files searched.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-02-10 10:57 -0800 |
| Message-ID | <f6928d15-aebe-4dcf-91f4-0fbc88b32827@googlegroups.com> |
| In reply to | #54760 |
On Friday, February 10, 2017 at 2:14:35 AM UTC+1, HAA wrote: > Albert van der Horst wrote: > > In article <o5jrct$1r41$1@gioia.aioe.org>, HAA <someone@microsoft.com> 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 > > > > > > > Much more sensible is replacing the sequence '' BOUNDS ?DO '' by FOR > > > > : FOR POSTPONE SWAP POSTPONE OVER POSTPONE + POSTPONE ?DO ; > > > > Now we can do > > > > : test "AAP" FOR I C@ EMIT LOOP ; > > > > We could come up with an endless stream of those macro's. > > > > The rule must be: > > if in some project some macro can be used so often that it makes > > sense to introduce it, define it in the project prelude. > > > > I DO NOT PROPOSE `` FOR '' AS AN ADDITION TO THE STANDARD OR ANYTHING. > > I JUST STATE THAT IN SOME PROJECTS IT MIGHT BE APPROPRIATE IN A > > PROJECT PRELUDE. > > I FIRMLY REJECT PROPOSALS LIKE ``FOR'' AND ``END'' AS A PERMANENT > > ADDITION TO A FORTH. > > > > (Not that it helps to prevent this thread to go in the direction > > of the pro's and con's of FOR.) > > > > Groetjes Albert > > Yet there are respected Forths which define ?EXIT on relatively few counts. > Numbers matter but also the idea. > > When the numbers are very high as they are with EXIT THEN and the usage > exceeds that of other conditionals such as BEGIN REPEAT then you begin > wondering, as I did, whether Forth missed something. When you can point > to potentially further use in Case statements then you realize it has gone > cosmetics and convenience. For me, END is part of the Forth language. > It's always been there - just hidden. > > Here's an example from SwiftForth that makes use of both END and a > broadened definition for OF. Which version would you prefer to code? > > \ original code > ... > begin > 0 key $20 or case > [char] n of ... 1- endof > [char] s of ... 1- endof > [char] r of ... 1- endof > [char] f of ... 1- endof > endcase > until ; > > \ using END > ... > begin > key $20 or > [char] n of ... end > [char] s of ... end > [char] r of ... end > [char] f of ... end > drop > again ; > > BTW a check of SwiftForth for BOUNDS DO/?DO reveals a count of 22 out > of 300+ files searched. total iForth files: 19357 Searching for: BOUNDS ?DO Found 355 occurrence(s) in 180 file(s) Searching for: ?EXIT Found 1052 occurrence(s) in 278 file(s) Searching for: EXIT ENDIF Found 1180 occurrence(s) in 299 file(s) Searching for: IF DROP Found 1530 occurrence(s) in 467 file(s) Searching for: EXIT THEN Found 2369 occurrence(s) in 422 file(s) But also: Searching for: 0= IF Found 5535 occurrence(s) in 1207 file(s) -marcel
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-11 12:45 +1100 |
| Message-ID | <o7lq8n$1jm5$1@gioia.aioe.org> |
| In reply to | #54778 |
mhx@iae.nl wrote: > ... > total iForth files: 19357 > > Searching for: BOUNDS ?DO > Found 355 occurrence(s) in 180 file(s) > > Searching for: ?EXIT > Found 1052 occurrence(s) in 278 file(s) > > Searching for: EXIT ENDIF > Found 1180 occurrence(s) in 299 file(s) > > Searching for: IF DROP > Found 1530 occurrence(s) in 467 file(s) > > Searching for: EXIT THEN > Found 2369 occurrence(s) in 422 file(s) As expected ?EXIT EXIT-THEN EXIT-ENDIF appear in large number. > > But also: > > Searching for: 0= IF > Found 5535 occurrence(s) in 1207 file(s) > > -marcel Coding style may influence this. For SwiftForth 0= IF NOT IF appear 200 times compared to ?EXIT (151) EXIT-THEN (227). Numbers matter but decisions are made on less. Take ANS words NIP and TUCK. SwiftForth: NIP (158) TUCK (56) NIP and TUCK are conveniences - additions to the language that don't fundamentally change anything. The underlying operators SWAP OVER DROP are still needed and used in number individually. The same would be true of 0= IF IF DROP OVER + SWAP DO were these replaced by macros. What's different about END is that it recognizes EXIT has little use in Forth. The sequence EXIT THEN is what's useful in Forth. The standalone word EXIT not so much.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-10 18:13 -0800 |
| Message-ID | <db3573f7-a2f8-4a6f-8270-7adfcec20b83@googlegroups.com> |
| In reply to | #54785 |
On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote:
> Coding style may influence this. For SwiftForth 0= IF NOT IF appear
> 200 times compared to ?EXIT (151) EXIT-THEN (227).
>
> Numbers matter but decisions are made on less. Take ANS words NIP
> and TUCK. SwiftForth: NIP (158) TUCK (56)
> NIP and TUCK are conveniences - additions to the language that don't
> fundamentally change anything.
ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and knew essentially nothing about code optimization.
NIP is the same as: SWAP DROP
TUCK is the same as: SWAP OVER
In a non-optimizing compiler, making NIP and TUCK into primitives (written in assembly-language) causes them to execute about twice as fast as having two primitives compiled (either SWAP DROP or SWAP OVER for NIP and TUCK respectively).
The same thing is true of ?EXIT --- making this a primitive is going to be result in much faster code than IF EXIT THEN would --- this is why those old Forth systems had ?EXIT despite the fact that it isn't used very much.
All in all, ANS-Forth was 1970s technology --- a lot of Forth systems (such as ISYS Forth for the Apple-IIc) were doing STC and code optimization --- only Forth Inc. continued to sell a Forth compiler that did not have any code optimization at all, and which was just warmed over 1970s technology.
In my novice-package I use lists quite a lot, and consequently I use INIT-LIST quite a lot (every node in every list needs to be initialized). Does this mean that INIT-LIST should be in the standard? No, that is only useful to people who use the novice-package, and it is trivial to write in ANS-Forth, so it doesn't really deserve to be put in the standard.
The problem is that, in SwiftForth it is abysmally slow. Here is the code:
SwiftForth? [if]
icode init-list ( node -- node )
zero(eax)
eax 0 [ebx] mov
ret
end-code
[else]
macro: init-list ( node -- node )
nil over .fore ! ;
[then]
Here is the code (with the SwiftForth? flag turned off, so we get the ANS-Forth code rather than the vendor-specific assembly-language code):
: ttt init-list ;
ttt isn't unique. ok
see ttt
492D5F 4 # EBP SUB 83ED04
492D62 EBX 0 [EBP] MOV 895D00
492D65 0 # EBX MOV BB00000000
492D6A 4 # EBP SUB 83ED04
492D6D EBX 0 [EBP] MOV 895D00
492D70 4 [EBP] EBX MOV 8B5D04
492D73 0 [EBP] EAX MOV 8B4500
492D76 EAX 0 [EBX] MOV 8903
492D78 4 [EBP] EBX MOV 8B5D04
492D7B 8 # EBP ADD 83C508
492D7E RET C3 ok
This is what you get in SwiftForth using my hand-written assembly-language (and suffering vendor lock-in as a result):
: ttt init-list ;
ttt isn't unique. ok
see ttt
49313F EAX EAX XOR 31C0
493141 EAX 0 [EBX] MOV 8903
493143 RET C3 ok
By comparison, this is what you get in VFX using ANS-Forth code:
: ttt init-list ; ok
see ttt
TTT
( 004E35F0 C70300000000 ) MOV DWord Ptr 0 [EBX], 00000000
( 004E35F6 C3 ) NEXT,
( 7 bytes, 2 instructions )
ok
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-02-11 07:55 -0500 |
| Message-ID | <20170211075559.5d4b2fc3@_> |
| In reply to | #54786 |
On Fri, 10 Feb 2017 18:13:43 -0800 (PST) hughaguilar96@gmail.com wrote: > On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote: > > Coding style may influence this. For SwiftForth 0= IF NOT IF > > appear 200 times compared to ?EXIT (151) EXIT-THEN (227). > > > > Numbers matter but decisions are made on less. Take ANS words NIP > > and TUCK. SwiftForth: NIP (158) TUCK (56) > > NIP and TUCK are conveniences - additions to the language that don't > > fundamentally change anything. > > ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and > knew essentially nothing about code optimization. > > NIP is the same as: SWAP DROP > TUCK is the same as: SWAP OVER NIP and TUCK are prime examples of why I said your <SWITCH wouldn't be used. I made a similar point to Anton about his superinstructions some years ago (or perhaps it was superoperators or some similar concept...). If you look at the counts for NIP and TUCK and compare them to those posted by Marcel for various word combinations, NIP and TUCK aren't used that much by anyone. This is because they're simply of low need, not in widespread use anywhere, and they weren't standard for a long time. > In a non-optimizing compiler, making NIP and TUCK into primitives > (written in assembly-language) causes them to execute about twice as > fast as having two primitives compiled (either SWAP DROP or SWAP OVER > for NIP and TUCK respectively). Why should anyone implement infrequently executed words as primitives? If you're going to implement them as primitives, i.e., you don't care about optimizing your time or investment, you might as well go ahead and implement all Forth words as primitives. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-11 13:16 +0000 |
| Message-ID | <o7n2nd$fkf$1@dont-email.me> |
| In reply to | #54789 |
On 2/11/2017 12:55, Rod Pemberton wrote: > On Fri, 10 Feb 2017 18:13:43 -0800 (PST) > hughaguilar96@gmail.com wrote: > >> On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote: > >>> Coding style may influence this. For SwiftForth 0= IF NOT IF >>> appear 200 times compared to ?EXIT (151) EXIT-THEN (227). >>> >>> Numbers matter but decisions are made on less. Take ANS words NIP >>> and TUCK. SwiftForth: NIP (158) TUCK (56) >>> NIP and TUCK are conveniences - additions to the language that don't >>> fundamentally change anything. >> >> ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and >> knew essentially nothing about code optimization. >> >> NIP is the same as: SWAP DROP >> TUCK is the same as: SWAP OVER > > NIP and TUCK are prime examples of why I said your <SWITCH wouldn't be > used. I made a similar point to Anton about his superinstructions some > years ago (or perhaps it was superoperators or some similar concept...). > If you look at the counts for NIP and TUCK and compare them to those > posted by Marcel for various word combinations, NIP and TUCK aren't > used that much by anyone. This is because they're simply of low need, > not in widespread use anywhere, and they weren't standard for a long > time. > >> In a non-optimizing compiler, making NIP and TUCK into primitives >> (written in assembly-language) causes them to execute about twice as >> fast as having two primitives compiled (either SWAP DROP or SWAP OVER >> for NIP and TUCK respectively). > > Why should anyone implement infrequently executed words as primitives? The argument was about how frequently programmers write certain words or phrases. Their execution frequency is another matter, as is their overall effect on an application's performance. > If you're going to implement them as primitives, i.e., you don't care > about optimizing your time or investment, you might as well go ahead and > implement all Forth words as primitives. > > > Rod Pemberton > -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-02-11 11:28 -1000 |
| Message-ID | <-9WdneZj9upxHALFnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #54790 |
On 2/11/17 3:16 AM, Alex wrote: > On 2/11/2017 12:55, Rod Pemberton wrote: >> On Fri, 10 Feb 2017 18:13:43 -0800 (PST) >> hughaguilar96@gmail.com wrote: >> >>> On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote: >> >>>> Coding style may influence this. For SwiftForth 0= IF NOT IF >>>> appear 200 times compared to ?EXIT (151) EXIT-THEN (227). >>>> >>>> Numbers matter but decisions are made on less. Take ANS words NIP >>>> and TUCK. SwiftForth: NIP (158) TUCK (56) >>>> NIP and TUCK are conveniences - additions to the language that don't >>>> fundamentally change anything. >>> >>> ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and >>> knew essentially nothing about code optimization. >>> >>> NIP is the same as: SWAP DROP >>> TUCK is the same as: SWAP OVER >> >> NIP and TUCK are prime examples of why I said your <SWITCH wouldn't be >> used. I made a similar point to Anton about his superinstructions some >> years ago (or perhaps it was superoperators or some similar concept...). >> If you look at the counts for NIP and TUCK and compare them to those >> posted by Marcel for various word combinations, NIP and TUCK aren't >> used that much by anyone. This is because they're simply of low need, >> not in widespread use anywhere, and they weren't standard for a long >> time. >> >>> In a non-optimizing compiler, making NIP and TUCK into primitives >>> (written in assembly-language) causes them to execute about twice as >>> fast as having two primitives compiled (either SWAP DROP or SWAP OVER >>> for NIP and TUCK respectively). >> >> Why should anyone implement infrequently executed words as primitives? > > The argument was about how frequently programmers write certain words or > phrases. Their execution frequency is another matter, as is their > overall effect on an application's performance. One could argue that if NIP and TUCK were primitives, and hence didn't have the overhead of an extra layer, they would be more widely used. But the fact is, most programmers I know just don't think of them. >> If you're going to implement them as primitives, i.e., you don't care >> about optimizing your time or investment, you might as well go ahead and >> implement all Forth words as primitives. No, that doesn't follow. It's worth coding words that are simple as primitives when they're widely used, and the effort is not great because they're simple. It's also worth coding words that can affect performance, such as screen and disk I/O (though that's fading as rotating media disappears). Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web