Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49933 > unrolled thread
| Started by | foxaudioresearch@gmail.com |
|---|---|
| First post | 2016-08-10 13:06 -0700 |
| Last post | 2016-08-28 22:34 +0200 |
| Articles | 20 on this page of 202 — 33 participants |
Back to article view | Back to comp.lang.forth
"Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-10 13:06 -0700
Re: "Forth is Sudoku for programmers" "WJ" <w_a_x_man@yahoo.com> - 2016-08-10 21:00 +0000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-10 23:26 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 00:25 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-11 01:29 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 16:09 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-11 19:31 -0500
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-12 12:22 +1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 19:59 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-11 18:23 -1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 21:57 -0700
Re: "Forth is Sudoku for programmers" mhx@iae.nl - 2016-08-11 23:20 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 23:49 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 08:52 +0000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-15 02:31 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 22:43 +1000
Re: "Forth is Sudoku for programmers" stephen@mpeforth.com (Stephen Pelc) - 2016-08-15 14:49 +0000
Re: "Forth is Sudoku for programmers" Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 21:24 +0000
Re: "Forth is Sudoku for programmers" Ron Aaron <rambamist@gmail.com> - 2016-08-22 07:04 +0300
Re: "Forth is Sudoku for programmers" Lars Brinkhoff <lars.spam@nocrew.org> - 2016-08-26 07:12 +0200
Re: "Forth is Sudoku for programmers" Ron Aaron <rambamist@gmail.com> - 2016-08-26 09:18 +0300
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:12 +0200
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 00:04 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 01:34 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 02:17 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 08:53 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 11:54 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-12 17:38 -0400
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 20:02 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 07:10 +0000
Re: "Forth is Sudoku for programmers" Alex McDonald <alex@rivadpm.com> - 2016-08-15 08:34 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-15 01:11 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:23 +0200
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-28 14:26 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-29 01:44 -0500
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-29 00:45 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 14:56 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 15:02 -0700
Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-12 22:05 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 21:05 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:15 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 23:39 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 00:03 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 00:07 -0700
Re: "Forth is Sudoku for programmers" Doug Hoffman <glidedog@gmail.com> - 2016-08-13 07:35 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 17:17 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:04 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:38 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-13 20:46 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 06:02 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-14 23:04 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 16:01 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-13 21:53 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-14 07:45 -0700
Re: "Forth is Sudoku for programmers" franck.bensusan@gmail.com - 2016-08-15 06:44 -0700
Re: "Forth is Sudoku for programmers" Melzzzzz <mel@zzzzz.com> - 2016-08-14 19:57 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 11:17 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:59 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 14:09 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 15:48 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-14 18:34 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 02:24 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 19:26 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-21 14:58 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:51 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 15:52 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-24 16:35 -0700
Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-14 10:32 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-14 13:55 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 21:37 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-28 15:25 -0700
Re: "Forth is Sudoku for programmers" jim.brakefield@ieee.org - 2016-08-28 16:16 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-28 16:44 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-13 20:00 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-13 20:39 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-12 22:11 -1000
Re: "Forth is Sudoku for programmers" dhoffman888@gmail.com - 2016-08-13 03:39 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 20:18 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:35 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 22:52 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 22:55 -0700
Re: "Forth is Sudoku for programmers" Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-08-13 11:31 +0100
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 11:47 +1000
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-15 12:05 +1000
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 08:21 +0000
Re: "Forth is Sudoku for programmers" Brad Eckert <hwfwguy@gmail.com> - 2016-08-17 22:54 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-12 14:51 +1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 21:59 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-13 18:04 +1000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-11 23:16 -0700
Re: "Forth is Sudoku for programmers" "HAA" <someone@microsoft.com> - 2016-08-13 18:47 +1000
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-11 22:59 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-11 20:54 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-12 12:36 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-12 15:10 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-12 17:45 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-15 18:40 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-15 20:18 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:18 +0200
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-10 15:38 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-10 16:18 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:39 +0000
Re: "Forth is Sudoku for programmers" Brad Eckert <hwfwguy@gmail.com> - 2016-08-12 00:23 -0700
Re: "Forth is Sudoku for programmers" "WJ" <w_a_x_man@yahoo.com> - 2016-08-21 01:56 +0000
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-10 20:28 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 00:23 -0700
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:26 +0000
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 11:06 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 11:51 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 01:48 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-11 01:52 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-13 09:42 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-13 13:36 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-14 07:06 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-14 14:10 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-16 00:46 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-16 00:57 -0700
Re: "Forth is Sudoku for programmers" humptydumpty <ouatubi@gmail.com> - 2016-08-16 04:45 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-18 02:16 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 03:04 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-18 09:30 -0500
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-18 07:44 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-18 11:36 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 13:41 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-18 14:01 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-18 14:33 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-18 16:23 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-18 17:28 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-18 18:59 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-18 19:07 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-29 01:09 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-18 17:21 -1000
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-18 23:36 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 00:11 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-19 01:44 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 01:46 -0700
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:29 +0200
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-31 03:43 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-19 03:49 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 02:18 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-20 05:05 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-20 15:13 -0700
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-21 16:33 -0500
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-21 19:37 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 20:02 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:36 -1000
Re: "Forth is Sudoku for programmers" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-22 03:36 -0500
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-19 08:40 -0500
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-19 15:59 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 16:28 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 16:31 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 17:24 -0700
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 19:48 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-19 20:17 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:16 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:19 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-20 03:13 -0700
Re: "Forth is Sudoku for programmers" foxaudioresearch@gmail.com - 2016-08-20 07:03 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 12:21 -0500
Re: "Forth is Sudoku for programmers" Coos Haak <htrofhc@gmail.com> - 2016-08-20 20:39 +0200
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 15:41 -0500
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 14:40 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-20 17:25 -0500
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-20 20:14 -0700
Re: "Forth is Sudoku for programmers" julian.fondren@endurance.com - 2016-08-20 20:30 -0700
Re: "Forth is Sudoku for programmers" Cecil Bayona <cbayona@cbayona.com> - 2016-08-21 13:46 -0500
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 20:13 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 12:37 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 21:11 +0100
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 13:19 -1000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 19:03 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-22 06:45 +0100
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:38 -1000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:43 +0200
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-21 08:57 +0000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:40 +0200
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-21 09:57 +0000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 11:29 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 11:56 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 12:11 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 12:26 -0700
Re: "Forth is Sudoku for programmers" Paul Rubin <no.email@nospam.invalid> - 2016-08-21 12:52 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-22 07:12 +0100
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 23:43 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-21 21:40 -1000
Re: "Forth is Sudoku for programmers" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-22 17:20 +0000
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-21 13:01 -0700
Re: "Forth is Sudoku for programmers" Julian Fondren <julian.fondren@gmail.com> - 2016-08-21 13:16 -0700
Re: "Forth is Sudoku for programmers" Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-21 20:19 +0100
Re: "Forth is Sudoku for programmers" stephen@mpeforth.com (Stephen Pelc) - 2016-08-21 17:41 +0000
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-20 02:09 -0700
Re: "Forth is Sudoku for programmers" hughaguilar96@gmail.com - 2016-08-20 20:04 -0700
Re: "Forth is Sudoku for programmers" "Elizabeth D. Rather" <erather@forth.com> - 2016-08-19 09:40 -1000
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-19 13:48 -0700
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-26 01:13 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-26 04:26 -0400
Re: "Forth is Sudoku for programmers" lehs <skydda.barnen@gmail.com> - 2016-08-26 03:06 -0700
Re: "Forth is Sudoku for programmers" rickman <gnuarm@gmail.com> - 2016-08-26 11:54 -0400
Re: "Forth is Sudoku for programmers" lawrencedo99@gmail.com - 2016-08-26 20:43 -0700
Re: "Forth is Sudoku for programmers" Mark Wills <markwills1970@gmail.com> - 2016-08-27 04:20 -0700
Re: "Forth is Sudoku for programmers" Bernd Paysan <bernd@net2o.de> - 2016-08-28 00:04 +0000
Re: "Forth is Sudoku for programmers" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-28 22:34 +0200
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-20 15:41 -0500 |
| Message-ID | <npaf9v$ahq$1@dont-email.me> |
| In reply to | #50287 |
On 8/20/2016 1:39 PM, Coos Haak wrote: > Op Sat, 20 Aug 2016 12:21:15 -0500 schreef Cecil Bayona: > >> Some rather be kings of a heap of ashes rather just one of the boys so I >> would not place a lot of hope that they will lift Forth from it's >> current status, a useless toy with tremendous lost potential. Enhance >> the Forth you use to make a usable tool and disregard what the "experts" >> say. >> >> Take the ANS Standard as an example, a mess of contradictions and >> ambiguities with missing critical pieces, so what is being done? More of >> the same, doubling down on past mistakes, a Standard that approves >> everything that existed beforehand, after all we wouldn't want to hurt >> peoples feelings, but it's meaningless. Even the major players disregard >> it to make their products usable. > > Now spit it out: what contradictions are in the 94 or 2012 standards? > I have seen enough of these grandiose meaningless explications. > > groet Coos > All the warts in the 94 Standard will continue to be there as they claim is that all features of the 94 Standard will be kept, that includes all the ambiguity in many words, that is not what a standard is supposed to be.. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-20 14:40 -0700 |
| Message-ID | <87zio7rue2.fsf@jester.gateway.pace.com> |
| In reply to | #50294 |
Cecil Bayona <cbayona@cbayona.com> writes: > All the warts in the 94 Standard will continue to be there Can you give any concrete examples? I don't remember many things from the 94 standard whose presence seems bad to me, to the point where they should be removed. I do think it could be improved by adding some things that are currently absent.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-20 17:25 -0500 |
| Message-ID | <npalce$vu8$1@dont-email.me> |
| In reply to | #50297 |
On 8/20/2016 4:40 PM, Paul Rubin wrote: > Cecil Bayona <cbayona@cbayona.com> writes: >> All the warts in the 94 Standard will continue to be there > > Can you give any concrete examples? I don't remember many things from > the 94 standard whose presence seems bad to me, to the point where they > should be removed. I do think it could be improved by adding some > things that are currently absent. > There are many words that in one case the interpretive definition is undefined. Not illegal but undefined so how they are treated varies all over the place; abort" not defined for interpretive mode, SwiftForth returns a 0 on the stack, MPE prints an error message that it's not available (my preferred choice) yet both are ANS compatible Forth. There are many cases of words with undefined conditions, they need clarity and the standard should define how they are treated. Like I said before on my response, pick your favorite Forth and extend it with the words you use to create applications, unfortunately the Standard is too vague is many cases. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-20 20:14 -0700 |
| Message-ID | <87k2fastho.fsf@jester.gateway.pace.com> |
| In reply to | #50300 |
Cecil Bayona <cbayona@cbayona.com> writes: > There are many words that in one case the interpretive definition is > undefined. Not illegal but undefined so how they are treated varies > all over the place; Hmm, so you're saying there are gaps in the standard that can't be filled because any fix would break somebody's existing code somewhere. OK I guess that's a problem. The standard failing to specify how to do something is different than it specifying doing something bad, but I see why it's still not always easy to fix.
[toc] | [prev] | [next] | [standalone]
| From | julian.fondren@endurance.com |
|---|---|
| Date | 2016-08-20 20:30 -0700 |
| Message-ID | <808639fd-a6be-4d88-a54d-499d906016a0@googlegroups.com> |
| In reply to | #50306 |
On Saturday, August 20, 2016 at 10:15:01 PM UTC-5, Paul Rubin wrote: > Hmm, so you're saying there are gaps in the standard that can't be > filled because any fix would break somebody's existing code somewhere. That would be the case if interpreted ABORT" were common. But the only variation of implementation even described are the different ways that interpretive ABORT" fails to be useful to anyone. Standardizing a behavior for interpretive ABORT" would just mean that a feature nobody used except to have their system complain or break, would now potentially have a use. In Forth, not every word is useful in interpreted code, control-flow words most remarkably.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-21 13:46 -0500 |
| Message-ID | <npcstp$b59$1@dont-email.me> |
| In reply to | #50309 |
On 8/20/2016 10:30 PM, julian.fondren@endurance.com wrote: > On Saturday, August 20, 2016 at 10:15:01 PM UTC-5, Paul Rubin wrote: > >> Hmm, so you're saying there are gaps in the standard that can't be >> filled because any fix would break somebody's existing code somewhere. > > That would be the case if interpreted ABORT" were common. But the > only variation of implementation even described are the different ways > that interpretive ABORT" fails to be useful to anyone. Standardizing > a behavior for interpretive ABORT" would just mean that a feature > nobody used except to have their system complain or break, would now > potentially have a use. > > In Forth, not every word is useful in interpreted code, control-flow > words most remarkably. > The point being that one Standard system allows the code to run and the other one stops and gives an error message yet both are compatible with the ANS Standard. That word is one of many that have similar issues. ." is another word with wide varying results, in SwiftForth my system crashed on some occasions in others it pushes a 5 on the stack, MPE printed the string. It's more like the Wild West, anything goes, not much of a Standard in these cases. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-21 20:13 +0100 |
| Message-ID | <npcuge$guu$1@dont-email.me> |
| In reply to | #50338 |
On 21/08/2016 19:46, Cecil Bayona wrote: > > > On 8/20/2016 10:30 PM, julian.fondren@endurance.com wrote: >> On Saturday, August 20, 2016 at 10:15:01 PM UTC-5, Paul Rubin wrote: >> >>> Hmm, so you're saying there are gaps in the standard that can't be >>> filled because any fix would break somebody's existing code somewhere. >> >> That would be the case if interpreted ABORT" were common. But the >> only variation of implementation even described are the different ways >> that interpretive ABORT" fails to be useful to anyone. Standardizing >> a behavior for interpretive ABORT" would just mean that a feature >> nobody used except to have their system complain or break, would now >> potentially have a use. >> >> In Forth, not every word is useful in interpreted code, control-flow >> words most remarkably. >> > The point being that one Standard system allows the code to run and the > other one stops and gives an error message yet both are compatible with > the ANS Standard. That word is one of many that have similar issues. ." > is another word with wide varying results, in SwiftForth my system > crashed on some occasions in others it pushes a 5 on the stack, MPE > printed the string. It's more like the Wild West, anything goes, not > much of a Standard in these cases. > No it's not the standard's fault, it's yours for doing things the standard doesn't cover and expecting different systems to exhibit the same behaviour for non-standard code. Use ." inside a colon definition and .( in interpretation mode. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 12:37 -0700 |
| Message-ID | <ec0f37db-1b0b-45a7-9ec4-000faa8afbd2@googlegroups.com> |
| In reply to | #50345 |
On Sunday, August 21, 2016 at 12:13:20 PM UTC-7, Gerry wrote: > On 21/08/2016 19:46, Cecil Bayona wrote: > > The point being that one Standard system allows the code to run and the > > other one stops and gives an error message yet both are compatible with > > the ANS Standard. That word is one of many that have similar issues. ." > > is another word with wide varying results, in SwiftForth my system > > crashed on some occasions in others it pushes a 5 on the stack, MPE > > printed the string. It's more like the Wild West, anything goes, not > > much of a Standard in these cases. > > No it's not the standard's fault, it's yours for doing things the > standard doesn't cover and expecting different systems to exhibit the > same behaviour for non-standard code. Use ." inside a colon definition > and .( in interpretation mode. Gerry is right about this --- some Forth systems (OpenForth) experimented with STATE-smart words so IF and ." etc. could be used in interpretive mode --- this was a bad idea, and this bad idea was not included in ANS-Forth. A lot of bad ideas were included in ANS-Forth though --- for example, what happens when tick or FIND are used to obtain the xt of a word such as IF or ." that doesn't have any interpretation semantics? --- that is ambiguous, and you can't count on the xt being executable even inside of a colon word (VFX has non-executable execution tokens). This problem is fixed by my disambiguifiers --- I think Cecil has a somewhat tangled up conception of the problem with FIND and he also doesn't know about the solution (the disambiguifiers). There are other cases of ambiguity in ANS-Forth that I can't fix. For example: section (3.2.3.2) The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. What happened here is that some Forth systems have the control-flow stack distinct from the data-stack (this makes sense because meta-compiling words have access to their own data, without the control-flow data getting in the way). SwiftForth has the control-flow stack being the same as the data-stack (most likely because nobody at Forth Inc. has ever written a meta-compiling word and hence doesn't know how they work). Elizabeth Rather, in her effort to please everybody (just like the ultra-liberal kindergarten teacher) said that both methods are ANS-Forth compliant, but you can't actually assume that the control-flow stack and the data-stack are distinct --- you have to assume the worst-case scenario, which is that you are using SwiftForth that has the control-flow data intermingled with the user's data.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-21 21:11 +0100 |
| Message-ID | <npd1sm$tgk$1@dont-email.me> |
| In reply to | #50350 |
On 21/08/2016 20:37, hughaguilar96@gmail.com wrote: > There are other cases of ambiguity in ANS-Forth that I can't fix. For example: > > section (3.2.3.2) > The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed. > Yes, that always seemed a bad idea to me, so much so that my system has always had a separate control flow stack. I remember when I said something like that several years ago I got severely criticised by the traditionalists. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-21 13:19 -1000 |
| Message-ID | <ytidnQYQLY16qyfKnZ2dnUU7-IPNnZ2d@supernews.com> |
| In reply to | #50353 |
On 8/21/16 10:11 AM, Gerry Jackson wrote: > On 21/08/2016 20:37, hughaguilar96@gmail.com wrote: >> There are other cases of ambiguity in ANS-Forth that I can't fix. For >> example: >> >> section (3.2.3.2) >> The control-flow stack may, but need not, physically exist in an >> implementation. If it does exist, it may be, but need not be, >> implemented using the data stack. The format of the control-flow stack >> is implementation defined. Since the control-flow stack may be >> implemented using the data stack, items placed on the data stack are >> unavailable to a program after items are placed on the control-flow >> stack and remain unavailable until the control-flow stack items are >> removed. >> > > Yes, that always seemed a bad idea to me, so much so that my system has > always had a separate control flow stack. I remember when I said > something like that several years ago I got severely criticised by the > traditionalists. And what has that allowed you to do that you couldn't previously? The reason generations of Forth implementer have found it convenient (and neither confusing nor limiting) to use the data stack as the control flow stack is that the control flow stack only exists during compilation, when it is rarely necessary to carry other kinds of items on the data stack. But, if it makes you happy, enjoy! Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 19:03 -0700 |
| Message-ID | <527011dd-641f-4e1c-8fb3-aecf97171ea3@googlegroups.com> |
| In reply to | #50368 |
On Sunday, August 21, 2016 at 4:19:08 PM UTC-7, Elizabeth D. Rather wrote: > On 8/21/16 10:11 AM, Gerry Jackson wrote: > > On 21/08/2016 20:37, hughaguilar96@gmail.com wrote: > >> There are other cases of ambiguity in ANS-Forth that I can't fix. For > >> example: > >> > >> section (3.2.3.2) > >> The control-flow stack may, but need not, physically exist in an > >> implementation. If it does exist, it may be, but need not be, > >> implemented using the data stack. The format of the control-flow stack > >> is implementation defined. Since the control-flow stack may be > >> implemented using the data stack, items placed on the data stack are > >> unavailable to a program after items are placed on the control-flow > >> stack and remain unavailable until the control-flow stack items are > >> removed. > >> > > > > Yes, that always seemed a bad idea to me, so much so that my system has > > always had a separate control flow stack. I remember when I said > > something like that several years ago I got severely criticised by the > > traditionalists. > > And what has that allowed you to do that you couldn't previously? The > reason generations of Forth implementer have found it convenient (and > neither confusing nor limiting) to use the data stack as the control > flow stack is that the control flow stack only exists during > compilation, when it is rarely necessary to carry other kinds of items > on the data stack. > > But, if it makes you happy, enjoy! Rarely? You mean, other than in every meta-compilation word. Most likely, nobody at Forth Inc. knows what meta-compilation is, which is why this seems so rare to you. ANS-Forth programmers are required to work around the incompetence of Elizabeth Rather. Here is an example of Bernd Paysan (Forth-200x committee member) working around the problem of control-flow data being intermingled with user data (he holds his data on the return-stack): https://groups.google.com/forum/#!searchin/comp.lang.forth/queens%7Csort:date/comp.lang.forth/THP64AeGuS0/cUDnhpVxZacJ On Sunday, March 22, 2015 at 2:11:03 PM UTC-7, Bernd Paysan wrote: > Paul Rubin wrote: > > > Bernd Paysan <bernd.paysan@gmx.de> writes: > >> Of course Forth has first-class functions. We call them "xt", execution > >> tokens. You can pass them as parameters to other words, you can return > >> an xt as result of a word, you can use xts to define higher order > >> functions. > > > > Hmm, ok, I hadn't thought of xt's as first-class functions but maybe > > they are. Is it possible to create them at runtime? I.e. is there an > > ANS portable way to do something like: > > > > \ given functions f and g, make a new function that composes them > > : compose ( xt1 xt2 -- xt3 ) .... ; > > > > So this should work: > > > > ['] sin ['] sqrt compose constant sin-sqrt => ok > > > > 2e sin-sqrt execute f. => 0.9877659459927356 ok > > > > That number is sin(sqrt(2)). "Compose" has made a new xt that combines > > the actions of the previous two. It's like adding two numbers in order > > to create a new number. I'd say that to call xt's first class > > functions, you have to be able to do this. > > Sure, no doubts about that. So let's do it: > > : compose ( xt1 xt2 -- xt3 ) swap >r >r > :noname r> compile, r> compile, postpone ; ; > > Fixing the bugs in your code, to test it: > > ' fsin ' fsqrt compose constant sin-sqrt ok > 2e sin-sqrt execute f. 0.987765945992736 ok > > Are you happy with that?
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-08-22 06:45 +0100 |
| Message-ID | <npe3i1$mm6$1@dont-email.me> |
| In reply to | #50368 |
On 22/08/2016 00:19, Elizabeth D. Rather wrote: > On 8/21/16 10:11 AM, Gerry Jackson wrote: >> On 21/08/2016 20:37, hughaguilar96@gmail.com wrote: >>> There are other cases of ambiguity in ANS-Forth that I can't fix. For >>> example: >>> >>> section (3.2.3.2) >>> The control-flow stack may, but need not, physically exist in an >>> implementation. If it does exist, it may be, but need not be, >>> implemented using the data stack. The format of the control-flow stack >>> is implementation defined. Since the control-flow stack may be >>> implemented using the data stack, items placed on the data stack are >>> unavailable to a program after items are placed on the control-flow >>> stack and remain unavailable until the control-flow stack items are >>> removed. >>> >> >> Yes, that always seemed a bad idea to me, so much so that my system has >> always had a separate control flow stack. I remember when I said >> something like that several years ago I got severely criticised by the >> traditionalists. > > And what has that allowed you to do that you couldn't previously? During compilation, the ability to pass data into and out of colon definitions and across control words like IF without having to stick it on the return stack before and after e.g. see the definitions of OF and ENDOF in section A.3.2.2.2 of the standard. I know there are work arounds for these things but it is far more convenient to not have to even think about it. Of course if I want to write something portable I still have to worry about it and it's a pain that other systems still use the data stack. Also as the control-flow stack is there it has other uses during compilation. > The > reason generations of Forth implementer have found it convenient (and > neither confusing nor limiting) to use the data stack as the control > flow stack is that the control flow stack only exists during > compilation, when it is rarely necessary to carry other kinds of items > on the data stack. I suspect it was done originally because of the limited amount of memory available in early systems, then a virtue was made of necessity - but you'd know better than me about that. > > But, if it makes you happy, enjoy! Quite. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-21 21:38 -1000 |
| Message-ID | <XNSdnRCG8fmVMSfKnZ2dnUU7-b1QAAAA@supernews.com> |
| In reply to | #50386 |
On 8/21/16 7:45 PM, Gerry Jackson wrote: > On 22/08/2016 00:19, Elizabeth D. Rather wrote: >> On 8/21/16 10:11 AM, Gerry Jackson wrote: >>> On 21/08/2016 20:37, hughaguilar96@gmail.com wrote: >>>> There are other cases of ambiguity in ANS-Forth that I can't fix. For >>>> example: >>>> >>>> section (3.2.3.2) >>>> The control-flow stack may, but need not, physically exist in an >>>> implementation. If it does exist, it may be, but need not be, >>>> implemented using the data stack. The format of the control-flow stack >>>> is implementation defined. Since the control-flow stack may be >>>> implemented using the data stack, items placed on the data stack are >>>> unavailable to a program after items are placed on the control-flow >>>> stack and remain unavailable until the control-flow stack items are >>>> removed. >>>> >>> >>> Yes, that always seemed a bad idea to me, so much so that my system has >>> always had a separate control flow stack. I remember when I said >>> something like that several years ago I got severely criticised by the >>> traditionalists. >> >> And what has that allowed you to do that you couldn't previously? > > During compilation, the ability to pass data into and out of colon > definitions and across control words like IF without having to stick it > on the return stack before and after e.g. see the definitions of OF and > ENDOF in section A.3.2.2.2 of the standard. I know there are work > arounds for these things but it is far more convenient to not have to > even think about it. Of course if I want to write something portable I > still have to worry about it and it's a pain that other systems still > use the data stack. > > Also as the control-flow stack is there it has other uses during > compilation. > >> The >> reason generations of Forth implementer have found it convenient (and >> neither confusing nor limiting) to use the data stack as the control >> flow stack is that the control flow stack only exists during >> compilation, when it is rarely necessary to carry other kinds of items >> on the data stack. > > I suspect it was done originally because of the limited amount of memory > available in early systems, then a virtue was made of necessity > - but you'd know better than me about that. Mostly programming ease, avoiding the necessity for creating and maintaining a whole new structure that's very rarely useful. Cheers, Elizabeth >> >> But, if it makes you happy, enjoy! > > Quite. > -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-08-28 22:43 +0200 |
| Message-ID | <npvidf$je7$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #50309 |
In article <808639fd-a6be-4d88-a54d-499d906016a0@googlegroups.com>,
<julian.fondren@endurance.com> wrote:
>On Saturday, August 20, 2016 at 10:15:01 PM UTC-5, Paul Rubin wrote:
>
>> Hmm, so you're saying there are gaps in the standard that can't be
>> filled because any fix would break somebody's existing code somewhere.
>
>That would be the case if interpreted ABORT" were common. But the
>only variation of implementation even described are the different ways
>that interpretive ABORT" fails to be useful to anyone. Standardizing
>a behavior for interpretive ABORT" would just mean that a feature
>nobody used except to have their system complain or break, would now
>potentially have a use.
>
>In Forth, not every word is useful in interpreted code, control-flow
>words most remarkably.
Maybe not the best example.
Since
WANT -scripting-
I do things like
10 0 DO . H. CR LOOP
all the time.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-21 08:57 +0000 |
| Message-ID | <2016Aug21.105754@mips.complang.tuwien.ac.at> |
| In reply to | #50300 |
Cecil Bayona <cbayona@cbayona.com> writes:
>
>
>On 8/20/2016 4:40 PM, Paul Rubin wrote:
>> Cecil Bayona <cbayona@cbayona.com> writes:
>>> All the warts in the 94 Standard will continue to be there
>>
>> Can you give any concrete examples? I don't remember many things from
>> the 94 standard whose presence seems bad to me, to the point where they
>> should be removed. I do think it could be improved by adding some
>> things that are currently absent.
>>
>There are many words that in one case the interpretive definition is
>undefined. Not illegal but undefined so how they are treated varies all
>over the place;
>
>abort" not defined for interpretive mode, SwiftForth returns a 0 on the
>stack, MPE prints an error message that it's not available (my preferred
>choice) yet both are ANS compatible Forth.
So in your opinion the standard should define interpretation semantics
for ABORT". Ok, so what if the standard did that, and made the
SwiftForth behaviour standard? Then VFX could not perform the
behaviour you prefer if it wanted to be standard. Would that be
better than the current situation?
And is there really a problem with the current situation wrt. ABORT"?
Apparently interpretive ABORT" delivering an error is ok with you, so
you probably won't be using interpretive ABORT" in a program; so for
your program, what the system does when encountering an interpretive
ABORT" does not matter; as an interface between programs and systems,
this aspect of the standard is no problem. Of course, during
development, if you happen to use interpretive ABORT", it's nicer if
the system gives an error.
BTW, SwiftForth's ABORT" is an example of the surprises that
STATE-smart words offer: ABORT" itself is immediate and not directly
STATE-smart, but it calls STATE-smart S". As a result, interpretive
ABORT" has some funny combination of behaviours, that's unlikely to be
intended:
: foo s" xyz" [ abort" abc" ok
type abc ok
] ; ok
true foo foo xyz
For comparison, here's what current development Gforth does:
: foo [ abort" abc" ] ;
*terminal*:1:9: abort" is compile-only ok
true foo
*the terminal*:2: error: abc
true foo
The first message is in blue (warning), the second in red (error).
>There are many cases of words
>with undefined conditions, they need clarity and the standard should
>define how they are treated.
You don't want a standard, you want an implementation.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-08-28 22:40 +0200 |
| Message-ID | <npvi8g$jdk$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #50300 |
In article <npalce$vu8$1@dont-email.me>, Cecil Bayona <cbayona@cbayona.com> wrote: > > >On 8/20/2016 4:40 PM, Paul Rubin wrote: >> Cecil Bayona <cbayona@cbayona.com> writes: >>> All the warts in the 94 Standard will continue to be there >> >> Can you give any concrete examples? I don't remember many things from >> the 94 standard whose presence seems bad to me, to the point where they >> should be removed. I do think it could be improved by adding some >> things that are currently absent. >> >There are many words that in one case the interpretive definition is >undefined. Not illegal but undefined so how they are treated varies all >over the place; > >abort" not defined for interpretive mode, SwiftForth returns a 0 on the >stack, MPE prints an error message that it's not available (my preferred >choice) yet both are ANS compatible Forth. There are many cases of words >with undefined conditions, they need clarity and the standard should >define how they are treated. We have been over this again and again. Standard Forths are only supposed to compile Standard Programs. <SNIP> >-- >Cecil - k5nwa -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-21 09:57 +0000 |
| Message-ID | <2016Aug21.115739@mips.complang.tuwien.ac.at> |
| In reply to | #50294 |
Cecil Bayona <cbayona@cbayona.com> writes:
>All the warts in the 94 Standard will continue to be there as they claim
>is that all features of the 94 Standard will be kept, that includes all
>the ambiguity in many words,
Ambiguous conditions are not features, and there is no particular
desire that they be kept. They are white areas where the standard has
not yet progressed. What is ambiguous in the current standard might
be defined in the next one. If ambiguous conditions are kept in the
next standard, either no common practice has emerged in that area, or
nobody has made a proposal to standardize the common practice.
> that is not what a standard is supposed to be..
And that is?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 11:29 -0700 |
| Message-ID | <ee83202b-cebb-46e2-b7dc-1151ca234817@googlegroups.com> |
| In reply to | #50327 |
On Sunday, August 21, 2016 at 3:21:48 AM UTC-7, Anton Ertl wrote: > Cecil Bayona <cbayona@cbayona.com> writes: > >All the warts in the 94 Standard will continue to be there as they claim > >is that all features of the 94 Standard will be kept, that includes all > >the ambiguity in many words, > > Ambiguous conditions are not features, and there is no particular > desire that they be kept. They are white areas where the standard has > not yet progressed. What is ambiguous in the current standard might > be defined in the next one. If ambiguous conditions are kept in the > next standard, either no common practice has emerged in that area, or > nobody has made a proposal to standardize the common practice. That is not true! If ANS-Forth allows two contradictory systems to both be considered standard-compliant, then you are going to have programs for one system that don't work on the other system, and vice-versa --- if your new standard is not ambiguous anymore, then one group or the other will get the rug pulled out from under them --- Elizabeth Rather only cares about loyalty, so she will never allow anybody to get the rug pulled out from under them, so long as they are loyal and agree to continue to say that she is the "leading expert" --- the result is that your new standard will have to be ambiguous too, just like ANS-Forth. ANS-Forth is ambiguous --- Forth-200x is mandated to be 100% compatible with ANS-Forth --- therefore Forth-200x will be ambiguous. ANS-Forth is like a kindergarten class taught by an ultra-liberal who says: "Everybody is a winner!" --- nobody can flunk out of this kindergarten class because that would be a contradiction to the "everybody is a winner" doctrine --- nobody ever graduates to first-grade either though; they remain in kindergarten for their entire lives (declaring themselves to be winners every day, stroking their beards to indicate their wisdom). > > that is not what a standard is supposed to be.. > > And that is? A Forth standard should allow standard-compliant programs to be ported between standard-compliant Forth systems --- this is what ANS-Forth doesn't allow. The whole point of Straight Forth is that anybody can implement a Forth system that conforms to Straight Forth so long as they follow the rules which are documented, and anybody can write a program in Straight Forth and expect it to run on any Straight Forth system --- to various degrees, all ANS-Forth programs will get the rug pulled out from under them --- porting ANS-Forth programs to Straight Forth will require some effort, and doing so will be different for VFX, SwiftForth and gForth users because VFX, SwiftForth and gForth are not compatible with each other. Not everybody will graduate from kindergarten.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-21 11:56 -0700 |
| Message-ID | <c8efe5c1-7512-409e-bd1e-8de4db28b739@googlegroups.com> |
| In reply to | #50336 |
On Sunday, August 21, 2016 at 1:29:59 PM UTC-5, hughag...@gmail.com wrote: > That is not true! > > If ANS-Forth allows two contradictory systems to both be considered standard-compliant, then you are going to have programs for one system that don't work on the other system, and vice-versa. A language named 'CRYPT' has a standard that defines 100 functions. Alice's implementation of CRYPT defines all 100 functions -- and also a 101st function named secure(). Bob's implementation of CRYPT defines all 100 functions -- and also a 101st function named secure(), which is incompatible in some cases. Those incompatibilities stem from differing implementation philosophies and they make sense in context. Subsequently, Eve writes some CRYPT code that also includes the unstandardized function secure(). She adds it to her 'novice CRYPT' package and proudly announces the added functionality -- but then is disturbed to find that the new code works on Alice's implementation, but not on Bob's! Eve complains about this in comp.lang.crypt and then has three times as much to complain about when people point out that secure() is not actually a standard word and that Eve should've checked on its actual compatibility if she cared about that. After years of calling Bob a treacher and a dastard in comp.lang.crypt rants, about which the less the said the better, Eve finally calms down and proposes her ultimate solution to people like Bob messing up everything up for no reason other than bad breeding. Eve's solution: * No systems may provide any functionality in excess of that defined by the standard. secure(), if it exists, must be standardized and its behavior must be exactly the same in all respects. **** This solution was immeditely adopted by the grateful community. As a result, CRYPT implementations no longer had anything to distinguish themselves by, and none of them quite fit their precise circumstances as well as they had, and basically within a year everyone was getting paid to port CRYPT to Python3, as Guido had promised that no Python4 will require that code to be rewritten. The end.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-21 12:11 -0700 |
| Message-ID | <971e65bc-d0c7-42cb-81f6-010ca343a0ec@googlegroups.com> |
| In reply to | #50341 |
On Sunday, August 21, 2016 at 11:56:43 AM UTC-7, Julian Fondren wrote: > On Sunday, August 21, 2016 at 1:29:59 PM UTC-5, hughag...@gmail.com wrote: > > That is not true! > > > > If ANS-Forth allows two contradictory systems to both be considered standard-compliant, then you are going to have programs for one system that don't work on the other system, and vice-versa. > > A language named 'CRYPT' has a standard that defines 100 functions. > > Alice's implementation of CRYPT defines all 100 functions -- and also > a 101st function named secure(). > > Bob's implementation of CRYPT defines all 100 functions -- and also a > 101st function named secure(), which is incompatible in some cases. Is Julien Fondren a salesman for Forth Inc.? Why is he promoting ANS-Forth like this? How is this different from John Passaniti endlessly contradicting me with idiotic arguments that made no sense? Obviously, I was was referring to ambiguity within the core functions, not within extensions --- a typical example being FIND that works differently on VFX, SwiftForth and gForth. Elizabeth Rather depends entirely upon lying sycophants such as Julien Fondren to support ANS-Forth --- this is because ANS-Forth is a technical failure --- there are no technical arguments supporting ANS-Forth.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web