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 1 of 14 [1] 2 3 … 14 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-17 12:17 +1100 |
| Subject | EXIT THEN |
| Message-ID | <o5jrct$1r41$1@gioia.aioe.org> |
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
[toc] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-16 18:27 -0800 |
| Message-ID | <27ef3706-6a0c-4c97-9fec-1ccebbe9c172@googlegroups.com> |
| In reply to | #54064 |
On Monday, January 16, 2017 at 6:18:25 PM UTC-7, 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 Alternatively: macro: end exit then ; I can put this in the novice-package --- I'm okay with it. :-)
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2017-01-16 18:28 -0800 |
| Message-ID | <40682dd5-ba45-4b07-bd5c-7974b1119e78@googlegroups.com> |
| In reply to | #54064 |
El lunes, 16 de enero de 2017, 22:18:25 (UTC-3), HAA escribió: > 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 Charles Moore say in firechat (I not remember when) ColorForth not have ELSE because this produce better factorization.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-16 20:56 -0800 |
| Message-ID | <42c0521f-942a-43ca-8a08-2381f93b0a13@googlegroups.com> |
| In reply to | #54066 |
On Monday, January 16, 2017 at 7:28:27 PM UTC-7, Pablo Hugo Reda wrote: > El lunes, 16 de enero de 2017, 22:18:25 (UTC-3), HAA escribió: > > 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 > > Charles Moore say in firechat (I not remember when) ColorForth not have ELSE because this produce better factorization. I rarely use CASE --- more common is for me factor out the conditional structure and then use IF ... EXIT THEN for each conditional --- this is more robust than CASE because I can test for something other than integer equality. I agree that IF ... ELSE ... THEN is like a miniature CASE --- this can also be factored out similarly. CASE is one of the major blunders in ANS-Forth design --- the standard is supposed to standardize behavior rather than implementation --- CASE has to be nested IF statements though, which is horribly inefficient. I has to be nested IF statements because the possibility of having two conditionals for the same value wasn't explicitly disallowed. CASE is also complicated --- I can't remember how it works without looking it up in the document --- I don't like it. If CASE allowed a jump table, then it would be possible to write an interpreter for a byte-code VM much more cleanly --- as it is, a jump-table has to be manually constructed, which is very bloaty --- also, a jump-table should be written in assembly-language for speed, which of course kills portability. ANS-Forth needed to be designed to have the same features as C --- this should have been a basic goal --- then the other features, such as meta-compiling, would have put Forth beyond C. ANS-Forth screwed up everything --- it compared badly to C, and it killed UR/Forth which was competitive with C in regard to speed, leaving only PolyForth which compared badly to QBASIC --- this is why Forth died.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-19 13:05 +1100 |
| Message-ID | <o5p6rl$2k0$2@gioia.aioe.org> |
| In reply to | #54068 |
hughaguilar96@gmail.com wrote:
> ...
> CASE is also complicated --- I can't remember how it works without looking it up in the
> document --- I don't like it.
Wil Baden also thought CASE too complicated and restrictive preferring a
DIY approach where programmers 'roll their own' using a few primitives. E.g.
: end-of-line? ( char -- 2|1|0 )
$0D of 2 end
$0A of 1 end
drop 0 ;
This is more flexible and faster than ANS CASE which requires OF be used
with ENDOF that compiles a jump whether you needed it or not. Just one of
the reasons I'm not in favor of standards.
> ...
> Here are correct versions:
>
> : end1 postpone exit postpone then ; immediate ok
> : end2 s" exit then" evaluate ; immediate ok
> : ttt1 if 5 . end1 6 . ; ok
> : ttt2 if 5 . end2 6 . ; ok
> 1 ttt1 5 ok
> 0 ttt1 6 ok
> 1 ttt2 5 ok
> 0 ttt2 6 ok
Thanks for spotting the bug.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-18 23:29 -0500 |
| Message-ID | <o5pf83$3eq$1@dont-email.me> |
| In reply to | #54139 |
On 1/18/2017 9:05 PM, HAA wrote:
> hughaguilar96@gmail.com wrote:
>> ...
>> CASE is also complicated --- I can't remember how it works without looking it up in the
>> document --- I don't like it.
>
> Wil Baden also thought CASE too complicated and restrictive preferring a
> DIY approach where programmers 'roll their own' using a few primitives. E.g.
>
> : end-of-line? ( char -- 2|1|0 )
> $0D of 2 end
> $0A of 1 end
> drop 0 ;
>
> This is more flexible and faster than ANS CASE which requires OF be used
> with ENDOF that compiles a jump whether you needed it or not. Just one of
> the reasons I'm not in favor of standards.
How is case restrictive exactly? Won't case do this just as well?
: end-of-line? ( char -- 2|1|0 )
case
$0D of 2 endof
$0A of 1 endof
0 swap
endcase
;
I don't code Forth enough to know for sure I am using the CASE statement
correctly, but this did work when I tested it.
So is this really so bad? The above method only works if the alternate
CASE structure is the last thing in the word.
--
Rick C
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-20 11:46 +1100 |
| Message-ID | <o5rmih$7r0$1@gioia.aioe.org> |
| In reply to | #54144 |
rickman wrote: > On 1/18/2017 9:05 PM, HAA wrote: > > hughaguilar96@gmail.com wrote: > >> ... > >> CASE is also complicated --- I can't remember how it works without looking it up in > >> the document --- I don't like it. > > > > Wil Baden also thought CASE too complicated and restrictive preferring a > > DIY approach where programmers 'roll their own' using a few primitives. E.g. > > > > : end-of-line? ( char -- 2|1|0 ) > > $0D of 2 end > > $0A of 1 end > > drop 0 ; > > > > This is more flexible and faster than ANS CASE which requires OF be used > > with ENDOF that compiles a jump whether you needed it or not. Just one of > > the reasons I'm not in favor of standards. > > How is case restrictive exactly? Won't case do this just as well? > > : end-of-line? ( char -- 2|1|0 ) > case > $0D of 2 endof > $0A of 1 endof > 0 swap > endcase > ; ENDOF is functionally equivalent to ELSE so you generate a jump to the point after ENDCASE instead of exiting immediately. Most case usage is complex enough that it warrants a separate definition making the 'jump to the end' an unnecessary action. To support these superfluous jumps you also needed the words CASE and ENDCASE. The first version is not only more direct in its execution and therefore more efficient, it's simpler to write. It's an example of 'ELSE elimination' mentioned elsewhere. Unfortunately in order to be compatible with 'everybody's CASE', ANS CASE had to be specified in a way that prevents such optimizations. In theory an ANS program could define a word similar to my OF but that doesn't help me. It wouldn't be as efficient as the one I already have.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-19 22:28 -0500 |
| Message-ID | <o5s01m$2ps$1@dont-email.me> |
| In reply to | #54188 |
On 1/19/2017 7:46 PM, HAA wrote: > rickman wrote: >> On 1/18/2017 9:05 PM, HAA wrote: >>> hughaguilar96@gmail.com wrote: >>>> ... >>>> CASE is also complicated --- I can't remember how it works without looking it up in >>>> the document --- I don't like it. >>> >>> Wil Baden also thought CASE too complicated and restrictive preferring a >>> DIY approach where programmers 'roll their own' using a few primitives. E.g. >>> >>> : end-of-line? ( char -- 2|1|0 ) >>> $0D of 2 end >>> $0A of 1 end >>> drop 0 ; >>> >>> This is more flexible and faster than ANS CASE which requires OF be used >>> with ENDOF that compiles a jump whether you needed it or not. Just one of >>> the reasons I'm not in favor of standards. >> >> How is case restrictive exactly? Won't case do this just as well? >> >> : end-of-line? ( char -- 2|1|0 ) >> case >> $0D of 2 endof >> $0A of 1 endof >> 0 swap >> endcase >> ; > > ENDOF is functionally equivalent to ELSE so you generate a jump to the > point after ENDCASE instead of exiting immediately. Most case usage is > complex enough that it warrants a separate definition making the 'jump > to the end' an unnecessary action. To support these superfluous jumps > you also needed the words CASE and ENDCASE. I think that is an opinion rather than a fact. If you encapsulate the case in a word just "because" you are adding both a call and a return. That is a lot more superfluous than the ENDOF. I found seven uses of CASE in the test code I wrote and maintain. Two of them have short code after the CASE statement. So in those "cases" (pun intended) making the case a word would have added a needless word. Still, my point is I don't count bytes in my code when I'm writing it. I write code to be simple to read and understand when I return to it months later. If I write a CASE using END and find I want to add a bit of code to the end of the word I would either need to add a word to encapsulate the CASE word or I'd have to edit the CASE structure to the ENDOF format. It's not worth the bother to me to save that little bit of efficiency when I'm running on a PC with GB of RAM. > The first version is not only more direct in its execution and therefore more > efficient, it's simpler to write. It's an example of 'ELSE elimination' mentioned > elsewhere. Unfortunately in order to be compatible with 'everybody's CASE', > ANS CASE had to be specified in a way that prevents such optimizations. > In theory an ANS program could define a word similar to my OF but that > doesn't help me. It wouldn't be as efficient as the one I already have. I think you mean END rather than OF, no? That may be more "efficient" in terms of ram usage or speed, but ***who cares***??? I don't write programs that bring my computer to its knees. I can't remember the last time I even looked to see the size of a program I wrote other than perhaps lines of source. Using END is less efficient in terms of my usage of the language. The entire concept of structured programming is *less* efficient by many measures. But it has advantages in many ways and "efficiency" seldom matters. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-22 18:45 -0800 |
| Message-ID | <b38b2e31-f8aa-43a3-9993-ab0687bd42a1@googlegroups.com> |
| In reply to | #54139 |
On Wednesday, January 18, 2017 at 7:04:41 PM UTC-7, HAA wrote:
> hughaguilar96@gmail.com wrote:
> > ...
> > CASE is also complicated --- I can't remember how it works without looking it up in the
> > document --- I don't like it.
>
> Wil Baden also thought CASE too complicated and restrictive preferring a
> DIY approach where programmers 'roll their own' using a few primitives. E.g.
>
> : end-of-line? ( char -- 2|1|0 )
> $0D of 2 end
> $0A of 1 end
> drop 0 ;
>
> This is more flexible and faster than ANS CASE which requires OF be used
> with ENDOF that compiles a jump whether you needed it or not. Just one of
> the reasons I'm not in favor of standards.
How about this for readability?
macro: <of over = if drop ; ok
macro: of> exit then ; ok
: end-of-line? ( char -- 2|1|0 )
13 <of 2 of>
10 <of 1 of>
drop 0 ; ok
13 end-of-line? . 2 ok
12 end-of-line? . 0 ok
10 end-of-line? . 1 ok
But this assumes that we are testing integers. Will we need another set of macros for strings, and another set for floats?
If we are going to only support integers, then we should write something that builds a jump-table --- I have been assuming that this would need to be written in assembly-language --- it might be possible in ANS-Forth though.
I recommend that you not waste your time with this END proposal which is rather trivial (not quite the "game changer" that you make it out to be) --- write a jump-table builder that could be used for simulating a VM --- that would be useful; I would put that in the novice-package! :-)
I will give some thought to the subject --- if you beat me to coming up with a solution, then good for you --- I want people to make contributions to the novice-package (I had originally envisioned it being mostly other people's contributions; I had not foreseen that I would be attacked for the novice-package and that Elizabeth Rather would say that I'm not a Forth programmer because of it).
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-25 09:57 +1100 |
| Message-ID | <o68m31$1g3n$1@gioia.aioe.org> |
| In reply to | #54266 |
hughaguilar96@gmail.com wrote: > On Wednesday, January 18, 2017 at 7:04:41 PM UTC-7, HAA wrote: > > hughaguilar96@gmail.com wrote: > > > ... > > > CASE is also complicated --- I can't remember how it works without looking it up in > > > the document --- I don't like it. > > > > Wil Baden also thought CASE too complicated and restrictive preferring a > > DIY approach where programmers 'roll their own' using a few primitives. E.g. > > > > : end-of-line? ( char -- 2|1|0 ) > > $0D of 2 end > > $0A of 1 end > > drop 0 ; > > > > This is more flexible and faster than ANS CASE which requires OF be used > > with ENDOF that compiles a jump whether you needed it or not. Just one of > > the reasons I'm not in favor of standards. > > How about this for readability? > > macro: <of over = if drop ; ok > macro: of> exit then ; ok > : end-of-line? ( char -- 2|1|0 ) > 13 <of 2 of> > 10 <of 1 of> > drop 0 ; ok > 13 end-of-line? . 2 ok > 12 end-of-line? . 0 ok > 10 end-of-line? . 1 ok A macro version of OF is fine for portability but not necessarily for efficiency. From my pov OF already exists and should be implemented in a way that isn't restrictive. END has no efficiency issue so it's a case of pick your poison - macro or postpone. > I recommend that you not waste your time with this END proposal which is rather trivial > (not quite the "game changer" that you make it out to be) Trivial but everywhere. What substantive Forth program doesn't have EXIT THEN in them? I just converted an editor with three case statements as above. 30 instances of EXIT THEN were replaced with END and the code looks a lot better for it. Anything that makes me proud to display Forth code - I don't consider a waste of my time.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2017-01-25 23:56 -0800 |
| Message-ID | <ac62337f-01ff-4991-8eb6-f9c20e8ee77a@googlegroups.com> |
| In reply to | #54068 |
I've just realised why OF isn't necessarily just a synonym of OVER = IF (that has bugged me for years). CASE can compile a jump table thus: OF checks if the selector if a constant If is is, OF ... ENDOF compiles a quotation and remembers it and the selector If the selector is the same as an existing constant it is ignored (the code is unreachable) Otherwise or at ENDCASE It checks for existing selector/quotation pairs and compiles a suitable table.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-26 03:35 -0600 |
| Message-ID | <gNOdne5hOIdpXxTFnZ2dnUU7-IOdnZ2d@supernews.com> |
| In reply to | #54410 |
JennyB <jennybrien@googlemail.com> wrote: > I've just realised why OF isn't necessarily just a synonym of OVER = IF (that has bugged me for years). > > CASE can compile a jump table thus: > > OF checks if the selector if a constant > If is is, OF ... ENDOF compiles a quotation and remembers it and the selector > If the selector is the same as an existing constant it is ignored (the code is unreachable) > > Otherwise or at ENDCASE > It checks for existing selector/quotation pairs and compiles a suitable table. It can do that even if OF is a synonym for OVER = IF . And ENDOF is a synonym for ELSE. Which it damn well should be, IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-01-26 11:31 +0100 |
| Message-ID | <pl2kuicwtud7.1528s0g2pjof9.dlg@40tude.net> |
| In reply to | #54414 |
Op Thu, 26 Jan 2017 03:35:48 -0600 schreef Andrew Haley: > JennyB <jennybrien@googlemail.com> wrote: >> I've just realised why OF isn't necessarily just a synonym of OVER = IF (that has bugged me for years). >> >> CASE can compile a jump table thus: >> >> OF checks if the selector if a constant >> If is is, OF ... ENDOF compiles a quotation and remembers it and the selector >> If the selector is the same as an existing constant it is ignored (the code is unreachable) >> >> Otherwise or at ENDCASE >> It checks for existing selector/quotation pairs and compiles a suitable table. > > It can do that even if OF is a synonym for OVER = IF . And ENDOF is a > synonym for ELSE. Which it damn well should be, IMO. > > Andrew. OF is a synonym of OVER = IF DROP My OF can be used since some odd decades like IF outside CASE .. ENDCASE and be terminated by ELSE or THEN groet Coos
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-26 11:07 +0000 |
| Message-ID | <2017Jan26.120712@mips.complang.tuwien.ac.at> |
| In reply to | #54414 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>It can do that even if OF is a synonym for OVER = IF . And ENDOF is a
>synonym for ELSE. Which it damn well should be, IMO.
The CASE implementation in
<http://theforth.net/package/compat/current-view/caseext.fs>, which is
the implementation in the development version of Gforth, has:
: endof ( compilation case-sys1 of-sys -- case-sys2 ; run-time -- ) \ core-ext end-of
\g Exit the enclosing @code{case} structure by jumping behind
\g @code{endcase}/@code{next-case}.
postpone else 1 cs-roll ; immediate compile-only
The reason for the "1 CS-ROLL" is that this CASE implementation
supports CONTOF (to replace ENDOF) and NEXT-CASE (to replace ENDCASE),
both of which loop back to CASE.
Note that this implementation satisfies the requirements of the
standard, in contrast to the implementation in appendix A.3.2.3.2 of
the standard.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-05 19:15 +1100 |
| Message-ID | <o76msk$1098$1@gioia.aioe.org> |
| In reply to | #54419 |
Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> >It can do that even if OF is a synonym for OVER = IF . And ENDOF is a
> >synonym for ELSE. Which it damn well should be, IMO.
>
> The CASE implementation in
> <http://theforth.net/package/compat/current-view/caseext.fs>, which is
> the implementation in the development version of Gforth, has:
>
>
> : endof ( compilation case-sys1 of-sys -- case-sys2 ; run-time -- ) \ core-ext end-of
> \g Exit the enclosing @code{case} structure by jumping behind
> \g @code{endcase}/@code{next-case}.
> postpone else 1 cs-roll ; immediate compile-only
>
> The reason for the "1 CS-ROLL" is that this CASE implementation
> supports CONTOF (to replace ENDOF) and NEXT-CASE (to replace ENDCASE),
> both of which loop back to CASE.
>
> Note that this implementation satisfies the requirements of the
> standard, in contrast to the implementation in appendix A.3.2.3.2 of
> the standard.
>
> - anton
I would just write:
begin
n1 of ... end
n2 of ... end
condition if ... end
again
It's 2017. Not 1994 when nobody knew any better.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-07 17:54 +0000 |
| Message-ID | <2017Feb7.185415@mips.complang.tuwien.ac.at> |
| In reply to | #54636 |
"HAA" <someone@microsoft.com> writes:
>I would just write:
>
>begin
> n1 of ... end
> n2 of ... end
> condition if ... end
>again
Interestingly, I had to look at this for quite a while to understand
that; despite this END being discussed recently and quite at length
here, the usage here just slipped past my radar. That might change if
it catches on, but I don't see it as beneficial enough to justify the
transition cost.
That being said, I like the general concept better than ?EXIT, because
there often is cleanup work that has to be done before EXITing, so
?EXIT is really wrong factoring, but at least the ?EXIT name does not
need any getting-used to in order to see what's going on.
Which brings me to the benefits of using THROW. THROW does the stack
and DO..LOOP cleanup by itself, and that really lowers the programming
burden. E.g., if you have
IF 2drop rdrop true EXIT THEN
or
IF nip nip unloop exit THEN
(taken from real code), you first have to write this code to clean up
the stacks, and when you change something in the word, you may have to
update it. By contrast, when you exit with
( flag ) condition# and throw
all that goes away, and you can mostly think about the word (or at
least that part of the word) as if you were dealing with straight-line
code. Another advantage is that, like straight-line code, you can
factor parts of the code (including the THROW) out into separate
words, unlike code containing EXIT.
The downsides are that you need to CATCH the conditions, and that
CATCH and THROW are typically not the fastest words around around.
>It's 2017. Not 1994 when nobody knew any better.
I don't see that using EXIT THEN or a macro for it is anything that we
learned after 1994.
- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-07 21:14 +0000 |
| Message-ID | <o7dd89$99l$1@dont-email.me> |
| In reply to | #54690 |
On 2/7/2017 17:54, Anton Ertl wrote:
>
> Which brings me to the benefits of using THROW. THROW does the stack
> and DO..LOOP cleanup by itself, and that really lowers the programming
> burden. E.g., if you have
>
> IF 2drop rdrop true EXIT THEN
> or
> IF nip nip unloop exit THEN
>
> (taken from real code), you first have to write this code to clean up
> the stacks, and when you change something in the word, you may have to
> update it. By contrast, when you exit with
>
> ( flag ) condition# and throw
>
> all that goes away, and you can mostly think about the word (or at
> least that part of the word) as if you were dealing with straight-line
> code. Another advantage is that, like straight-line code, you can
> factor parts of the code (including the THROW) out into separate
> words, unlike code containing EXIT.
This was exactly the technique I used in Win32Forth to support (pre the
recognizer proposal) a stack of number conversion words. Each attempts
to convert the number, and on failure, THROWs. CATCH then attempts the
next in the list until the list is exhausted, when we issue -13 THROW
(not found).
Much easier than having to stack balance; apropos the recognizer
proposal, it's a better technique IMHO than expensive stack cleaning and
returning R:FAIL.
>
> The downsides are that you need to CATCH the conditions, and that
> CATCH and THROW are typically not the fastest words around around.
They're not desperately expensive if assembler is used. The register
usage is not material, but it is worth noting that a non-zero THROW
fiddles with the return stack, which might cause slowdowns on processors
that are sensitive to RETs not matched with calls.
code catch ( xt -- flag )
mov ecx eax ( save xt )
push ebp \ sp@ >r
push { handler ebx } \ handler @ >r
mov { handler ebx } esp \ rp @ handler !
mov eax { ebp } ( drop xt )
add ebp cell
call ecx \ execute
mov { -cell ebp } eax
pop { handler ebx } \ r> handler !
sub ebp cell
add esp cell ( junk old ebp )
xor eax eax \ 0
ret end-code
code throw ( n -- )
test eax eax \ ?dup if
jz ' drop ( drop if zero )
mov esp { handler ebx } \ handler @ rp!
pop { handler ebx } \ r> handler !
pop ebp \ r> swap >r sp! drop r>
ret end-code
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-13 16:52 +0000 |
| Message-ID | <2017Feb13.175259@mips.complang.tuwien.ac.at> |
| In reply to | #54694 |
Alex <alex@rivadpm.com> writes:
>On 2/7/2017 17:54, Anton Ertl wrote:
>
>>
>> Which brings me to the benefits of using THROW. THROW does the stack
>> and DO..LOOP cleanup by itself, and that really lowers the programming
>> burden. E.g., if you have
>>
>> IF 2drop rdrop true EXIT THEN
>> or
>> IF nip nip unloop exit THEN
>>
>> (taken from real code), you first have to write this code to clean up
>> the stacks, and when you change something in the word, you may have to
>> update it. By contrast, when you exit with
>>
>> ( flag ) condition# and throw
>>
>> all that goes away, and you can mostly think about the word (or at
>> least that part of the word) as if you were dealing with straight-line
>> code. Another advantage is that, like straight-line code, you can
>> factor parts of the code (including the THROW) out into separate
>> words, unlike code containing EXIT.
>
>This was exactly the technique I used in Win32Forth to support (pre the
>recognizer proposal) a stack of number conversion words. Each attempts
>to convert the number, and on failure, THROWs. CATCH then attempts the
>next in the list until the list is exhausted, when we issue -13 THROW
>(not found).
>
>Much easier than having to stack balance; apropos the recognizer
>proposal, it's a better technique IMHO than expensive stack cleaning and
>returning R:FAIL.
Matthias Trute gives a pretty convincing comparison of R:FAIL
vs. returning 0 in his proposal. Work out an example (maybe the same
one) with a alternative based on THROW. Maybe you can convince us
all.
>> The downsides are that you need to CATCH the conditions, and that
>> CATCH and THROW are typically not the fastest words around around.
>
>They're not desperately expensive if assembler is used.
They are not very expensive in any case. Definitely cheap enough for
most situations, and one can eliminate them in the few inner loops if
needed. Or one could have compilers that understand enough about them
to make even code that uses CATCH and THROW in a statically analysable
way as fast as code that does not use CATCH and THROW.
>The register
>usage is not material, but it is worth noting that a non-zero THROW
>fiddles with the return stack, which might cause slowdowns on processors
>that are sensitive to RETs not matched with calls.
That would be a good reason to have such compilers that know how to
optimize CATCH and THROW.
I think that another reason why this technique sees little use is that
the CATCHing part is relatively cumbersome to write. Maybe by writing
some convenience words that can be addressed:
-4000 constant local-exception
: ?lthrow ( flag -- )
0<> local-exception and throw ;
: lcatch ( ... xt -- ... n )
catch dup local-exception <> and ;
: lexec ( ... xt -- ... )
\ xt has to have a neutral stack effect
lcatch throw ;
LCATCH would be mostly used like CATCH, and LEXEC mostly like EXECUTE.
One would use LCATCH for cleaning up non-stack stuff before
rethrowing, like (in my experience) most uses of CATCH.
LCATCH and LEXEC does not provide information about which way exit
from xt was taken, but I think that's the right way. Otherwise the
catching word becomes too complicated, and in any case, it makes
little sense to join the control flow in this way and then split it up
again.
A use of such words might look like:
[: some-condition ?lthrow
another-condition ?lthrow
yet-another-condition ?lthrow
do-something
;] lexec
This would replace something like
some-condition 0= if
another-condition 0= if
yet-another-condition 0= if
do-something
else
yet-another-cleanup
then
else
another-cleanup
then
else
some-cleanup
then
or its alternative
[: some-condition if
some-cleanup exit then
another-condition if
another-cleanup exit then
yet-another-condition if
yet-another-cleanup exit then
do-something
;]
- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-15 23:49 +0000 |
| Subject | Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <o82pb4$a1v$1@dont-email.me> |
| In reply to | #54841 |
On 2/13/2017 16:52, Anton Ertl wrote:
>> Much easier than having to stack balance; apropos the recognizer
>> proposal, it's a better technique IMHO than expensive stack cleaning and
>> returning R:FAIL.
> Matthias Trute gives a pretty convincing comparison of R:FAIL
> vs. returning 0 in his proposal. Work out an example (maybe the same
> one) with a alternative based on THROW. Maybe you can convince us
> all.
>
This uses the example from the appendix of
http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf
First, we remove the definition of DT:NULL and replace it with DT:FAIL;
: DT:FAIL -13 THROW ;
The example uses a float conversion:
: REC:FLOAT ( addr len -- DT:FLOAT | DT:NULL ) ( F: -- f )
>FLOAT IF DT:FLOAT ELSE DT:NULL THEN ;
: REC:FLOAT ( addr len -- DT:FLOAT ) ( F: -- f )
>FLOAT IF DT:FLOAT ELSE DT:FAIL THEN ;
There is no effective difference between the two, since the stack is
unperturbed. Here's a toy example where the stack cleanup to provide a
DT:NULL adds to the clutter:
: REC:NUM ( addr len -- d DT:NUM | DT:NULL )
0 0 2SWAP >NUMBER IF DROP 2DROP DT:NULL ELSE DROP DT:NUM THEN ;
: REC:NUM ( addr len -- d DT:NUM )
0 0 2SWAP >NUMBER IF DT:FAIL ELSE DROP DT:NUM THEN ;
The DT:FAIL version is shorter, in that it simply junks the stack and
the rstack, which would require R> DROPs, later & automatically in the
CATCHing word rather than in the recognizer.
The only other changes in the proposal are to RECOGNIZE:
: RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN | DT:NULL )
DUP >R @
BEGIN
DUP
WHILE
DUP CELLS R@ + @
2OVER 2>R SWAP 1- >R
EXECUTE DUP
DT:NULL <> IF
2R> 2DROP 2R> 2DROP EXIT
THEN
DROP R> 2R> ROT
REPEAT
DROP 2DROP R> DROP
DT:NULL ;
: RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN )
DUP >R @
BEGIN
DUP
WHILE
DUP CELLS R@ + @
2OVER 2>R SWAP 1- >R
CATCH 0= IF
2R> 2DROP 2R> 2DROP EXIT
THEN
DROP R> 2R> ROT
REPEAT
DT:FAIL ;
In RECOGNIZE the CATCH 0= replaces EXECUTE DUP DT:NULL <>
and DT:FAIL replaces DROP 2DROP R> DROP DT:NULL
All this assumes that the interpreter has a CATCH of last resort that
prints a suitable not found.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-02-16 14:41 +0000 |
| Subject | Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] |
| Message-ID | <o84dir$kc3$1@dont-email.me> |
| In reply to | #54872 |
On 2/15/2017 23:49, Alex wrote: > On 2/13/2017 16:52, Anton Ertl wrote: >>> Much easier than having to stack balance; apropos the recognizer >>> proposal, it's a better technique IMHO than expensive stack cleaning and >>> returning R:FAIL. > >> Matthias Trute gives a pretty convincing comparison of R:FAIL >> vs. returning 0 in his proposal. Work out an example (maybe the same >> one) with a alternative based on THROW. Maybe you can convince us >> all. >> > > This uses the example from the appendix of > http://amforth.sourceforge.net/pr/Recognizer-rfc-D.pdf > > First, we remove the definition of DT:NULL and replace it with DT:FAIL; > > : DT:FAIL -13 THROW ; > > The example uses a float conversion: > > : REC:FLOAT ( addr len -- DT:FLOAT | DT:NULL ) ( F: -- f ) > >FLOAT IF DT:FLOAT ELSE DT:NULL THEN ; > > : REC:FLOAT ( addr len -- DT:FLOAT ) ( F: -- f ) > >FLOAT IF DT:FLOAT ELSE DT:FAIL THEN ; > > There is no effective difference between the two, since the stack is > unperturbed. Here's a toy example where the stack cleanup to provide a > DT:NULL adds to the clutter: > > : REC:NUM ( addr len -- d DT:NUM | DT:NULL ) > 0 0 2SWAP >NUMBER IF DROP 2DROP DT:NULL ELSE DROP DT:NUM THEN ; > > : REC:NUM ( addr len -- d DT:NUM ) > 0 0 2SWAP >NUMBER IF DT:FAIL ELSE DROP DT:NUM THEN ; > > The DT:FAIL version is shorter, in that it simply junks the stack and > the rstack, which would require R> DROPs, later & automatically in the > CATCHing word rather than in the recognizer. > > The only other changes in the proposal are to RECOGNIZE: > > : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN | DT:NULL ) > DUP >R @ > BEGIN > DUP > WHILE > DUP CELLS R@ + @ > 2OVER 2>R SWAP 1- >R > EXECUTE DUP > DT:NULL <> IF > 2R> 2DROP 2R> 2DROP EXIT > THEN > DROP R> 2R> ROT > REPEAT > DROP 2DROP R> DROP > DT:NULL ; > > : RECOGNIZE ( addr len stack-id -- i*x DT:TOKEN ) > DUP >R @ > BEGIN > DUP > WHILE > DUP CELLS R@ + @ > 2OVER 2>R SWAP 1- >R > CATCH 0= IF > 2R> 2DROP 2R> 2DROP EXIT > THEN > DROP R> 2R> ROT I think this may need to be 2DROP R> 2R> ROT. It's untested. > REPEAT > DT:FAIL ; > > In RECOGNIZE the CATCH 0= replaces EXECUTE DUP DT:NULL <> > and DT:FAIL replaces DROP 2DROP R> DROP DT:NULL > > All this assumes that the interpreter has a CATCH of last resort that > prints a suitable not found. > The advantages are: 1. The code required for each REC:x is shorter and easier to code in the failure case. There may be multiple DT:NULL exits required in more complex REC:x cases. There are no issues about stack or rstack cleanup, since it's handled in THROW/CATCH. The REC:x word does not have variable stack effects of ( i*x DT:something | DT:NULL ). 2. Should the conversion fail for any other reason (bug, complexity) then the whole system doesn't crash; the error is isolated to the REC:x word in question. Neutral: 3. The advantage fo RECOGNIZE being shorter is not that material, since it's probably only written once. Downsides: 4. Requires the EXCEPTION wordset. But then: 5. This could be provided as an alternative implementation for REC:x words; cleaning the stacks and returning DT:NULL is exactly equivaent to cleaning the stacks and having DT:NULL do a -13 THROW. As long as RECOGNIZE is set up to handle it, the REC:x programmer need not account for what DT:NULL does. -- Alex
[toc] | [prev] | [next] | [standalone]
Page 1 of 14 [1] 2 3 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web