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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-29 12:17 +1000 |
| Message-ID | <ogg0em$eco$1@gioia.aioe.org> |
| In reply to | #59928 |
Alex wrote: > On 5/27/2017 06:04, HAA wrote: > > Alex wrote: > >> On 5/26/2017 12:56, HAA wrote: > >> > >>> My other point was efficiency. I'd be horrified at the thought of > >>> anyone attempting to use catch/throw in code such as this. > >>> > >> > >> Why? > > > > Forth is about using the right tool for the job? > > > > > > > > OK, so why is it the wrong tool for the job? Is it the names? I've presented code using what I believe is the best tool for the job. If you believe otherwise, provide an alternative explaining why that is best.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-29 08:42 +0100 |
| Message-ID | <oggj72$uu3$1@dont-email.me> |
| In reply to | #59997 |
On 5/29/2017 03:17, HAA wrote: > Alex wrote: >> On 5/27/2017 06:04, HAA wrote: >>> Alex wrote: >>>> On 5/26/2017 12:56, HAA wrote: >>>> >>>>> My other point was efficiency. I'd be horrified at the thought of >>>>> anyone attempting to use catch/throw in code such as this. >>>>> >>>> >>>> Why? >>> >>> Forth is about using the right tool for the job? >>> >>> >>> >> >> OK, so why is it the wrong tool for the job? Is it the names? > > I've presented code using what I believe is the best tool for the job. > If you believe otherwise, provide an alternative explaining why that > is best. > You would apparently be horrified, and I was wondering why, and you haven't explained. But as to your request, I can do no better than quote Anton Ertl; > My point is that CATCH/THROW is better for multi-level exit than > explicit return-address manipulation: It cleans up the stacks, and > works also with locals and on systems with tail-call elimination and > inlining. Is this describing a tool you would use? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-30 11:14 +1000 |
| Message-ID | <ogih1a$dof$2@gioia.aioe.org> |
| In reply to | #60013 |
Alex wrote: > On 5/29/2017 03:17, HAA wrote: > > Alex wrote: > >> On 5/27/2017 06:04, HAA wrote: > >>> Alex wrote: > >>>> On 5/26/2017 12:56, HAA wrote: > >>>> > >>>>> My other point was efficiency. I'd be horrified at the thought of > >>>>> anyone attempting to use catch/throw in code such as this. > >>>>> > >>>> > >>>> Why? > >>> > >>> Forth is about using the right tool for the job? > >>> > >>> > >>> > >> > >> OK, so why is it the wrong tool for the job? Is it the names? > > > > I've presented code using what I believe is the best tool for the job. > > If you believe otherwise, provide an alternative explaining why that > > is best. > > > > You would apparently be horrified, and I was wondering why, and you > haven't explained. But as to your request, I can do no better than quote > Anton Ertl; > > > My point is that CATCH/THROW is better for multi-level exit than > > explicit return-address manipulation: It cleans up the stacks, and > > works also with locals and on systems with tail-call elimination and > > inlining. > > Is this describing a tool you would use? I've demonstrated the tool I would use in two specific situations involving 'explicit return-address manipulation'.
[toc] | [prev] | [next] | [standalone]
| From | obi65537@gmail.com |
|---|---|
| Date | 2017-05-29 20:32 -0700 |
| Message-ID | <4bb2d918-a2b6-4fb8-8cc9-42684070dfe2@googlegroups.com> |
| In reply to | #60013 |
On Monday, May 29, 2017 at 10:42:45 AM UTC+3, Alex wrote: > On 5/29/2017 03:17, HAA wrote: > > Alex wrote: > >> On 5/27/2017 06:04, HAA wrote: > >>> Alex wrote: > >>>> On 5/26/2017 12:56, HAA wrote: > >>>> > >>>>> My other point was efficiency. I'd be horrified at the thought of > >>>>> anyone attempting to use catch/throw in code such as this. > >>>>> > >>>> > >>>> Why? > >>> > >>> Forth is about using the right tool for the job? > >>> > >>> > >>> > >> > >> OK, so why is it the wrong tool for the job? Is it the names? > > > > I've presented code using what I believe is the best tool for the job. > > If you believe otherwise, provide an alternative explaining why that > > is best. > > > > You would apparently be horrified, and I was wondering why, and you > haven't explained. But as to your request, I can do no better than quote > Anton Ertl; > > > My point is that CATCH/THROW is better for multi-level exit than > > explicit return-address manipulation: It cleans up the stacks, and > > works also with locals and on systems with tail-call elimination and > > inlining. > > Is this describing a tool you would use? > > -- > Alex To make the long story short: post your 'CATCH/THROW' version of HAA code and discuss its superiority. Have a nice day, hum9
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-30 14:40 +1000 |
| Message-ID | <ogit38$qm9$1@gioia.aioe.org> |
| In reply to | #60039 |
obi65537@gmail.com wrote:
> ...
> To make the long story short: post your 'CATCH/THROW' version of HAA code
> and discuss its superiority.
>
> Have a nice day,
> hum9
FWIW this is how the code would look if written 'straight'. Not too bad in
this instance but the result is busier looking code since the calling routine
must now handle the errors and eof's that occur in the subroutines for
each such call.
: rdini ( a u fid -- a u ior )
1 setfh ;
: ranrw ( mode -- err ) \ read/write 128 byte disk file record
33 + fcb swap bdos ;
: fread ( a u1 -- a u2 )
begin dup while
>r \ u remaining
setsiz r@ umin ( siz)
dup recsiz = if \ whole record
over setdma 0 ranrw if drop r> end \ direct to adr
else \ partial record
hbuf setdma 0 ranrw if drop r> end \ to temp buffer
2dup hbuf offs + -rot cmove \ copy partial to adr
then
dup >r + rwp@ r@ m+ rwp! 2r> - \ update file pos & u remaining
repeat ;
: read-file ( a u1 fid -- u2 ior )
rdini ?dup if ( err) nip >ior end ( a u) tuck fread ( u a' u') nip - 0 ;
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-30 12:55 +0100 |
| Message-ID | <ogjmd5$4mh$1@dont-email.me> |
| In reply to | #60039 |
On 5/30/2017 04:32, obi65537@gmail.com wrote: > On Monday, May 29, 2017 at 10:42:45 AM UTC+3, Alex wrote: >> On 5/29/2017 03:17, HAA wrote: >>> Alex wrote: >>>> On 5/27/2017 06:04, HAA wrote: >>>>> Alex wrote: >>>>>> On 5/26/2017 12:56, HAA wrote: >>>>>> >>>>>>> My other point was efficiency. I'd be horrified at the thought of >>>>>>> anyone attempting to use catch/throw in code such as this. >>>>>>> >>>>>> >>>>>> Why? >>>>> >>>>> Forth is about using the right tool for the job? >>>>> >>>>> >>>>> >>>> >>>> OK, so why is it the wrong tool for the job? Is it the names? >>> >>> I've presented code using what I believe is the best tool for the job. >>> If you believe otherwise, provide an alternative explaining why that >>> is best. >>> >> >> You would apparently be horrified, and I was wondering why, and you >> haven't explained. But as to your request, I can do no better than quote >> Anton Ertl; >> >>> My point is that CATCH/THROW is better for multi-level exit than >>> explicit return-address manipulation: It cleans up the stacks, and >>> works also with locals and on systems with tail-call elimination and >>> inlining. >> >> Is this describing a tool you would use? >> >> -- >> Alex > > To make the long story short: post your 'CATCH/THROW' version of HAA code > and discuss its superiority. HAA's code won't work on any system that doesn't maintain the return address on the stack; for instance those that do tail-call elimination or inlining. I don't need to write any code to demonstrate that. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-31 12:17 +1000 |
| Message-ID | <ogl92k$mjs$1@gioia.aioe.org> |
| In reply to | #60058 |
Alex wrote:
> On 5/30/2017 04:32, obi65537@gmail.com wrote:
> > ...
> > To make the long story short: post your 'CATCH/THROW' version of HAA code
> > and discuss its superiority.
>
> HAA's code won't work on any system that doesn't maintain the return
> address on the stack; for instance those that do tail-call elimination
> or inlining. I don't need to write any code to demonstrate that.
Any forth compiler deserving of that name should be able to implement
a feature which has existed in Forth since early days.
"Forth allows us to alter the control flow by directly manipulating the
return stack. [...] the disciplined use of the structured exit can actually
simplify code, and thereby improve readability and maintainability."
L. Brodie "Thinking FORTH"
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-06-01 12:01 +1000 |
| Message-ID | <ognsij$mcv$1@gioia.aioe.org> |
| In reply to | #60058 |
Alex wrote: > ... > HAA's code won't work on any system that doesn't maintain the return > address on the stack; for instance those that do tail-call elimination > or inlining. I don't need to write any code to demonstrate that. In fact ANS does require systems to maintain "nest-sys" on the return stack. It's clearly shown in the spec for colon, semicolon and EXIT. The existence of "nest-sys" - even if only virtually - guarantees a forth programmer the right to have subroutines. Any compiler that inlined a subroutine without first getting permission from the programmer would be acting contrary to ANS. The spec for EXIT shows it performs two distinct tasks - discard nest-sys from the return stack and return control to the calling function. There's nothing preventing ANS from defining UNNEST which simply discards nest-sys. The principle of discarding system-dependent information from the return stack already exists in ANS in the form of UNLOOP. I don't hear anyone advocating UNLOOP be removed because CATCH/THROW might replace it. Some might even consider such a proposal ridiculous.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-01 02:17 -0500 |
| Message-ID | <nJKdnSJMfqTgIrLEnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #60121 |
HAA <someone@microsoft.com> wrote: > Alex wrote: >> ... >> HAA's code won't work on any system that doesn't maintain the return >> address on the stack; for instance those that do tail-call elimination >> or inlining. I don't need to write any code to demonstrate that. > > In fact ANS does require systems to maintain "nest-sys" on the > return stack. "nest-sys" is zero to n cells in size. > It's clearly shown in the spec for colon, semicolon and EXIT. The > existence of "nest-sys" - even if only virtually - guarantees a > forth programmer the right to have subroutines. Any compiler that > inlined a subroutine without first getting permission from the > programmer would be acting contrary to ANS. No, that's not right, because the "as if" rule applies here, as to all programming languages. I'm sure if you ask the current TC they'll tell you that inlining is OK. > The spec for EXIT shows it performs two distinct tasks - discard nest-sys > from the return stack and return control to the calling function. There's > nothing preventing ANS from defining UNNEST which simply discards > nest-sys. Well, there is: no sane TC would ever agree to it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-06-01 22:09 +1000 |
| Message-ID | <ogp052$a7r$1@gioia.aioe.org> |
| In reply to | #60130 |
Andrew Haley wrote:
> HAA <someone@microsoft.com> wrote:
> > Alex wrote:
> >> ...
> >> HAA's code won't work on any system that doesn't maintain the return
> >> address on the stack; for instance those that do tail-call elimination
> >> or inlining. I don't need to write any code to demonstrate that.
> >
>
> > In fact ANS does require systems to maintain "nest-sys" on the
> > return stack.
>
> "nest-sys" is zero to n cells in size.
"nest-sys" is "implementation defined". What's not in doubt is that
nest-sys exists and it occurs whenever a subroutine is invoked.
> > It's clearly shown in the spec for colon, semicolon and EXIT. The
> > existence of "nest-sys" - even if only virtually - guarantees a
> > forth programmer the right to have subroutines. Any compiler that
> > inlined a subroutine without first getting permission from the
> > programmer would be acting contrary to ANS.
>
> No, that's not right, because the "as if" rule applies here, as to all
> programming languages. I'm sure if you ask the current TC they'll
> tell you that inlining is OK.
What one 200x member has said is that in Forth there has always an
expectation that you write is what you get. Forth works at a lower level
than other languages and has benefited from that capability. I would
certainly regard as over-reach and breach of ANS if a compiler went
behind my back and started inlining code I had written as a subroutine.
>
> > The spec for EXIT shows it performs two distinct tasks - discard nest-sys
> > from the return stack and return control to the calling function. There's
> > nothing preventing ANS from defining UNNEST which simply discards
> > nest-sys.
>
> Well, there is: no sane TC would ever agree to it.
>
> Andrew.
'No sane TC would ever agree to' an opportunity to simplify and reduce
code as suggested by Forth's creator? How unfortunate for Forth.
Charles Moore:
"More and more I've come to favor R> DROP to alter the flow of control.
[...] The alternative is burdening the rest of the application with checking
whether an error occurred. That's an inconvenience."
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-01 07:51 -0500 |
| Message-ID | <krCdnaUVdptTkK3EnZ2dnUU7-d3NnZ2d@supernews.com> |
| In reply to | #60139 |
HAA <someone@microsoft.com> wrote: > Andrew Haley wrote: >> HAA <someone@microsoft.com> wrote: >> > Alex wrote: >> >> ... >> >> HAA's code won't work on any system that doesn't maintain the return >> >> address on the stack; for instance those that do tail-call elimination >> >> or inlining. I don't need to write any code to demonstrate that. >> > >> >> > In fact ANS does require systems to maintain "nest-sys" on the >> > return stack. >> >> "nest-sys" is zero to n cells in size. > > "nest-sys" is "implementation defined". What's not in doubt is that > nest-sys exists and it occurs whenever a subroutine is invoked. There is every reason to doubt that it exists in concrete: it is a conceptual structure. A physical return stack that contains addresses might be somewhere else, or the compiler might have rewritten all of your code so that there are no calls. The "as if" rule applies. >> > It's clearly shown in the spec for colon, semicolon and EXIT. The >> > existence of "nest-sys" - even if only virtually - guarantees a >> > forth programmer the right to have subroutines. Any compiler that >> > inlined a subroutine without first getting permission from the >> > programmer would be acting contrary to ANS. >> >> No, that's not right, because the "as if" rule applies here, as to all >> programming languages. I'm sure if you ask the current TC they'll >> tell you that inlining is OK. > > What one 200x member has said is that in Forth there has always an > expectation that you write is what you get. Forth works at a lower level > than other languages and has benefited from that capability. I would > certainly regard as over-reach and breach of ANS if a compiler went > behind my back and started inlining code I had written as a subroutine. So, you'd regard it as over-reach. In which case I believe you'd be wrong: there is no doubt about that from a standard language point of view. You might argue about it as a quality of implementation issue, in which case I'd say "each to their own". >> > The spec for EXIT shows it performs two distinct tasks - discard nest-sys >> > from the return stack and return control to the calling function. There's >> > nothing preventing ANS from defining UNNEST which simply discards >> > nest-sys. >> >> Well, there is: no sane TC would ever agree to it. > > 'No sane TC would ever agree to' an opportunity to simplify and reduce > code as suggested by Forth's creator? How unfortunate for Forth. > > Charles Moore: > > "More and more I've come to favor R> DROP to alter the flow of control. > [...] The alternative is burdening the rest of the application with checking > whether an error occurred. That's an inconvenience." Quelle tragedie. And note that we now have THROW. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-01 14:20 +0100 |
| Message-ID | <ogp44o$6aj$1@dont-email.me> |
| In reply to | #60142 |
On 6/1/2017 13:51, Andrew Haley wrote: > Quelle tragedie. And note that we now have THROW. And irony. (There's a song in there somewhere. Tragedy and Irony, to the tune of Ebony and Ivory.) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-06-02 13:09 +1000 |
| Message-ID | <ogqkto$or7$1@gioia.aioe.org> |
| In reply to | #60142 |
Andrew Haley wrote: > HAA <someone@microsoft.com> wrote: > > Andrew Haley wrote: > >> HAA <someone@microsoft.com> wrote: > >> > Alex wrote: > >> >> ... > >> >> HAA's code won't work on any system that doesn't maintain the return > >> >> address on the stack; for instance those that do tail-call elimination > >> >> or inlining. I don't need to write any code to demonstrate that. > >> > > >> > >> > In fact ANS does require systems to maintain "nest-sys" on the > >> > return stack. > >> > >> "nest-sys" is zero to n cells in size. > > > > "nest-sys" is "implementation defined". What's not in doubt is that > > nest-sys exists and it occurs whenever a subroutine is invoked. > > There is every reason to doubt that it exists in concrete: it is a > conceptual structure. You're saying ANS and all the previous standards invented a fiction? That the 'return stack' in Forth has never been used to hold information necessary for a subroutine to return to its caller? Wonders never cease. > A physical return stack that contains addresses > might be somewhere else, or the compiler might have rewritten all of > your code so that there are no calls. The "as if" rule applies. The only rule I see is the one specified by colon which says a call to a subroutine leaves a nest-sys on the return stack. Any implementer which seeks to avoid it is on their own. > >> Well, there is: no sane TC would ever agree to it. > > > > 'No sane TC would ever agree to' an opportunity to simplify and reduce > > code as suggested by Forth's creator? How unfortunate for Forth. > > > > Charles Moore: > > > > "More and more I've come to favor R> DROP to alter the flow of control. > > [...] The alternative is burdening the rest of the application with checking > > whether an error occurred. That's an inconvenience." > > Quelle tragedie. In other words you don't have a technical reason for rejecting UNNEST. > And note that we now have THROW. I've already commented on the improbability of replacing UNLOOP with THROW. What makes you think substituting UNNEST with THROW would be any less foolish? > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-02 08:44 +0100 |
| Message-ID | <ogr4qe$ts8$1@dont-email.me> |
| In reply to | #60178 |
On 6/2/2017 04:09, HAA wrote: > Andrew Haley wrote: >> HAA <someone@microsoft.com> wrote: >>> Andrew Haley wrote: >>>> HAA <someone@microsoft.com> wrote: >>>>> Alex wrote: >>>>>> ... >>>>>> HAA's code won't work on any system that doesn't maintain the return >>>>>> address on the stack; for instance those that do tail-call elimination >>>>>> or inlining. I don't need to write any code to demonstrate that. >>>>> >>>> >>>>> In fact ANS does require systems to maintain "nest-sys" on the >>>>> return stack. >>>> >>>> "nest-sys" is zero to n cells in size. >>> >>> "nest-sys" is "implementation defined". What's not in doubt is that >>> nest-sys exists and it occurs whenever a subroutine is invoked. >> >> There is every reason to doubt that it exists in concrete: it is a >> conceptual structure. > > You're saying ANS and all the previous standards invented a fiction? > That the 'return stack' in Forth has never been used to hold information > necessary for a subroutine to return to its caller? Wonders never cease. It's clear that nest-sys is implementation defined. That means it may not exist on the rstack; and I can imagine systems where that might be a practical state of affairs, for instance machines with no stacks (IBM s/360 and descendants, SPARC register windows) where both stacks would be emulated and return addresses might be more efficiently dealt with using other techniques. > >> A physical return stack that contains addresses >> might be somewhere else, or the compiler might have rewritten all of >> your code so that there are no calls. The "as if" rule applies. > > The only rule I see is the one specified by colon which says a call to a > subroutine leaves a nest-sys on the return stack. Any implementer > which seeks to avoid it is on their own. > None do, since returning from a word is a requirement of the language. But it can be implemented and comply with the standard with 0 cells on the rstack. >>>> Well, there is: no sane TC would ever agree to it. >>> >>> 'No sane TC would ever agree to' an opportunity to simplify and reduce >>> code as suggested by Forth's creator? How unfortunate for Forth. >>> >>> Charles Moore: >>> >>> "More and more I've come to favor R> DROP to alter the flow of control. >>> [...] The alternative is burdening the rest of the application with checking >>> whether an error occurred. That's an inconvenience." >> >> Quelle tragedie. > > In other words you don't have a technical reason for rejecting UNNEST. Yes. 1. It will prevent inlining and tail call elimination. 2. It forces architectures that have other ways of call/return to save something on the rstack. The Charles Moore argument is spurious. I don't believe it is a programming technique with any value; much like GOTO, it is a historical curiosity. Brodie gave it too much prominence in Starting Forth. One line would have sufficed; "Don't do this." > >> And note that we now have THROW. > > I've already commented on the improbability of replacing UNLOOP with THROW. > What makes you think substituting UNNEST with THROW would be any less > foolish? You're proposing UNNEST instead of THROW; it's not us proposing THROW instead of UNNEST. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | obi65537@gmail.com |
|---|---|
| Date | 2017-06-02 11:05 -0700 |
| Message-ID | <8c8de7f9-bdeb-4d9c-96aa-44872d5f6aec@googlegroups.com> |
| In reply to | #60179 |
On Friday, June 2, 2017 at 10:44:34 AM UTC+3, Alex wrote: > > You're proposing UNNEST instead of THROW; it's not us proposing THROW > instead of UNNEST. > > -- > Alex I'm sick of your diversions. You proposed THROW instead of UNNEST in every case. What you posted: <thread/ On 5/29/2017 03:17, HAA wrote: > Alex wrote: >> On 5/27/2017 06:04, HAA wrote: >>> Alex wrote: >>>> On 5/26/2017 12:56, HAA wrote: >>>> >>>>> My other point was efficiency. I'd be horrified at the thought of >>>>> anyone attempting to use catch/throw in code such as this. >>>>> >>>> >>>> Why? >>> >>> Forth is about using the right tool for the job? >>> >>> >>> >> >> OK, so why is it the wrong tool for the job? Is it the names? > > I've presented code using what I believe is the best tool for the job. > If you believe otherwise, provide an alternative explaining why that > is best. > You would apparently be horrified, and I was wondering why, and you haven't explained. But as to your request, I can do no better than quote Anton Ertl; > My point is that CATCH/THROW is better for multi-level exit than > explicit return-address manipulation: It cleans up the stacks, and > works also with locals and on systems with tail-call elimination and > inlining. Is this describing a tool you would use? /end-thread>
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-02 19:34 +0100 |
| Message-ID | <ogsatq$tik$1@dont-email.me> |
| In reply to | #60203 |
On 6/2/2017 19:05, obi65537@gmail.com wrote: > On Friday, June 2, 2017 at 10:44:34 AM UTC+3, Alex wrote: >> >> You're proposing UNNEST instead of THROW; it's not us proposing THROW >> instead of UNNEST. >> >> -- >> Alex > > I'm sick of your diversions.\\ Oh dear. > You proposed THROW instead of UNNEST in every case. What you posted: > > <thread/ > > On 5/29/2017 03:17, HAA wrote: >> Alex wrote: >>> On 5/27/2017 06:04, HAA wrote: >>>> Alex wrote: >>>>> On 5/26/2017 12:56, HAA wrote: >>>>> >>>>>> My other point was efficiency. I'd be horrified at the thought of >>>>>> anyone attempting to use catch/throw in code such as this. >>>>>> >>>>> >>>>> Why? >>>> >>>> Forth is about using the right tool for the job? >>>> >>>> >>>> >>> >>> OK, so why is it the wrong tool for the job? Is it the names? >> >> I've presented code using what I believe is the best tool for the job. >> If you believe otherwise, provide an alternative explaining why that >> is best. >> > > You would apparently be horrified, and I was wondering why, and you > haven't explained. But as to your request, I can do no better than quote > Anton Ertl; > >> My point is that CATCH/THROW is better for multi-level exit than >> explicit return-address manipulation: It cleans up the stacks, and >> works also with locals and on systems with tail-call elimination and >> inlining. > > Is this describing a tool you would use? > > /end-thread> > I thought I was asking questions to someone who wants UNNEST but refused to engage as to why it was superior to CATCH/THROW. I have no objection to you or HAA using whatever word you like, or even employing R> DROP raw, but I believe it a valid question to ask -- why not THROW and what it offers? It does all the things mentioned above, and UNNEST does not; but neither HAA or you has explained why UNNEST is a desirable or superior solution. At the risk of pissing you off even more, I'll repeat; you and HAA are proposing UNNEST instead of THROW; it's not me proposing THROW instead of UNNEST. It's up to you to justify UNNEST, not me. And, as it stands, neither you nor s/he have shown how it's possible to write such a word in a standard way. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-06-03 14:29 +1000 |
| Message-ID | <ogtdu1$n1t$1@gioia.aioe.org> |
| In reply to | #60205 |
Alex wrote: > ... > At the risk of pissing you off even more, I'll repeat; you and HAA are > proposing UNNEST instead of THROW; it's not me proposing THROW instead > of UNNEST. It's up to you to justify UNNEST, not me. You've been given two examples using UNNEST. Don't "piss off" readers with posts intended to obfuscate and wear out. Make good on your claim CATCH/ THROW can do everything UNNEST can by rewriting those two examples. When you've done that, I'll be happy to compare them and readers can decide for themselves whether UNNEST is justified for them. > And, as it stands, > neither you nor s/he have shown how it's possible to write such a word > in a standard way. It's not my job to make things standard. That's the role of TC's. In the absence of CATCH/THROW alternatives, let's compare the only alternative to UNNEST presented thus far. You asked me to justify my use of UNNEST. I use it because it produces the results Brodie and Moore said it would. Original using UNNEST: : ?# ( ud -- ud ) # 2dup d0= if unnest then ; : #,S ( ud -- 0 0 ) begin ?# ?# ?# [char] , hold again ; ?# ( 004AB0D0 E8670BF6FF ) CALL 0040BC3C # ( 004AB0D5 8BD3 ) MOV EDX, EBX ( 004AB0D7 0B5D00 ) OR EBX, [EBP] ( 004AB0DA 8BDA ) MOV EBX, EDX ( 004AB0DC 0F8503000000 ) JNZ/NE 004AB0E5 ( 004AB0E2 83C404 ) ADD ESP, 04 ( 004AB0E5 C3 ) NEXT, ( 22 bytes, 7 instructions ) #,S ( 004AB110 E8BBFFFFFF ) CALL 004AB0D0 ?# ( 004AB115 E8B6FFFFFF ) CALL 004AB0D0 ?# ( 004AB11A E8B1FFFFFF ) CALL 004AB0D0 ?# ( 004AB11F 8D6DFC ) LEA EBP, [EBP+-04] ( 004AB122 895D00 ) MOV [EBP], EBX ( 004AB125 BB2C000000 ) MOV EBX, 0000002C ( 004AB12A E8AD0AF6FF ) CALL 0040BBDC HOLD ( 004AB12F EBDF ) JMP 004AB110 #,S ( 004AB131 C3 ) NEXT, ( 34 bytes, 9 instructions ) Andrew Haley wrote: > ... > : ?# ( ud -- ud' t ) # 2dup or ; > : #,S ( ud -- 0 0 ) > begin > ?# while ?# while ?# while > [char] , hold > repeat then then ; ?# ( 004AB190 E8A70AF6FF ) CALL 0040BC3C # ( 004AB195 8BD3 ) MOV EDX, EBX ( 004AB197 0B5D00 ) OR EBX, [EBP] ( 004AB19A 8D6DFC ) LEA EBP, [EBP+-04] ( 004AB19D 895500 ) MOV [EBP], EDX ( 004AB1A0 C3 ) NEXT, ( 17 bytes, 6 instructions ) #,S ( 004AB1C0 E8CBFFFFFF ) CALL 004AB190 ?# ( 004AB1C5 85DB ) TEST EBX, EBX ( 004AB1C7 8B5D00 ) MOV EBX, [EBP] ( 004AB1CA 8D6D04 ) LEA EBP, [EBP+04] ( 004AB1CD 0F8438000000 ) JZ/E 004AB20B ( 004AB1D3 E8B8FFFFFF ) CALL 004AB190 ?# ( 004AB1D8 85DB ) TEST EBX, EBX ( 004AB1DA 8B5D00 ) MOV EBX, [EBP] ( 004AB1DD 8D6D04 ) LEA EBP, [EBP+04] ( 004AB1E0 0F8425000000 ) JZ/E 004AB20B ( 004AB1E6 E8A5FFFFFF ) CALL 004AB190 ?# ( 004AB1EB 85DB ) TEST EBX, EBX ( 004AB1ED 8B5D00 ) MOV EBX, [EBP] ( 004AB1F0 8D6D04 ) LEA EBP, [EBP+04] ( 004AB1F3 0F8412000000 ) JZ/E 004AB20B ( 004AB1F9 8D6DFC ) LEA EBP, [EBP+-04] ( 004AB1FC 895D00 ) MOV [EBP], EBX ( 004AB1FF BB2C000000 ) MOV EBX, 0000002C ( 004AB204 E8D309F6FF ) CALL 0040BBDC HOLD ( 004AB209 EBB5 ) JMP 004AB1C0 #,S ( 004AB20B C3 ) NEXT, ( 76 bytes, 21 instructions )
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-02 21:54 -0700 |
| Message-ID | <0534112b-a52f-446a-9849-17868b65b128@googlegroups.com> |
| In reply to | #60215 |
On Friday, June 2, 2017 at 11:28:52 PM UTC-5, HAA wrote: > Original using UNNEST: > > : ?# ( ud -- ud ) # 2dup d0= if unnest then ; > : #,S ( ud -- 0 0 ) begin ?# ?# ?# [char] , hold again ; > > ?# > ( 004AB0D0 E8670BF6FF ) CALL 0040BC3C # > ( 004AB0D5 8BD3 ) MOV EDX, EBX > ( 004AB0D7 0B5D00 ) OR EBX, [EBP] > ( 004AB0DA 8BDA ) MOV EBX, EDX > ( 004AB0DC 0F8503000000 ) JNZ/NE 004AB0E5 > ( 004AB0E2 83C404 ) ADD ESP, 04 > ( 004AB0E5 C3 ) NEXT, > ( 22 bytes, 7 instructions ) > > #,S > ( 004AB110 E8BBFFFFFF ) CALL 004AB0D0 ?# > ( 004AB115 E8B6FFFFFF ) CALL 004AB0D0 ?# > ( 004AB11A E8B1FFFFFF ) CALL 004AB0D0 ?# > ( 004AB11F 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB122 895D00 ) MOV [EBP], EBX > ( 004AB125 BB2C000000 ) MOV EBX, 0000002C > ( 004AB12A E8AD0AF6FF ) CALL 0040BBDC HOLD > ( 004AB12F EBDF ) JMP 004AB110 #,S > ( 004AB131 C3 ) NEXT, > ( 34 bytes, 9 instructions ) > > Andrew Haley wrote: > > ... > > : ?# ( ud -- ud' t ) # 2dup or ; > > : #,S ( ud -- 0 0 ) > > begin > > ?# while ?# while ?# while > > [char] , hold > > repeat then then ; > > ?# > ( 004AB190 E8A70AF6FF ) CALL 0040BC3C # > ( 004AB195 8BD3 ) MOV EDX, EBX > ( 004AB197 0B5D00 ) OR EBX, [EBP] > ( 004AB19A 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB19D 895500 ) MOV [EBP], EDX > ( 004AB1A0 C3 ) NEXT, > ( 17 bytes, 6 instructions ) > > #,S > ( 004AB1C0 E8CBFFFFFF ) CALL 004AB190 ?# > ( 004AB1C5 85DB ) TEST EBX, EBX > ( 004AB1C7 8B5D00 ) MOV EBX, [EBP] > ( 004AB1CA 8D6D04 ) LEA EBP, [EBP+04] > ( 004AB1CD 0F8438000000 ) JZ/E 004AB20B > ( 004AB1D3 E8B8FFFFFF ) CALL 004AB190 ?# > ( 004AB1D8 85DB ) TEST EBX, EBX > ( 004AB1DA 8B5D00 ) MOV EBX, [EBP] > ( 004AB1DD 8D6D04 ) LEA EBP, [EBP+04] > ( 004AB1E0 0F8425000000 ) JZ/E 004AB20B > ( 004AB1E6 E8A5FFFFFF ) CALL 004AB190 ?# > ( 004AB1EB 85DB ) TEST EBX, EBX > ( 004AB1ED 8B5D00 ) MOV EBX, [EBP] > ( 004AB1F0 8D6D04 ) LEA EBP, [EBP+04] > ( 004AB1F3 0F8412000000 ) JZ/E 004AB20B > ( 004AB1F9 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB1FC 895D00 ) MOV [EBP], EBX > ( 004AB1FF BB2C000000 ) MOV EBX, 0000002C > ( 004AB204 E8D309F6FF ) CALL 0040BBDC HOLD > ( 004AB209 EBB5 ) JMP 004AB1C0 #,S > ( 004AB20B C3 ) NEXT, > ( 76 bytes, 21 instructions ) One million runs on my machine with iForth, three times: unnest: 0.216 seconds elapsed. flag: 0.174 seconds elapsed. unnest: 0.174 seconds elapsed. flag: 0.172 seconds elapsed. unnest: 0.173 seconds elapsed. flag: 0.172 seconds elapsed. With 1s sleep between the benchmarks: unnest: 0.210 seconds elapsed. flag: 0.172 seconds elapsed. unnest: 0.233 seconds elapsed. flag: 0.173 seconds elapsed. unnest: 0.219 seconds elapsed. flag: 0.174 seconds elapsed. ok Meanwhile, on lina64, counting in TICKS: ( TICKS-PER-SECOND . 2910054919 OK ) 7k runs unnest: 55658846 flag: 50831050 difference: 4827796 70k runs unnest: 112536218 flag: 76954459 difference: 35581759 700k runs unnest: 736397375 flag: 722087215 difference: 14310160 Better stick with the style arguments for UNNEST.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-06-04 22:52 +1000 |
| Message-ID | <oh0vpp$hg8$1@gioia.aioe.org> |
| In reply to | #60216 |
Julian Fondren wrote: > ... > One million runs on my machine with iForth, three times: > ... I don't expect much speed difference as much of the execution time will be tied up in # (see below). As not too many apps will be executing #,S a million times, I would give preference to other considerations such as simplicity of code and resulting footprint. # ( 0040BC3C 8D6DFC ) LEA EBP, [EBP+-04] ( 0040BC3F 895D00 ) MOV [EBP], EBX ( 0040BC42 8B5E18 ) MOV EBX, [ESI+18] ( 0040BC45 E8DED5FFFF ) CALL 00409228 MU/MOD ( 0040BC4A 837D0409 ) CMP [EBP+04], 09 ( 0040BC4E 8BD3 ) MOV EDX, EBX ( 0040BC50 8B5D04 ) MOV EBX, [EBP+04] ( 0040BC53 8B4D00 ) MOV ECX, [EBP] ( 0040BC56 894D04 ) MOV [EBP+04], ECX ( 0040BC59 895500 ) MOV [EBP], EDX ( 0040BC5C 7E03 ) JLE/NG 0040BC61 ( 0040BC5E 83C307 ) ADD EBX, 07 ( 0040BC61 83C330 ) ADD EBX, 30 ( 0040BC64 E873FFFFFF ) CALL 0040BBDC HOLD ( 0040BC69 C3 ) NEXT, ( 46 bytes, 15 instructions ) HOLD ( 0040BBDC 83461CFF ) ADD [ESI+1C], -01 ( 0040BBE0 8B561C ) MOV EDX, [ESI+1C] ( 0040BBE3 881A ) MOV 0 [EDX], BL ( 0040BBE5 8B5D00 ) MOV EBX, [EBP] ( 0040BBE8 8D6D04 ) LEA EBP, [EBP+04] ( 0040BBEB C3 ) NEXT, ( 16 bytes, 6 instructions ) MU/MOD ( 00409228 53 ) PUSH EBX ( 00409229 8B1C24 ) MOV EBX, [ESP] ( 0040922C 8B4500 ) MOV EAX, [EBP] ( 0040922F BA00000000 ) MOV EDX, 00000000 ( 00409234 F7F3 ) DIV EBX ( 00409236 5B ) POP EBX ( 00409237 50 ) PUSH EAX ( 00409238 8B4504 ) MOV EAX, [EBP+04] ( 0040923B F7F3 ) DIV EBX ( 0040923D 5B ) POP EBX ( 0040923E 894500 ) MOV [EBP], EAX ( 00409241 895504 ) MOV [EBP+04], EDX ( 00409244 C3 ) NEXT, ( 29 bytes, 13 instructions )
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-02 22:24 -0700 |
| Message-ID | <ae752189-c36a-4a1d-af8c-8106c40d47f1@googlegroups.com> |
| In reply to | #60215 |
On Friday, June 2, 2017 at 11:28:52 PM UTC-5, HAA wrote:
> Original using UNNEST:
>
> : ?# ( ud -- ud ) # 2dup d0= if unnest then ;
> : #,S ( ud -- 0 0 ) begin ?# ?# ?# [char] , hold again ;
>
> ?#
> ( 004AB0D0 E8670BF6FF ) CALL 0040BC3C #
> ( 004AB0D5 8BD3 ) MOV EDX, EBX
> ( 004AB0D7 0B5D00 ) OR EBX, [EBP]
> ( 004AB0DA 8BDA ) MOV EBX, EDX
> ( 004AB0DC 0F8503000000 ) JNZ/NE 004AB0E5
> ( 004AB0E2 83C404 ) ADD ESP, 04
> ( 004AB0E5 C3 ) NEXT,
> ( 22 bytes, 7 instructions )
>
> #,S
> ( 004AB110 E8BBFFFFFF ) CALL 004AB0D0 ?#
> ( 004AB115 E8B6FFFFFF ) CALL 004AB0D0 ?#
> ( 004AB11A E8B1FFFFFF ) CALL 004AB0D0 ?#
> ( 004AB11F 8D6DFC ) LEA EBP, [EBP+-04]
> ( 004AB122 895D00 ) MOV [EBP], EBX
> ( 004AB125 BB2C000000 ) MOV EBX, 0000002C
> ( 004AB12A E8AD0AF6FF ) CALL 0040BBDC HOLD
> ( 004AB12F EBDF ) JMP 004AB110 #,S
> ( 004AB131 C3 ) NEXT,
> ( 34 bytes, 9 instructions )
eh hold on, this is VFX, and run through the optimizer. Did you test
this code except in once-off interactive usage?
123456. <# #,s1 #> type 123,456 ok
ok good.
: x 123456. <# #,s1 #> type ; ok
x .s type
DATA STACK
top
0 0000:0000
0 0000:0000
ok
lol what.
it runs fine with the optimizer off, from UNNEST thru #,S
With these results:
see ?#
?#
( 080C0B70 E8B321F9FF ) CALL 08052D28 #
( 080C0B75 8BD3 ) MOV EDX, EBX
( 080C0B77 0B5D00 ) OR EBX, [EBP]
( 080C0B7A 8D6DFC ) LEA EBP, [EBP+-04]
( 080C0B7D 895500 ) MOV [EBP], EDX
( 080C0B80 C3 ) NEXT,
( 17 bytes, 6 instructions )
ok
see #,s1
#,S1
( 080C0B20 E89BFFFFFF ) CALL 080C0AC0 ?#
( 080C0B25 E896FFFFFF ) CALL 080C0AC0 ?#
( 080C0B2A E891FFFFFF ) CALL 080C0AC0 ?#
( 080C0B2F E8C469F9FF2C000000 ) CALL 080574F8 LIT 0000002C
( 080C0B38 E84B21F9FF ) CALL 08052C88 HOLD
( 080C0B3D E84EF8F8FF200B0C08 ) CALL 08050390 BRANCH 080C0B20
( 080C0B46 C3 ) NEXT,
( 39 bytes, 7 instructions )
ok
One million runs with a 1s sleep between them, results in ms:
unnest: 220
flag: 70
unnest: 210
flag: 70
unnest: 220
flag: 70
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web