Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58987 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-05-10 08:21 -0700 |
| Last post | 2017-05-15 11:23 +0000 |
| Articles | 20 on this page of 215 — 25 participants |
Back to article view | Back to comp.lang.forth
Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:30 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-29 21:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:12 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 08:09 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 14:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 16:27 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-31 12:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 08:40 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 06:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 13:16 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:15 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 11:49 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 16:42 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:19 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 14:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-02 12:26 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-02 13:16 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-03 01:34 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-03 02:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 22:31 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 08:03 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-02 15:16 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 14:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 07:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 14:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-01 16:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 17:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 18:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 19:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 19:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
WRAP...END-WRAP (was: Would ?EXIT work ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 15:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-29 08:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 11:14 +1000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 14:40 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:55 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-31 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 12:01 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:17 -0500
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 22:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:51 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:20 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-02 13:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 08:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-06-02 11:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 19:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:29 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 21:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-04 22:52 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 22:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 07:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 08:39 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 13:47 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:36 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-04 17:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:28 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 15:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 09:36 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-05 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 10:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? JennyB <jennybrien@googlemail.com> - 2017-06-05 13:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-07 12:42 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 20:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:45 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 19:21 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:19 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 06:50 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
Re: READ-FILE over-specified? hughaguilar96@gmail.com - 2017-05-28 21:58 -0700
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-30 11:06 +1000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 05:20 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:29 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 09:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-16 10:28 +0000 |
| Message-ID | <2017May16.122829@mips.complang.tuwien.ac.at> |
| In reply to | #59360 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Forth's CATCH/THROW is the lightest-weight exception-handling
>mechanism that I've seen, but it's still heavier than EXIT, which is
>(almost) the lightest-weight subroutine return mechanism I've ever
>seen. Having siad that, it's difficult for an analytical Forth
>compiler to optimize CATCH and THROW: I don't know if any of them
>attempt it.
CATCH is easier for an analytical compiler (that analyses beyond basic
blocks) than R> DROP: you don't need to know where the THROW is coming
from to know the stack effect of the CATCH; you still need to know the
stack effect for the regular exit, but that's the same as for a
regular call.
For non-zero THROW, the way I use it would be relatively simple to
implement: only the TOS needs to be passed to the CATCH. However, the
standard describes it in terms of adjusting the stack depth, so if any
value below the CATCH depth was changed in between, this value is
specified in that case, too. Does anyone make use of this feature?
Concerning converting a statically predictable THROW into a
jump-with-extras, that's also possible, but requires similar effort to
optimizing a statically analyzable use of return-address manipulation.
The benefit of CATCH...THROW in that context is when we are not able
to statically analyze it: CATCH...THROW is relatively benign, whereas
with return-address manipulation every EXECUTE or deferred word can
result in arbitrary things happening to the return stack.
>Also, there is a philosophical objection to using THROW in anything
>other than exceptional circumstances.
If we can use return-address manipulation in non-exceptional
circumstances, why balk at THROW?
>In many languages this leads to
>throwing an exception being very slow. (That's a property of the
>implementation, but it's also the product of an attitude.)
You have a feedback loop in such things. But implementation comes
first: gcc now implements some cases of memcpy() in an efficient way,
and advocates its usage, so people start using it for these cases,
even those (like me) who think that this is the wrong way to solve the
problem.
>And
>exceptions can be very hard to debug.
Why do you think so? I have not had problems with them yet. On the
contrary, I have had problems with code where THROW may have been
appropriate, but was not used.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-16 10:43 -0500 |
| Message-ID | <W6mdnQe9aam6g4bEnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #59366 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Forth's CATCH/THROW is the lightest-weight exception-handling >>mechanism that I've seen, but it's still heavier than EXIT, which is >>(almost) the lightest-weight subroutine return mechanism I've ever >>seen. Having siad that, it's difficult for an analytical Forth >>compiler to optimize CATCH and THROW: I don't know if any of them >>attempt it. > > CATCH is easier for an analytical compiler (that analyses beyond basic > blocks) than R> DROP: Oh, for sure. > you don't need to know where the THROW is coming from to know the > stack effect of the CATCH; you still need to know the stack effect > for the regular exit, but that's the same as for a regular call. I get that, but you do have a merge point with two stack states. The easiest way to handle that is by spilling the stack state to memory. I was wondering if anyone did anything other than that. > For non-zero THROW, the way I use it would be relatively simple to > implement: only the TOS needs to be passed to the CATCH. However, the > standard describes it in terms of adjusting the stack depth, so if any > value below the CATCH depth was changed in between, this value is > specified in that case, too. Does anyone make use of this feature? I've always assumed it was bad practice. (i.e. Don't do that!) On the other hand, it's one of the ways you have of conveying more information to the caller than a throw code. > Concerning converting a statically predictable THROW into a > jump-with-extras, that's also possible, but requires similar effort > to optimizing a statically analyzable use of return-address > manipulation. The benefit of CATCH...THROW in that context is when > we are not able to statically analyze it: CATCH...THROW is > relatively benign, whereas with return-address manipulation every > EXECUTE or deferred word can result in arbitrary things happening to > the return stack. Yes, I completely agree. For comparison, we do optimize frequently- taken exceptions in Java, but that's a very unusual case: frequent throwning is often reckoned to be a sign of bad API design. >>Also, there is a philosophical objection to using THROW in anything >>other than exceptional circumstances. > > If we can use return-address manipulation in non-exceptional > circumstances, why balk at THROW? We can't do that as standard. I'm appalled at the very idea of using return-address manipulation in non-exceptional circumstances! >>In many languages this leads to throwing an exception being very >>slow. (That's a property of the implementation, but it's also the >>product of an attitude.) > > You have a feedback loop in such things. But implementation comes > first: gcc now implements some cases of memcpy() in an efficient way, > and advocates its usage, so people start using it for these cases, > even those (like me) who think that this is the wrong way to solve the > problem. > > And exceptions can be very hard to debug. > > Why do you think so? I've had some bad experiences. I once wrote a parser which handled corner cases with THROW. I (needless to say) got it wrong and found that tracing the control flow was very difficult, and the usual keyboard interaction was rather impractical. In the end, I ripped out the use of THROW for everything except an early end of stream. It might be that really good tracing tools would have solved the problem, but needing really good tracing tools is perhaps also a sign of a bad design. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-16 16:34 +0000 |
| Message-ID | <2017May16.183409@mips.complang.tuwien.ac.at> |
| In reply to | #59377 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> you don't need to know where the THROW is coming from to know the
>> stack effect of the CATCH; you still need to know the stack effect
>> for the regular exit, but that's the same as for a regular call.
>
>I get that, but you do have a merge point with two stack states. The
>easiest way to handle that is by spilling the stack state to memory.
Certainly, but that's not different than for any other control flow
join.
>I was wondering if anyone did anything other than that.
Maybe iForth. But I hope to contribute to advances in this area in
the future.
>> Concerning converting a statically predictable THROW into a
>> jump-with-extras, that's also possible, but requires similar effort
>> to optimizing a statically analyzable use of return-address
>> manipulation. The benefit of CATCH...THROW in that context is when
>> we are not able to statically analyze it: CATCH...THROW is
>> relatively benign, whereas with return-address manipulation every
>> EXECUTE or deferred word can result in arbitrary things happening to
>> the return stack.
>
>Yes, I completely agree. For comparison, we do optimize frequently-
>taken exceptions in Java, but that's a very unusual case: frequent
>throwning is often reckoned to be a sign of bad API design.
I would not draw any conclusions from Java style to Forth style. In
Forth THROW is currently not usually used for non-exceptional exits,
but that would provide advantages (that are not relevant in Java) that
I discussed in <2017Feb13.175259@mips.complang.tuwien.ac.at>.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-16 12:41 -0500 |
| Message-ID | <V_SdnQBzw5l8pIbEnZ2dnUU7-dvNnZ2d@supernews.com> |
| In reply to | #59384 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>we do optimize frequently-taken exceptions in Java, but that's a >>very unusual case: frequent throwing is often reckoned to be a sign >>of bad API design. > > I would not draw any conclusions from Java style to Forth style. In > Forth THROW is currently not usually used for non-exceptional exits, > but that would provide advantages (that are not relevant in Java) that > I discussed in <2017Feb13.175259@mips.complang.tuwien.ac.at>. Yes, I get that, and I can understand that the reasoning used there make sense. I don't think that there's anything Java-specific (or in any way language-specific) about the idea that exceptions should be exceptional. It may well be that there is something special about Forth (and there are many special things!) which means that CATCH and THROW should be used for more for things than other languages do, but right now I can't think of any reason why there might be. (Well, perhaps cost, but that strikes me as a fairly bad reason for such a design decision.) Having said that, I used CATCH and THROW to handle transaction aborts, and they worked beautifully. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-17 16:14 +0000 |
| Message-ID | <2017May17.181425@mips.complang.tuwien.ac.at> |
| In reply to | #59386 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I don't think that there's anything Java-specific (or in any way
>language-specific) about the idea that exceptions should be
>exceptional.
Sure, but does that mean that CATCH and THROW should be exceptional?
Why? Just because they were originally intended for exceptions? Not
a sufficient reason.
> It may well be that there is something special about
>Forth (and there are many special things!) which means that CATCH and
>THROW should be used for more for things than other languages do, but
>right now I can't think of any reason why there might be.
Maybe you did not get <2017Feb13.175259@mips.complang.tuwien.ac.at>
after all.
The reason is that, in Forth, you frequently have to do some sequence
of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up
no-longer needed arguments on the stacks. That's especially annoying
if you have to deal with a bunch of dependent conditions that you have
to check with ifs. You get code like:
: foo
2dup check-something if
dup >r check-something-else if
2dup fdup check-yet-another-thing if
do the thing that depends on these conditions
clean up the stacks exit then
clean up the stacks for this branch exit then
clean up the stacks for this branch exit then
clean up the stacks for this branch ;
Or you can organize this with ELSEs; or with each IF in a separate
word, with local cleanups, but possibly long stack effects. Or you
put the data in variables so that you don't have to worry about their
presence on the stacks; but wait, we are now in a multi-core world, so
we have to put it in user variables, and this local data will cost
space in every task.
Or, alternatively, you use THROW's ability to clean up all the stacks:
[: 2dup check-something ?lthrow
dup >r check-something-else ?lthrow
2dup fdup check-yet-another-thing ?throw
do the thing that depends on these conditions
clean up the stacks
;] lexec
If the "do the thing" part leaves nothing on the stack, its cleanup
can be done by an LTHROW, too.
This style allows us to think about this code linearly instead of as a
complex IF cascade, and it frees us from having to adjust one or more
else branches whenever we change something in the checks.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 03:05 -0500 |
| Message-ID | <LfSdndoSbsJHyIDEnZ2dnUU7-VPNnZ2d@supernews.com> |
| In reply to | #59436 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I don't think that there's anything Java-specific (or in any way >>language-specific) about the idea that exceptions should be >>exceptional. > > Sure, but does that mean that CATCH and THROW should be exceptional? > Why? Just because they were originally intended for exceptions? Not > a sufficient reason. Well, "exceptions should always be exceptional" is not a religious doctrine for me, so to some extent I'm only repeating what has been said by others. It's a long discussion and I'm sure you've read the points made. But THROWing does effectively bypass actions at the end of a word, and the maintenance programmer is going to have to be aware that if they need some actions to happen they're going to have to change the way they write. So, in a program which uses exceptions heavily a common pattern would change from open-action stuff close-action to open-action [: stuff ;] catch >r close-action r> throw which is more complicated. (This is a standard pattern in Java, and people sometimes forget to do it.) I'm not sure it's an improvement. >>It may well be that there is something special about Forth (and >>there are many special things!) which means that CATCH and THROW >>should be used for more for things than other languages do, but >>right now I can't think of any reason why there might be. > > Maybe you did not get <2017Feb13.175259@mips.complang.tuwien.ac.at> > after all. > > The reason is that, in Forth, you frequently have to do some sequence > of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up > no-longer needed arguments on the stacks. That's especially annoying > if you have to deal with a bunch of dependent conditions that you have > to check with ifs. You get code like: > > : foo > 2dup check-something if > dup >r check-something-else if > 2dup fdup check-yet-another-thing if > do the thing that depends on these conditions > clean up the stacks exit then > clean up the stacks for this branch exit then > clean up the stacks for this branch exit then > clean up the stacks for this branch ; > > Or you can organize this with ELSEs; or with each IF in a separate > word, with local cleanups, but possibly long stack effects. Or you > put the data in variables so that you don't have to worry about their > presence on the stacks; but wait, we are now in a multi-core world, so > we have to put it in user variables, and this local data will cost > space in every task. > > Or, alternatively, you use THROW's ability to clean up all the stacks: > > [: 2dup check-something ?lthrow > dup >r check-something-else ?lthrow > 2dup fdup check-yet-another-thing ?throw > do the thing that depends on these conditions > clean up the stacks > ;] lexec Mmm, and unconditional THROW which isn't checking anything, but merely avoiding having to DROP stuff. > If the "do the thing" part leaves nothing on the stack, its cleanup > can be done by an LTHROW, too. > > This style allows us to think about this code linearly instead of as a > complex IF cascade, and it frees us from having to adjust one or more > else branches whenever we change something in the checks. I take your point, but it's not at all obvious to me that a well- factored version of FOO, with stack changes and cleanups pushed down into factors, wouldn't be better than THROWing. It's really hard to talk about something like this in the abstract. In particular, it might make sense to keep the stack depth constant across IFs so that the join at the end of FOO drops as many things as needed. I don't like ELSE DROP THEN very much any more than you do. That's why I like ?DUP, among other things. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-18 16:33 +0000 |
| Message-ID | <2017May18.183334@mips.complang.tuwien.ac.at> |
| In reply to | #59471 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
...
>But THROWing does effectively bypass actions at the end of a word, and
>the maintenance programmer is going to have to be aware that if they
>need some actions to happen they're going to have to change the way
>they write. So, in a program which uses exceptions heavily a common
>pattern would change from
>
> open-action stuff close-action
>
>to
>
> open-action [: stuff ;] catch >r close-action r> throw
>
>which is more complicated. (This is a standard pattern in Java, and
>people sometimes forget to do it.) I'm not sure it's an improvement.
You need to do something like this anyway, even if THROW occurs just
in exceptional circumstances. The typical way to make this nice and
simple is to factor it in a word that does the setup (open-action) and
cleanup (close-action) for all of the same kinds of things, and then
you just write
[: stuff ;] action
The only other alternative is to forget about cleanup, like Chuck
Moore is advocating (using BASE as example), but then you can forget
about composability and libraries.
I would say, that, contrary to your statement, unlike pre-Forth-94
(with its ABORT and ABORT" which bypassed everything without any
chance for the caller to effect a cleanup), CATCH almost offers a
guarantee that any exit will run through the post-CATCH code. The
only standard exception to this is QUIT, but I hope nobody is using
this anymore in application code (it should actually be moved to TOOLS
EXT, or redefined in terms of THROW).
>I take your point, but it's not at all obvious to me that a well-
>factored version of FOO, with stack changes and cleanups pushed down
>into factors, wouldn't be better than THROWing. It's really hard to
>talk about something like this in the abstract.
It's also hard to talk about this in the concrete, because for every
concrete example, the refactoring camp will provide some refactoring
and declare "mission accomplished", like George W. Bush did in Iraq,
ignoring the fact that the resulting factoring may not be the best for
further maintenance, and anyway, the code typically had a long and
tortuous past (with the cleanup code costing all the time) until it
became an example for the factoring capabilities of c.l.f
participants.
Anyway, I have had this problem and bugs from it a number of times,
and when I wrote about it in February, I looked through, IIRC
prims2x.fs, and found a number of nested IFs with stack cleanup (DROP
2DROP R> DROP and the like) before THEN. I could search again and
post the code here, but I doubt that you would find it a useful
factoring exercise, because you don't know the context.
>In particular, it might make sense to keep the stack depth constant
>across IFs so that the join at the end of FOO drops as many things as
>needed.
Hmm, fill the stacks at the start, so that the stack depth is always
the same? Unfortunately, often you can compute some items only after
you have checked a condition. You could put a placeholder on the
stack until then, but I don't consider this better factoring.
>I don't like ELSE DROP THEN very much any more than you do. That's
>why I like ?DUP, among other things.
Does not help for ELSE 2DROP THEN or ELSE R> DROP THEN.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 12:43 -0500 |
| Message-ID | <yZednUvhlPPXQIDEnZ2dnUU7-fvNnZ2d@supernews.com> |
| In reply to | #59512 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > ... >>But THROWing does effectively bypass actions at the end of a word, and >>the maintenance programmer is going to have to be aware that if they >>need some actions to happen they're going to have to change the way >>they write. So, in a program which uses exceptions heavily a common >>pattern would change from >> >> open-action stuff close-action >> >>to >> >> open-action [: stuff ;] catch >r close-action r> throw >> >>which is more complicated. (This is a standard pattern in Java, and >>people sometimes forget to do it.) I'm not sure it's an improvement. > > You need to do something like this anyway, even if THROW occurs just > in exceptional circumstances. Not exactly. Yes, if THROW can occur within the actions of stuff, but that is not a given. It's a matter of style: if stuff does not throw or cleans up any exceptions for itself then you don't have to do that. > The typical way to make this nice and simple is to factor it in a > word that does the setup (open-action) and cleanup (close-action) > for all of the same kinds of things, and then you just write > > [: stuff ;] action > > The only other alternative is to forget about cleanup, like Chuck > Moore is advocating (using BASE as example), but then you can forget > about composability and libraries. > > I would say, that, contrary to your statement, unlike pre-Forth-94 > (with its ABORT and ABORT" which bypassed everything without any > chance for the caller to effect a cleanup), CATCH almost offers a > guarantee that any exit will run through the post-CATCH code. CATCH does, yes, but THROW does not, and ABORT has even worse problems than THROW. (I can't think of a good reason why production code should ever ABORT, but given time perhaps someone could think of one.) So, no, the reality is not contrary to my statement. The contrast is between returning status information where a caller needs to know and THROWing. There's a choice here, but it's not clear to me which will result in better programs. >>I take your point, but it's not at all obvious to me that a well- >>factored version of FOO, with stack changes and cleanups pushed down >>into factors, wouldn't be better than THROWing. It's really hard to >>talk about something like this in the abstract. > > It's also hard to talk about this in the concrete, because for every > concrete example, the refactoring camp will provide some refactoring > and declare "mission accomplished", Perhaps so. That doesn't make them wrong. Not always, anyway. >>In particular, it might make sense to keep the stack depth constant >>across IFs so that the join at the end of FOO drops as many things as >>needed. > > Hmm, fill the stacks at the start, so that the stack depth is always > the same? Unfortunately, often you can compute some items only after > you have checked a condition. You could put a placeholder on the > stack until then, but I don't consider this better factoring. Probably not. It depends on how complex the stack handing gets to be. > >> I don't like ELSE DROP THEN very much any more than you do. That's >> why I like ?DUP, among other things. > > Does not help for ELSE 2DROP THEN or ELSE R> DROP THEN. No, but it's a big fat clue that there are sometimes better ways to do it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 04:01 -0500 |
| Message-ID | <dLednZEUu6ub_oDEnZ2dnUU7-aPNnZ2d@supernews.com> |
| In reply to | #59436 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
> The reason is that, in Forth, you frequently have to do some sequence
> of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up
> no-longer needed arguments on the stacks. That's especially annoying
> if you have to deal with a bunch of dependent conditions that you have
> to check with ifs. You get code like:
>
> : foo
> 2dup check-something if
> dup >r check-something-else if
> 2dup fdup check-yet-another-thing if
> do the thing that depends on these conditions
> clean up the stacks exit then
> clean up the stacks for this branch exit then
> clean up the stacks for this branch exit then
> clean up the stacks for this branch ;
>
> Or you can organize this with ELSEs; or with each IF in a separate
> word, with local cleanups, but possibly long stack effects. Or you
> put the data in variables so that you don't have to worry about their
> presence on the stacks; but wait, we are now in a multi-core world, so
> we have to put it in user variables, and this local data will cost
> space in every task.
>
> Or, alternatively, you use THROW's ability to clean up all the stacks:
>
> [: 2dup check-something ?lthrow
> dup >r check-something-else ?lthrow
> 2dup fdup check-yet-another-thing ?throw
> do the thing that depends on these conditions
> clean up the stacks
> ;] lexec
Thinking about this some more, something like
: foo
sp@ >r
2dup check-something if
dup >r check-something-else if
2dup fdup check-yet-another-thing if
do the thing that depends on these conditions
then then then
r> sp! ;
looks much better to me. There's no need for the EXECUTE and the
messing about with the return stack at all. THROW is overkill for a
job like this, surely? (OK, so there's the fp-stack to be DROPped as
well, but I'm you get the idea. Maybe a pair of words <MARK MARK>
which mark and reset both stacks would be better.)
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-18 15:41 +0000 |
| Message-ID | <2017May18.174156@mips.complang.tuwien.ac.at> |
| In reply to | #59475 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Or, alternatively, you use THROW's ability to clean up all the stacks:
>>
>> [: 2dup check-something ?lthrow
>> dup >r check-something-else ?lthrow
>> 2dup fdup check-yet-another-thing ?throw
>> do the thing that depends on these conditions
>> clean up the stacks
>> ;] lexec
>
>Thinking about this some more, something like
>
>: foo
> sp@ >r
> 2dup check-something if
> dup >r check-something-else if
> 2dup fdup check-yet-another-thing if
> do the thing that depends on these conditions
> then then then
> r> sp! ;
>
>looks much better to me. There's no need for the EXECUTE and the
>messing about with the return stack at all.
Actually, in the example above you need to clean up the return stack
as well as the FP stack and the data stack; note the >R in the second
line of my code (fourth line of your code). And therefore the "R>
SP!" part will fail if the first condition is true.
> THROW is overkill for a
>job like this, surely?
Let's see: THROW does three things:
1) clean up the stacks
2) determine the dynamically enclosing CATCH
3) jump there
For this usage we need the cleanup, and we need a jump. But yes,
point 2 above is overkill (but not particularly expensive). We can
think about something that fits better, and I will do that below, but
THROW has the advantage that it is already standard and widely
available.
SP@ SP! are non-standard, but at least widely available. Disadvantages:
- you also need RP@ RP! and FP@ FP! for the other stacks; and where do
you store the original values then?
- For systems with simple compilers, SP@ SP! is cheap, but for systems
with sophisticated compilers, it is expensive: it essentially dumbs
down the sophisticated compiler to the level of the simple compiler
for parts of the program, unless data-flow analysis can guarantee
the data flow from SP@ to SP!. CATCH and THROW are significantly
easier to handle efficiently for a sophisticated compiler, because
the THROW is guaranteed to clean up the stack, with no possibility
of setting the stack pointer to an arbitrary value.
>Maybe a pair of words <MARK MARK>
>which mark and reset both stacks would be better.)
Or rather: all three stacks. And then you do the jump part
separately, with IFs and a bunch of THENs. Is there any circumstance
where we want to split the THENs from the MARK>? I only can think of
a case where the THENs are not quite appropriate:
: foo
<MARK
2dup check-something if
dup >r check-something-else if
2dup fdup check-yet-another-thing if
do the thing that depends on these conditions
leave something on the stacks
AHEAD THENs-for-the-IFs MARK>
put something on the stacks to match up the success branch
THEN ;
So the "AHEAD THENs-for-the-IFs" would be a kind of super-ELSE, but
the MARK> would still be right after these THENs. So maybe "AHEAD
THENSs-for-the-ifs MARK>" should be combined into one word, say
CLEANUP>; then that example would become:
: foo
<MARK
2dup check-something if
dup >r check-something-else if
2dup fdup check-yet-another-thing if
do the thing that depends on these conditions
leave something on the stacks
CLEANUP>
put something on the stacks to match up the success branch
THEN ;
A cosmetic issue: Using IF turns this conceptually (and optically, if
you use an editor with auto-indent) from a sequence (with exits) into
an if-cascade. The reasoning for a sequence is simpler (especially if
the exits have guaranteed cleanup), but with the IFs, you have to look
at the whole thing to see that you can reason about it as a sequence.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 11:58 -0500 |
| Message-ID | <bvGdnXHcW-UgT4DEnZ2dnUU7-TXNnZ2d@supernews.com> |
| In reply to | #59509 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Or, alternatively, you use THROW's ability to clean up all the stacks: >>> >>> [: 2dup check-something ?lthrow >>> dup >r check-something-else ?lthrow >>> 2dup fdup check-yet-another-thing ?throw >>> do the thing that depends on these conditions >>> clean up the stacks >>> ;] lexec >> >>Thinking about this some more, something like >> >>: foo >> sp@ >r >> 2dup check-something if >> dup >r check-something-else if >> 2dup fdup check-yet-another-thing if >> do the thing that depends on these conditions >> then then then >> r> sp! ; >> >>looks much better to me. There's no need for the EXECUTE and the >>messing about with the return stack at all. > > Actually, in the example above you need to clean up the return stack > as well as the FP stack and the data stack; note the >R in the second > line of my code (fourth line of your code). And therefore the "R> > SP!" part will fail if the first condition is true. Ah, good point. I missed that. >> THROW is overkill for a job like this, surely? > > Let's see: THROW does three things: > > 1) clean up the stacks > 2) determine the dynamically enclosing CATCH > 3) jump there > > For this usage we need the cleanup, and we need a jump. But yes, > point 2 above is overkill (but not particularly expensive). We can > think about something that fits better, and I will do that below, but > THROW has the advantage that it is already standard and widely > available. > > SP@ SP! are non-standard, but at least widely available. Disadvantages: > > - you also need RP@ RP! and FP@ FP! for the other stacks; and where do > you store the original values then? I would have thought it advantageous to insist that the return stack should not be unbalanced if people really are going to do stuff like this, but even in discussing stuff like this we're halfway to damnation already, so I suppose we might as well go the whole way. I accept that's a matter of a preferred style, and this is not mine: I believe that people should tidy up their stacks just like they take out their garbage. Doubly so for their return stacks. >>Maybe a pair of words <MARK MARK> which mark and reset both stacks >>would be better.) > > Or rather: all three stacks. Well, two would be better IMO: then it's just a matter of pushing FP and SP. > And then you do the jump part separately, with IFs and a bunch of > THENs. Is there any circumstance where we want to split the THENs > from the MARK>? I only can think of a case where the THENs are not > quite appropriate: > > : foo > <MARK > 2dup check-something if > dup >r check-something-else if > 2dup fdup check-yet-another-thing if > do the thing that depends on these conditions > leave something on the stacks > AHEAD THENs-for-the-IFs MARK> > put something on the stacks to match up the success branch > THEN ; If ever there were a good use for EXIT-in-the middle it's surely this. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 22:57 +0100 |
| Message-ID | <ofl56t$ia5$1@dont-email.me> |
| In reply to | #59509 |
On 5/18/2017 16:41, Anton Ertl wrote: > Let's see: THROW does three things: > > 1) clean up the stacks > 2) determine the dynamically enclosing CATCH > 3) jump there > > For this usage we need the cleanup, and we need a jump. But yes, > point 2 above is overkill (but not particularly expensive). (2) comes pretty much for free; it's the RET to the address put there by CATCH's call, after THROW restores the saved rstack depth. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-17 00:32 +1000 |
| Message-ID | <off2ib$hes$1@gioia.aioe.org> |
| In reply to | #59355 |
Alex wrote: > On 5/16/2017 09:42, Gerry Jackson wrote: > > On 16/05/2017 01:24, HAA wrote: > >> Lars Brinkhoff wrote: > >>> HAA wrote: > >>>> It expresses a functionality which at the time was implemented through > >>>> R> DROP. For all I know ANS TC simply forgot to consider this use > >>>> in its > >>>> R> deliberations. > >>> > >>> Isn't it the case that the 1994 ANS explicitly spells out that return > >>> addresses may not be accessible at all by R>? > >> > >> Exactly. > > > > So they didn't forget about it, they chose to make it non-standard. > > > > And gave us CATCH and THROW, a much better & portable solution that > allows you to mark a place and return to it without any return stack > dependencies. Why more don't use it is a little mystifying. I'm happy to give credit to ANS when they get something right. But misapplying what they've provided is something only a fan will do.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 15:53 +0100 |
| Message-ID | <off3iv$koq$1@dont-email.me> |
| In reply to | #59373 |
On 5/16/2017 15:32, HAA wrote: > Alex wrote: >> On 5/16/2017 09:42, Gerry Jackson wrote: >>> On 16/05/2017 01:24, HAA wrote: >>>> Lars Brinkhoff wrote: >>>>> HAA wrote: >>>>>> It expresses a functionality which at the time was implemented through >>>>>> R> DROP. For all I know ANS TC simply forgot to consider this use >>>>>> in its >>>>>> R> deliberations. >>>>> >>>>> Isn't it the case that the 1994 ANS explicitly spells out that return >>>>> addresses may not be accessible at all by R>? >>>> >>>> Exactly. >>> >>> So they didn't forget about it, they chose to make it non-standard. >>> >> >> And gave us CATCH and THROW, a much better & portable solution that >> allows you to mark a place and return to it without any return stack >> dependencies. Why more don't use it is a little mystifying. > > I'm happy to give credit to ANS when they get something right. > But misapplying what they've provided is something only a fan will do. > How is the proposed use (avoiding non-portable rstack fiddling) "misapplying" CATCH/THROW? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-15 05:29 +0000 |
| Message-ID | <2017May15.072905@mips.complang.tuwien.ac.at> |
| In reply to | #59223 |
humptydumpty <ouatubi@gmail.com> writes:
>On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote:
>> No. That is not how it happened. ANS did not preclude return stack
>> hackery because it wasn't portable anyway. Before the ANS process
>> began, the number of return stack items pushed by a colon definition
>> wasn't always 1. And maybe you'd even be using a different stack for
>> return addresses.
>
>This is mind boggling! Was that Forth? What is the percentage
>of such implementations from all Forth implementations?
F-PC, possibly the most popular Forth system at the time of Forth-94
standardization, had two cells per return address. There are reports
of popular microcontrollers (IIRC 8051) that have an on-chip
return-address stack without connection to the data part of the chip,
i.e., the stack for >R R> has to be implemented elsewhere.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2017-05-14 23:00 -0700 |
| Message-ID | <ad5c86a1-bd1f-49e5-a7c5-d328aa2e8dc9@googlegroups.com> |
| In reply to | #59256 |
On Monday, May 15, 2017 at 8:40:08 AM UTC+3, Anton Ertl wrote: > humptydumpty writes: > >On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote: > >> No. That is not how it happened. ANS did not preclude return stack > >> hackery because it wasn't portable anyway. Before the ANS process > >> began, the number of return stack items pushed by a colon definition > >> wasn't always 1. And maybe you'd even be using a different stack for > >> return addresses. > > > >This is mind boggling! Was that Forth? What is the percentage > >of such implementations from all Forth implementations? > > F-PC, possibly the most popular Forth system at the time of Forth-94 > standardization, had two cells per return address. There are reports > of popular microcontrollers (IIRC 8051) that have an on-chip > return-address stack without connection to the data part of the chip, > i.e., the stack for >R R> has to be implemented elsewhere. That return address is a segment:offset pair on F-PC does not change the logical way to manipulate partial continuations. I'll take a look onto 8051 CamelFORTH of Brad Rodriguez. Thank you. > > - 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 2017: http://www.euroforth.org/ef17/ -- Have a nice day, hum9
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-17 12:27 -0400 |
| Message-ID | <ofhtft$jd$1@dont-email.me> |
| In reply to | #59223 |
On 5/14/2017 1:43 PM, humptydumpty wrote: > On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote: >> HAA wrote: >> >>> In the days when "return stack" meant return stack and threaded code >>> was the norm R> DROP is what you would use. ANS precludes this, >>> forcing programmers to adopt inefficient solutions. >> >> No. That is not how it happened. ANS did not preclude return stack >> hackery because it wasn't portable anyway. Before the ANS process >> began, the number of return stack items pushed by a colon definition >> wasn't always 1. And maybe you'd even be using a different stack for >> return addresses. > > This is mind boggling! Was that Forth? What is the percentage > of such implementations from all Forth implementations? > >> So maybe the R> DROP trick would work, maybe not. > > But this is not a trick. Is applying knowledge that on return-stack > is the address of continuation(partial) of current definition caller. > >> >> In that sense, the situation is not any different post-ANS: if you >> want to depend on a colon definition pushing one item onto the return >> stack you can still assume that. ANS did not cause this trick to stop >> working: it was descriptive rather than prescriptive. >> >>> Here's an example of a routine that deserves to be as efficient as >>> it looks. >>> >>> : ?# ( ud -- ud ) # 2dup d0= if r> drop then ; >>> >>> : #,S ( ud -- 0 0 ) begin ?# ?# ?# [char] , hold again ; >> >> I hope that wouldn't pass review. > > This is a very nice factored code! > > What matter is idea behind code. User will modify '?#' definition > accordingly with used Forth implementation, if necessary, or choose > another Forth implementation. Huh? I didn't realize the idea of sharing code was so it could be modified to work. I thought the idea of writing standard conforming code was to share without modification. Heck, this is the sort of code that gives a language a bad name. Another problem with it is compatibility with debuggers. I don't normally use them, but setting a breakpoint anywhere after the first use of ?# would give confusing results when the code executes right past the breakpoint without stopping. You would only figure out why if you dig into the underlying code. The same thing would happen if you insert debugging statements. I often do that and work from the top down to isolate the problem. It is very distracting when you insert debugging statements and they aren't executed. There is a reason why the idea of structured code was invented. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-15 09:16 +0000 |
| Message-ID | <xn0kq09hi6okud006@nntp.aioe.org> |
| In reply to | #59199 |
HAA wrote: > Rudy Velthuis wrote: > > humptydumpty wrote: > > > > > > Yes you are right. Anton Ertls suggestion is perfect: > > > > > > > > : ?exit postpone if postpone exit postpone then ; immediate > > > > > > > > Nowadays I focus on calculations and I've stopped thinking > > > > outside the box... :) > > > > > > LOL! > > > > > > Then what "return stack" means? :) > > > > Different things in different systems. And, as I said, there will be > > many systems that only put one cell on the return stack if they > > enter a definition, so 2R> and 2DROP would be wrong already. > > But it does raise the issue of wanting to drop a level. Well, how do you define "returning" from a definition to the "calling" definition? That is returning to a previous level, in a way. -- Rudy Velthuis http://www.rvelthuis.de "I don't approve of political jokes... I've seen too many of them get elected." -- unknown
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-15 09:55 +0000 |
| Message-ID | <xn0kq0agd5wcdzr002@nntp.aioe.org> |
| In reply to | #59199 |
HAA wrote: > Rudy Velthuis wrote: > > humptydumpty wrote: > > > > > > Yes you are right. Anton Ertls suggestion is perfect: > > > > > > > > : ?exit postpone if postpone exit postpone then ; immediate > > > > > > > > Nowadays I focus on calculations and I've stopped thinking > > > > outside the box... :) > > > > > > LOL! > > > > > > Then what "return stack" means? :) > > > > Different things in different systems. And, as I said, there will be > > many systems that only put one cell on the return stack if they > > enter a definition, so 2R> and 2DROP would be wrong already. > > But it does raise the issue of wanting to drop a level. Depends on how you define "level". I think that if you call a definition, you go one level deeper and if you return (exit) from that definition, you go back (up) one level again. That is what I would call "dropping a level". -- Rudy Velthuis http://www.rvelthuis.de "I can envision a small cottage somewhere, with a lot of writing paper, and a dog, and a fireplace and maybe enough money to give myself some Irish coffee now and then and entertain my two friends." -- Richard Van de Geer, letter, 1975, last American to die in Vietnam War, Time, 1985
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-13 14:25 +0000 |
| Message-ID | <xn0kpxogz4ib1hw00f@nntp.aioe.org> |
| In reply to | #59148 |
humptydumpty wrote: > On Saturday, May 13, 2017 at 3:01:03 AM UTC+3, lehs wrote: > > Den fredag 12 maj 2017 kl. 16:20:24 UTC+2 skrev Rudy Velthuis: > > > lehs wrote: > > > > > > > : ?exit ( flag -- ) if 2r> 2drop then ; > > > > > > > > I'm doing a kind of filtering word and want to replace IF EXIT > > > > THEN with ?EXIT if this works. > > > > > > Probably only on indirectly threaded systems, and even there, > > > there may be more or fewer items on the return stack. > > > > > > -- > > > Rudy Velthuis http://www.rvelthuis.de > > > > > > "In the 1980s capitalism triumphed over communism. In the 1990s > > > it triumphed over democracy." > > > -- David Korten > > > > Yes you are right. Anton Ertls suggestion is perfect: > > > > : ?exit postpone if postpone exit postpone then ; immediate > > > > Nowadays I focus on calculations and I've stopped thinking outside > > the box... :) > > LOL! > > Then what "return stack" means? :) > > Please, review what "return stack" stands for every kind of > threading. Also what "subroutine" means for in generic > programming. > > Return stack manipulations does *not work* for inlined > or tail-recursion optimized words. Indeed. Now I am wondering what the fun is about. Why the LOL! and whom are you telling this? I already said it won't work in general, but it may work on *some* indirect threading systems (obviously the ones that do not do inlining or tail-recursion optimization and that push two cells when entering a definition). <shrug> -- Rudy Velthuis http://www.rvelthuis.de "I think Microsoft named .Net so it wouldn’t show up in a Unix directory listing.” -- Oktal
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web