Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56164 > unrolled thread
| Started by | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| First post | 2017-03-23 02:17 -0500 |
| Last post | 2017-05-11 20:59 -0700 |
| Articles | 20 on this page of 184 — 31 participants |
Back to article view | Back to comp.lang.forth
comp.lang.forth is THE PROBLEM Richard Owlett <rowlett@cloud85.net> - 2017-03-23 02:17 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 00:27 -0700
Re: comp.lang.forth is THE PROBLEM anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 11:50 +0000
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-23 12:34 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 10:56 -0700
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-03-24 05:25 -0700
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-03-24 19:23 -0400
Re: comp.lang.forth is THE PROBLEM john <anon@example.com> - 2017-05-03 10:54 +0100
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-05-04 05:28 -0700
Re: comp.lang.forth is THE PROBLEM Dennis Ruffer <daruffer@gmail.com> - 2017-03-24 17:46 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-24 18:49 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-24 22:09 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-03-24 20:47 -0700
Re: comp.lang.forth is THE PROBLEM krishna.myneni@ccreweb.org - 2017-03-25 10:49 -0700
Re: comp.lang.forth is THE PROBLEM Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:39 -0700
Re: comp.lang.forth is THE PROBLEM The Beez <the.beez.speaks@gmail.com> - 2017-05-10 02:07 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 11:23 +0200
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-10 16:29 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-11 13:39 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 16:01 -0500
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 21:41 -1000
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-12 03:18 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 19:15 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:01 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-16 17:59 -0400
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-05-24 16:57 -0400
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-26 02:28 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 17:44 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:21 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:15 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:30 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 04:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 12:51 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 08:47 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 09:57 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 18:26 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 10:59 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:36 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 00:33 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 12:04 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 11:45 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-14 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:22 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 23:08 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-14 12:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:48 -0500
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:14 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:17 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:30 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:54 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-15 02:27 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:53 +0100
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:31 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 11:43 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 15:47 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 20:06 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 12:05 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-16 15:00 +0000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 10:52 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 19:33 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:11 +0200
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 21:25 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-17 07:48 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 10:50 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:27 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:42 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:22 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:57 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 13:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 13:01 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 14:09 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 07:00 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:15 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 22:21 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:04 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:10 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:19 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:29 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 08:44 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-18 01:13 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 10:02 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 01:29 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 11:34 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:56 -0700
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:44 +0000
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:42 +0000
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:59 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 13:01 +0200
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-18 08:26 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:37 +0000
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-18 08:16 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:04 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 19:41 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:05 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 11:21 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 20:32 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:35 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:06 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:30 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:41 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-17 19:17 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 20:58 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:46 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 08:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 16:00 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 01:47 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:03 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 17:51 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 07:51 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 00:11 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 17:46 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 10:34 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 20:57 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:08 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 05:15 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 14:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 21:15 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 19:49 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-19 07:10 +0200
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-19 07:42 -0500
Re: comp.lang.forth is THE PROBLEM Coos Haak <htrofhc@gmail.com> - 2017-05-19 09:59 +0200
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:48 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 12:40 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 20:57 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-20 03:42 -0500
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-20 02:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 10:15 +0100
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:34 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 02:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:18 +0100
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-19 17:06 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 08:31 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 17:02 +0100
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:34 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-18 16:40 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-18 08:12 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-19 02:30 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:57 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-20 14:01 -0700
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-21 19:55 +0200
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 11:57 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-21 12:41 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 13:02 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 14:43 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 16:32 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 18:46 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-22 07:05 +0100
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-23 13:45 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-23 22:02 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-24 01:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-24 14:07 +0100
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:14 -0700
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-16 18:48 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 15:06 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:16 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:18 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:58 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-12 03:32 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:29 -0500
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-13 08:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-13 13:25 -0500
Re: comp.lang.forth is THE PROBLEM "Robert L." <No_spamming@noWhere_7073.org> - 2017-05-15 05:45 +0000
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 06:54 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:30 +0200
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 00:32 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:25 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 21:15 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-16 21:34 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-15 08:39 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:38 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 17:32 -0500
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-16 10:06 +0200
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:51 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:50 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:47 -0700
Re: comp.lang.forth is THE PROBLEM Bill Zimmerly <billzimmerly@gmail.com> - 2017-05-11 20:59 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-19 09:18 -0700 |
| Message-ID | <f0a80ec0-4401-467c-848e-78e292f416e5@googlegroups.com> |
| In reply to | #59556 |
vineri, 19 mai 2017, 19:02:37 UTC+3, Alex a scris: > On 5/19/2017 16:31, Raimond Dragomir wrote: > > vineri, 19 mai 2017, 18:06:14 UTC+3, Albert van der Horst a scris: > >> In article <ad035ad4-09be-4f30-876a-f210064ee2da@googlegroups.com>, > >> Joel Rees <joel.rees@gmail.com> wrote: > >> <SNIP> > >>> And aggressively optimizing Forth compiler (with a properly designed > >>> run-time) may "flatten" each symbol in that definition into in-line > >>> instantiation of the code that characterizes the symbol. > >> > >> That is not aggressive optimising in my book. It is a low hanging fruit, > >> with sufficient carnal knowledge doable in one screen. > >> > >>> -- > >>> Joel Rees > >> -- > >> 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 > > > > In my view "MACRO" is about textual replacement facility BEFORE any compiling. > > Something like C #define's or TCL philosophy. There's no such thing > > in forth, unless you really want to play with EVALUATE & co. > > > > You might find this interesting. It's from a Lisp-y approach. > > http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01539.html > > <quote> > > I'd like to propose that there are three disciplined uses of macros: > > 1. data sublanguages: I can write simple looking expressions and > create complex nested lists/arrays/tables with quote, unquote etc > neatly dressed up with macros. > > 2. binding constructs: I can introduce new binding constructs with > macros. That helps me get rid of lambda's and with placing things > closer together that belong together. For example, one of our teachpacks > contains a form > (web-query ([last-name > (string-append "Hello " first-name " what's your last > name?"]) > ... last-name ... first-name ...) > with the obvious interaction between a program and a Web consumer implied. > [Note: In ML you could write > web-query(fn last-name => ...)string_append(...) > but by golly that's a pain and an unnecessary pattern.] > > 3. evaluation reordering: I can introduce constructs that delay/postpone > the evaluation of expressions as needed. Think of loops, new conditionals, > delay/force, etc. > [Note: In Haskell, you don't need that one.] > > I understand that Lispers use macros for other reasons. In all honesty, I > believe that this is partly due to compiler deficiencies, and partly due to > "semantic" irregularities in the target language. > > I challenge people to address all three issues when they say language X > can do what macros can do. > </quote> > > Now relate that to Forth. > > -- > Alex You lost me. I would raise a simple example. The eForth FOR NEXT constructs are very simple. FOR is just a >R BEGIN "macro". If you really want to write >R BEGIN by hand instead of FOR, it will work as expected. But I wonder which forth compiler will replace the "FOR" word in the original source with a ">R BEGIN" in an intermediate string and then compiling the ">R BEGIN" such it was the source string given. (the forth EVALUATE if I'm not wrong).
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-19 09:34 -0700 |
| Message-ID | <dd3cc7e2-7103-40b6-987c-caab51a67ccd@googlegroups.com> |
| In reply to | #59557 |
Oh, I just remebered that Ch.Moore named the immediate words in his colorforth as "macros". But I still stand that is not the correct wording. The forth "immediacy" is a bit different.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Klimas <klimas@w3group.de> |
|---|---|
| Date | 2017-05-18 16:40 +0200 |
| Message-ID | <ofkbja$nna$1@dont-email.me> |
| In reply to | #59445 |
On 2017-05-17 19:02:22 +0000, hughaguilar96@gmail.com said: > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that > the "leading expert" Elizabeth Rather and her appointed committee know > everything there is to know about Forth --- and that any critic (me) is > utterly incompetent, and doesn't even know what a pointer is. This is > very comparable to religious cults that claim to have a monopoly on > knowledge of spirituality --- and that any critic is utterly ignorant, > and no better than an animal. I don't know what is going here, I'm almost new to Forth. My statement is as follows: I don't want any vendor lock. I'm not a Forth Tool developer. I'm an application developer using ANSI-Forth compatible Forth system. Not to be bound to any implementation is essential for me. I didn't select Forth if there were no Ansi standard. Anyway. I was very interested in Scheme (a very small Lisp dialect). Scheme also defines a standard, but unfortunately they did a compatibility break from R5RS to R6RS and from R6RS to R7RS. This was the reason why I have to abandoned Scheme. I hope, and I think so, that I can trust in Ansi Forth. Best Wishes Andreas Klimas
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-18 08:12 -0700 |
| Message-ID | <02bc3ac2-dd6c-404d-9b59-8983c2ce1196@googlegroups.com> |
| In reply to | #59499 |
On Thursday, May 18, 2017 at 7:40:54 AM UTC-7, Andreas Klimas wrote: > On 2017-05-17 19:02:22 +0000, hughaguilar96@gmail.com said: > > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that > > the "leading expert" Elizabeth Rather and her appointed committee know > > everything there is to know about Forth --- and that any critic (me) is > > utterly incompetent, and doesn't even know what a pointer is. This is > > very comparable to religious cults that claim to have a monopoly on > > knowledge of spirituality --- and that any critic is utterly ignorant, > > and no better than an animal. > > I don't know what is going here, I'm almost new to Forth. > My statement is as follows: > > I don't want any vendor lock. I'm not a Forth Tool developer. > I'm an application developer using ANSI-Forth compatible Forth > system. Not to be bound to any implementation is essential > for me. I didn't select Forth if there were no Ansi standard. > > Anyway. I was very interested in Scheme (a very small Lisp > dialect). Scheme also defines a standard, but unfortunately > they did a compatibility break from R5RS to R6RS and from > R6RS to R7RS. This was the reason why I have to abandoned > Scheme. > > I hope, and I think so, that I can trust in Ansi Forth. As an experiment, ask Stephen Pelc how SYNONYM is implemented.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-19 02:30 -0700 |
| Message-ID | <e1a6946c-80ab-44e1-9fc2-648290a18496@googlegroups.com> |
| In reply to | #59499 |
четверг, 18 мая 2017 г., 17:40:54 UTC+3 пользователь Andreas Klimas написал: > On 2017-05-17 19:02:22 +0000, hughaguilar96@gmail.com said: > > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that > > the "leading expert" Elizabeth Rather and her appointed committee know > > everything there is to know about Forth --- and that any critic (me) is > > utterly incompetent, and doesn't even know what a pointer is. This is > > very comparable to religious cults that claim to have a monopoly on > > knowledge of spirituality --- and that any critic is utterly ignorant, > > and no better than an animal. > > I don't know what is going here, I'm almost new to Forth. > My statement is as follows: > > I don't want any vendor lock. I'm not a Forth Tool developer. > I'm an application developer using ANSI-Forth compatible Forth > system. Not to be bound to any implementation is essential > for me. I didn't select Forth if there were no Ansi standard. > > Anyway. I was very interested in Scheme (a very small Lisp > dialect). Scheme also defines a standard, but unfortunately > they did a compatibility break from R5RS to R6RS and from > R6RS to R7RS. This was the reason why I have to abandoned > Scheme. > > I hope, and I think so, that I can trust in Ansi Forth. If you are choosing between ANS-Forth and other Forth vendor, ANS may be a better choise. The question here is based on the position of forthers who can develop their own Forth, based on their customer's demands. In this case optimized and targeted Forth will be better than ANS. For now, outside Forth community is hard to find a customer who will agree by 100% Forth is smart. Only after this you can point to the fact you are use ANS-compatible version of cush smart thing. But first problem to solve usually is to ensure customer you are using a tool smart enough for his problem. One of first change for me was to replace S" and 1.23E0 as data formats. It was looking absolutely weak when a language, describing as smart and flexible, was not able to use " as a string designator and 1.23 (without E) for floating-point numbers. The position of ANS comittee is "write a proposal and we will see is it usefule or not". But I don't need their permission to change Forth significantly, since I can write my own. My point is Forth overall strategy should be reviewed to be more interesting for professional programmers, who don't need a complete guide describing non-critical words. With hundreds of standartized words Forth really looks like a cult.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-19 18:57 -0700 |
| Message-ID | <45b30d99-a451-4af5-ac2b-1e8274413c49@googlegroups.com> |
| In reply to | #59539 |
On Friday, May 19, 2017 at 6:30:14 PM UTC+9, Ilya Tarasov wrote: > четверг, 18 мая 2017 г., 17:40:54 UTC+3 пользователь Andreas Klimas написал: > > On 2017-05-17 19:02:22 +0000, hughaguilar96@somewhere said: > > > > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that > > > the "leading expert" Elizabeth Rather and her appointed committee know > > > everything there is to know about Forth --- and that any critic (me) is > > > utterly incompetent, and doesn't even know what a pointer is. This is > > > very comparable to religious cults that claim to have a monopoly on > > > knowledge of spirituality --- and that any critic is utterly ignorant, > > > and no better than an animal. > > > > I don't know what is going here, I'm almost new to Forth. > > My statement is as follows: > > > > I don't want any vendor lock. I'm not a Forth Tool developer. > > I'm an application developer using ANSI-Forth compatible Forth > > system. Not to be bound to any implementation is essential > > for me. I didn't select Forth if there were no Ansi standard. > > > > Anyway. I was very interested in Scheme (a very small Lisp > > dialect). Scheme also defines a standard, but unfortunately > > they did a compatibility break from R5RS to R6RS and from > > R6RS to R7RS. This was the reason why I have to abandoned > > Scheme. > > > > I hope, and I think so, that I can trust in Ansi Forth. > > If you are choosing between ANS-Forth and other Forth vendor, ANS may be a better choise. The question here is based on the position of forthers who can develop their own Forth, based on their customer's demands. In this case optimized and targeted Forth will be better than ANS. > > For now, outside Forth community is hard to find a customer who will agree by 100% Forth is smart. Only after this you can point to the fact you are use ANS-compatible version of cush smart thing. But first problem to solve usually is to ensure customer you are using a tool smart enough for his problem. One of first change for me was to replace S" and 1.23E0 as data formats. It was looking absolutely weak when a language, describing as smart and flexible, was not able to use " as a string designator and 1.23 (without E) for floating-point numbers. The position of ANS comittee is "write a proposal and we will see is it usefule or not". But I don't need their permission to change Forth significantly, since I can write my own. > Can we all get a little more of this attitude? Let's offer what we have to offer, share what we have to share, and not be so critical of what others are doing. > My point is Forth overall strategy should be reviewed to be more interesting for professional programmers, who don't need a complete guide describing non-critical words. With hundreds of standartized words Forth really looks like a cult. > -- Joel Rees Delusions of being a novelist: http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-20 14:01 -0700 |
| Message-ID | <127e5c7c-4897-420e-a935-5bf606b17cef@googlegroups.com> |
| In reply to | #59572 |
суббота, 20 мая 2017 г., 4:57:23 UTC+3 пользователь Joel Rees написал: > On Friday, May 19, 2017 at 6:30:14 PM UTC+9, Ilya Tarasov wrote: > > четверг, 18 мая 2017 г., 17:40:54 UTC+3 пользователь Andreas Klimas написал: > > > On 2017-05-17 19:02:22 +0000, hughaguilar96@somewhere said: > > > > > > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that > > > > the "leading expert" Elizabeth Rather and her appointed committee know > > > > everything there is to know about Forth --- and that any critic (me) is > > > > utterly incompetent, and doesn't even know what a pointer is. This is > > > > very comparable to religious cults that claim to have a monopoly on > > > > knowledge of spirituality --- and that any critic is utterly ignorant, > > > > and no better than an animal. > > > > > > I don't know what is going here, I'm almost new to Forth. > > > My statement is as follows: > > > > > > I don't want any vendor lock. I'm not a Forth Tool developer. > > > I'm an application developer using ANSI-Forth compatible Forth > > > system. Not to be bound to any implementation is essential > > > for me. I didn't select Forth if there were no Ansi standard. > > > > > > Anyway. I was very interested in Scheme (a very small Lisp > > > dialect). Scheme also defines a standard, but unfortunately > > > they did a compatibility break from R5RS to R6RS and from > > > R6RS to R7RS. This was the reason why I have to abandoned > > > Scheme. > > > > > > I hope, and I think so, that I can trust in Ansi Forth. > > > > If you are choosing between ANS-Forth and other Forth vendor, ANS may be a better choise. The question here is based on the position of forthers who can develop their own Forth, based on their customer's demands. In this case optimized and targeted Forth will be better than ANS. > > > > For now, outside Forth community is hard to find a customer who will agree by 100% Forth is smart. Only after this you can point to the fact you are use ANS-compatible version of cush smart thing. But first problem to solve usually is to ensure customer you are using a tool smart enough for his problem. One of first change for me was to replace S" and 1.23E0 as data formats. It was looking absolutely weak when a language, describing as smart and flexible, was not able to use " as a string designator and 1.23 (without E) for floating-point numbers. The position of ANS comittee is "write a proposal and we will see is it usefule or not". But I don't need their permission to change Forth significantly, since I can write my own. > > > > Can we all get a little more of this attitude? > > Let's offer what we have to offer, share what we have to share, and > not be so critical of what others are doing. I already post it here several times. Each time a flame was started :) I can repeat my observations, based on the positive experience from Forth. 1. Data formats Strings are started from quote. " abcde" is a string. Floating-point numbers must contain a point: 1.23 is a floating-point number. 2. Vocabularies are statically linked, i.e. no ONLY ALSO 3. More vectorized words like EMIT LITERAL etc. 4. File IO and other word sets are derived from customer requirements, so no THROW after opening file. These point appears to be common from my projects done with Forth.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-21 19:55 +0200 |
| Message-ID | <ofsk9s$nk$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59610 |
In article <127e5c7c-4897-420e-a935-5bf606b17cef@googlegroups.com>, Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 20 =D0=BC=D0=B0=D1=8F 2017 =D0= >=B3., 4:57:23 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82= >=D0=B5=D0=BB=D1=8C Joel Rees =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> On Friday, May 19, 2017 at 6:30:14 PM UTC+9, Ilya Tarasov wrote: >> > =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 18 =D0=BC=D0=B0=D1=8F 2017 = >=D0=B3., 17:40:54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1= >=82=D0=B5=D0=BB=D1=8C Andreas Klimas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= >=D0=BB: >> > > On 2017-05-17 19:02:22 +0000, hughaguilar96@somewhere said: >> > > >=20 >> > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea th= >at=20 >> > > > the "leading expert" Elizabeth Rather and her appointed committee k= >now=20 >> > > > everything there is to know about Forth --- and that any critic (me= >) is=20 >> > > > utterly incompetent, and doesn't even know what a pointer is. This = >is=20 >> > > > very comparable to religious cults that claim to have a monopoly on= >=20 >> > > > knowledge of spirituality --- and that any critic is utterly ignora= >nt,=20 >> > > > and no better than an animal. >> > >=20 >> > > I don't know what is going here, I'm almost new to Forth. >> > > My statement is as follows: >> > >=20 >> > > I don't want any vendor lock. I'm not a Forth Tool developer. >> > > I'm an application developer using ANSI-Forth compatible Forth >> > > system. Not to be bound to any implementation is essential >> > > for me. I didn't select Forth if there were no Ansi standard. >> > >=20 >> > > Anyway. I was very interested in Scheme (a very small Lisp >> > > dialect). Scheme also defines a standard, but unfortunately >> > > they did a compatibility break from R5RS to R6RS and from >> > > R6RS to R7RS. This was the reason why I have to abandoned >> > > Scheme. >> > >=20 >> > > I hope, and I think so, that I can trust in Ansi Forth. >> >=20 >> > If you are choosing between ANS-Forth and other Forth vendor, ANS may b= >e a better choise. The question here is based on the position of forthers w= >ho can develop their own Forth, based on their customer's demands. In this = >case optimized and targeted Forth will be better than ANS. >> >=20 >> > For now, outside Forth community is hard to find a customer who will ag= >ree by 100% Forth is smart. Only after this you can point to the fact you a= >re use ANS-compatible version of cush smart thing. But first problem to sol= >ve usually is to ensure customer you are using a tool smart enough for his = >problem. One of first change for me was to replace S" and 1.23E0 as data fo= >rmats. It was looking absolutely weak when a language, describing as smart = >and flexible, was not able to use " as a string designator and 1.23 (withou= >t E) for floating-point numbers. The position of ANS comittee is "write a p= >roposal and we will see is it usefule or not". But I don't need their permi= >ssion to change Forth significantly, since I can write my own. >> > >>=20 >> Can we all get a little more of this attitude? >>=20 >> Let's offer what we have to offer, share what we have to share, and=20 >> not be so critical of what others are doing. > >I already post it here several times. Each time a flame was started :) I ca= >n repeat my observations, based on the positive experience from Forth. > >1. Data formats >Strings are started from quote. " abcde" is a string. If you change strings, change it good. "abcde" is a string and " abvcse" is a string that starts with a space. >Floating-point numbers must contain a point: 1.23 is a floating-point numbe= >r. Wrong starting point. The problem is doubles, not fp numbers. De emphasize doubles, and require that a double contains *two* dots, at the start and the end. .1234. will never be taken for an fp. >2. Vocabularies are statically linked, i.e. no ONLY ALSO Huh? >3. More vectorized words like EMIT LITERAL etc. Vectorizing LITERAL has a lot of implied assumptions. Recoognizers make them unnecessary and are probably the better chocie. Following Unix (50 years of experience) I choose TYPE as the basic I/O word in ciforth not EMIT. Requiring EMIT to be revectored, and the implied assumption that all I/O goes through EMIT would be a fatal flaw in a standard. >4. File IO and other word sets are derived from customer requirements, so n= >o THROW after opening file. Since when is the *option* to throw after a file io a bad thing? > >These point appears to be common from my projects done with Forth. 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 | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-21 11:57 -0700 |
| Message-ID | <1ec29a6e-2134-44cb-8bde-039a5cbc6662@googlegroups.com> |
| In reply to | #59675 |
воскресенье, 21 мая 2017 г., 20:54:43 UTC+3 пользователь Albert van der Horst написал: > In article <127e5c7c-4897-420e-a935-5bf606b17cef@googlegroups.com>, > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > >=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 20 =D0=BC=D0=B0=D1=8F 2017 =D0= > >=B3., 4:57:23 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82= > >=D0=B5=D0=BB=D1=8C Joel Rees =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > >> On Friday, May 19, 2017 at 6:30:14 PM UTC+9, Ilya Tarasov wrote: > >> > =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 18 =D0=BC=D0=B0=D1=8F 2017 = > >=D0=B3., 17:40:54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1= > >=82=D0=B5=D0=BB=D1=8C Andreas Klimas =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= > >=D0=BB: > >> > > On 2017-05-17 19:02:22 +0000, hughaguilar96@somewhere said: > >> > > >=20 > >> > > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea th= > >at=20 > >> > > > the "leading expert" Elizabeth Rather and her appointed committee k= > >now=20 > >> > > > everything there is to know about Forth --- and that any critic (me= > >) is=20 > >> > > > utterly incompetent, and doesn't even know what a pointer is. This = > >is=20 > >> > > > very comparable to religious cults that claim to have a monopoly on= > >=20 > >> > > > knowledge of spirituality --- and that any critic is utterly ignora= > >nt,=20 > >> > > > and no better than an animal. > >> > >=20 > >> > > I don't know what is going here, I'm almost new to Forth. > >> > > My statement is as follows: > >> > >=20 > >> > > I don't want any vendor lock. I'm not a Forth Tool developer. > >> > > I'm an application developer using ANSI-Forth compatible Forth > >> > > system. Not to be bound to any implementation is essential > >> > > for me. I didn't select Forth if there were no Ansi standard. > >> > >=20 > >> > > Anyway. I was very interested in Scheme (a very small Lisp > >> > > dialect). Scheme also defines a standard, but unfortunately > >> > > they did a compatibility break from R5RS to R6RS and from > >> > > R6RS to R7RS. This was the reason why I have to abandoned > >> > > Scheme. > >> > >=20 > >> > > I hope, and I think so, that I can trust in Ansi Forth. > >> >=20 > >> > If you are choosing between ANS-Forth and other Forth vendor, ANS may b= > >e a better choise. The question here is based on the position of forthers w= > >ho can develop their own Forth, based on their customer's demands. In this = > >case optimized and targeted Forth will be better than ANS. > >> >=20 > >> > For now, outside Forth community is hard to find a customer who will ag= > >ree by 100% Forth is smart. Only after this you can point to the fact you a= > >re use ANS-compatible version of cush smart thing. But first problem to sol= > >ve usually is to ensure customer you are using a tool smart enough for his = > >problem. One of first change for me was to replace S" and 1.23E0 as data fo= > >rmats. It was looking absolutely weak when a language, describing as smart = > >and flexible, was not able to use " as a string designator and 1.23 (withou= > >t E) for floating-point numbers. The position of ANS comittee is "write a p= > >roposal and we will see is it usefule or not". But I don't need their permi= > >ssion to change Forth significantly, since I can write my own. > >> > > >>=20 > >> Can we all get a little more of this attitude? > >>=20 > >> Let's offer what we have to offer, share what we have to share, and=20 > >> not be so critical of what others are doing. > > > >I already post it here several times. Each time a flame was started :) I ca= > >n repeat my observations, based on the positive experience from Forth. > > > >1. Data formats > >Strings are started from quote. " abcde" is a string. > > If you change strings, change it good. "abcde" is a string and > " abvcse" is a string that starts with a space. Ok, you change string according to your demands if you wish. I change strings already, with a flag, so "abcde" may be a string too after executing SMART-STRINGS ON. This allows to check all unknown words for strings. The bad thing some words may start with quote and will be recognized as words before interpreting as strings. I'm going to stop using such words, but for now special flag is controlling strings interpretation. > >Floating-point numbers must contain a point: 1.23 is a floating-point numbe= > >r. > > Wrong starting point. The problem is doubles, not fp numbers. Heh. Correct starting point. My word against your. > De emphasize doubles, and require that a double contains *two* dots, > at the start and the end. > .1234. will never be taken for an fp. I don't want to introduce THIS to mathematics. I feel a little trouble to count languages where 1.23 is a floating-point number. Many people wants to use FPU and ready to use a language tightly integrated with FPU command set. With a Forth based on the hardware FPU stack, many programs with heavy calculations are pretty fast and I see no reasons to waste this feature by archaic traditions of Forth. > >2. Vocabularies are statically linked, i.e. no ONLY ALSO > > Huh? > >3. More vectorized words like EMIT LITERAL etc. > > Vectorizing LITERAL has a lot of implied assumptions. > Recoognizers make them unnecessary and are probably the better chocie. Show me that assumptions first. When explain why recognizers are not a kind of skill demonstration for programmers claiming them advanced. > Following Unix (50 years of experience) I choose TYPE as the basic I/O > word in ciforth not EMIT. Requiring EMIT to be revectored, and the > implied assumption that all I/O goes through EMIT would be a fatal > flaw in a standard. Embedded bare metal system has no software at all. So TYPE must be implemented first... as a sequence of EMIT. An old flame, common for all who use *nix or even terminal mode. For them, EMIT is a kind of TYPE with string length equal to 1. They prefer to not to think how TYPE is organized inside. > >4. File IO and other word sets are derived from customer requirements, so n= > >o THROW after opening file. > > Since when is the *option* to throw after a file io a bad thing? Since POSIX functions return one value. There are many IO libraries using this approach and it is easy to tell "Forth can be easily adopted, so you can use the style from your favourite language". Having a tons of traditions really looks like a cult.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-05-21 12:41 -0700 |
| Message-ID | <321427b6-d865-421f-a2f3-db90e3603a46@googlegroups.com> |
| In reply to | #59688 |
On Sunday, May 21, 2017 at 1:57:45 PM UTC-5, Ilya Tarasov wrote:
> Embedded bare metal system has no software at all. So TYPE must be implemented first... as a sequence of EMIT. An old flame, common for all who use *nix or even terminal mode. For them, EMIT is a kind of TYPE with string length equal to 1. They prefer to not to think how TYPE is organized inside.
>
No, they *know* how TYPE is implemented on such systems. It and EMIT
are both implemented with a syscall. Syscalls are slow, and
implementing TYPE as a loop that performs N syscalls for an N-length
string would be absurdly slow. As demonstrated:
4096 buffer: long-string
: typing ( -- ) long-string 4096 2 write-file drop ;
: emitting ( -- )
long-string 4096 bounds do i 1 2 write-file drop loop ;
: bench ( n -- )
cr ." typing: " timer-reset dup 0 do typing loop .elapsed
cr ." emitting: " timer-reset 0 do emitting loop .elapsed ;
With 50k runs on my machine:
typing: 0.004 seconds elapsed.
emitting: 16.183 seconds elapsed.
User-mode software is having to ask a kernel to do some work for it.
The kernel is slow to respond to individual requests but is very fast
once it executes them. Thus, TYPE and measures like buffered I/O to
batch up requests so the kernel does more work at once, and is asked
less often to do it.
Going without an OS frees you from waiting on the kernel, but the
kernel isn't like this for no reason. You may feel the same
performance pressure for some of those reasons, like wanting to finish
contiguous writes to storage rather than e.g. let two tasks switch
between writing single bytes to two different locations on the same
storage device.
> > >4. File IO and other word sets are derived from customer requirements, so n=
> > >o THROW after opening file.
> >
> > Since when is the *option* to throw after a file io a bad thing?
>
> Since POSIX functions return one value. There are many IO libraries using this approach and it is easy to tell "Forth can be easily adopted, so you can use the style from your favourite language". Having a tons of traditions really looks like a cult.
As with double numbers, it's a case of "other languages suck too much
to have a feature Forth has, therefore Forth is bad for being different."
OK.
So instead of
read-file ( u ior )
throw ( u )
You want
read-file ( n ) \ negative on error
handle-io-errors ( u )
?
It's still WRITE-FILE SOME-WORD in both cases.
In the case that you want to ignore errors you go from
read-file drop ( u )
to
read-file dup 0>= and
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-21 13:02 -0700 |
| Message-ID | <559c1583-fa0c-42cc-962f-46695aaffde9@googlegroups.com> |
| In reply to | #59693 |
воскресенье, 21 мая 2017 г., 22:41:26 UTC+3 пользователь Julian Fondren написал: > On Sunday, May 21, 2017 at 1:57:45 PM UTC-5, Ilya Tarasov wrote: > > Embedded bare metal system has no software at all. So TYPE must be implemented first... as a sequence of EMIT. An old flame, common for all who use *nix or even terminal mode. For them, EMIT is a kind of TYPE with string length equal to 1. They prefer to not to think how TYPE is organized inside. > > > > No, they *know* how TYPE is implemented on such systems. It and EMIT > are both implemented with a syscall. Syscalls are slow, and > implementing TYPE as a loop that performs N syscalls for an N-length > string would be absurdly slow. As demonstrated: Do you understand what I'm talking about? What syscalls will you have without a single byte of code? What kind of kernel do you expect for a system with 16-32 kb of memory? > > > >4. File IO and other word sets are derived from customer requirements, so n= > > > >o THROW after opening file. > > > > > > Since when is the *option* to throw after a file io a bad thing? > > > > Since POSIX functions return one value. There are many IO libraries using this approach and it is easy to tell "Forth can be easily adopted, so you can use the style from your favourite language". Having a tons of traditions really looks like a cult. > > As with double numbers, it's a case of "other languages suck too much > to have a feature Forth has, therefore Forth is bad for being different." In this case you are going to explain everyone they are fools. Ok, you can start a holy war each time you meet a customer and being a geek. I'm not. > OK. > > So instead of > > read-file ( u ior ) > throw ( u ) > > You want > > read-file ( n ) \ negative on error > handle-io-errors ( u ) > > ? Exactly, with only note - I don't need any handle-io-errors, because I can just write read-file result to variable and use it. In the case of error I will receive nothing. The difference I can add checking for IO error at any time I need and I don't need to insert it ANY TIME I use IO function. You can discuss this behavior with Windows or Linux team, it is their solution, not mine. I just follow known trends. > It's still WRITE-FILE SOME-WORD in both cases. > > In the case that you want to ignore errors you go from > > read-file drop ( u ) > > to > > read-file dup 0>= and I'm going to read-file ( -- hfile )
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-21 14:43 -0700 |
| Message-ID | <1c3ec4d5-3e82-4fc8-9e32-00b52135c034@googlegroups.com> |
| In reply to | #59675 |
On Sunday, May 21, 2017 at 10:54:43 AM UTC-7, Albert van der Horst wrote: > Wrong starting point. The problem is doubles, not fp numbers. > De emphasize doubles, and require that a double contains *two* dots, > at the start and the end. > .1234. will never be taken for an fp. I've already written STR>NUM that converts strings to numbers (this will be used in the outer-interpreter of Straight Forth). Floats are like in other languages. A 'e' 'E' or '.' indicate that it is a float --- it is not necessary to use scientific notation if it is not appropriate --- an 'e' or 'E' without an exponent number assume an exponent of 0, just like in ANS-Forth. Singles, doubles and floats all allow the ',' to be used anywhere in the number, which can improve readability. A ',' at the beginning of a number indicates that it is a double. > >3. More vectorized words like EMIT LITERAL etc. > > Vectorizing LITERAL has a lot of implied assumptions. > Recoognizers make them unnecessary and are probably the better chocie. Recognizers are a can of worms --- there is no way that I would have recognizers in Straight Forth (recognizers and the Paysan-faked quotations are the two primary reasons why I have abandoned Forth-200x as a lost cause) --- vectorizing LITERAL 2LITERAL and FLITERAL is super-simple and does everything necessary for supporting literal numbers in TARG mode colon definitions.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-21 16:32 -0700 |
| Message-ID | <72d395f5-20a4-497a-a880-b1d0208db124@googlegroups.com> |
| In reply to | #59698 |
понедельник, 22 мая 2017 г., 0:43:36 UTC+3 пользователь hughag...@gmail.com написал: > On Sunday, May 21, 2017 at 10:54:43 AM UTC-7, Albert van der Horst wrote: > > Wrong starting point. The problem is doubles, not fp numbers. > > De emphasize doubles, and require that a double contains *two* dots, > > at the start and the end. > > .1234. will never be taken for an fp. > > I've already written STR>NUM that converts strings to numbers (this will be used in the outer-interpreter of Straight Forth). > > Floats are like in other languages. A 'e' 'E' or '.' indicate that it is a float --- it is not necessary to use scientific notation if it is not appropriate --- an 'e' or 'E' without an exponent number assume an exponent of 0, just like in ANS-Forth. > > Singles, doubles and floats all allow the ',' to be used anywhere in the number, which can improve readability. > > A ',' at the beginning of a number indicates that it is a double. > > > >3. More vectorized words like EMIT LITERAL etc. > > > > Vectorizing LITERAL has a lot of implied assumptions. > > Recoognizers make them unnecessary and are probably the better chocie. > > Recognizers are a can of worms --- there is no way that I would have recognizers in Straight Forth (recognizers and the Paysan-faked quotations are the two primary reasons why I have abandoned Forth-200x as a lost cause) --- vectorizing LITERAL 2LITERAL and FLITERAL is super-simple and does everything necessary for supporting literal numbers in TARG mode colon definitions. I wonder why such simple things may cause so much flame. Indeed I know an answer, and this answer not laying in the plane of programming. The solution may be simple also - just explain how to write cross-compiler with very easy modifications and self-claimed experts may sit alone and dream about followers.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-21 18:46 -0700 |
| Message-ID | <dcd56854-3f84-471b-9eb2-bf92db8b7536@googlegroups.com> |
| In reply to | #59703 |
On Sunday, May 21, 2017 at 4:32:11 PM UTC-7, Ilya Tarasov wrote:
> понедельник, 22 мая 2017 г., 0:43:36 UTC+3 пользователь hughag...@gmail.com написал:
> > > >3. More vectorized words like EMIT LITERAL etc.
> > >
> > > Vectorizing LITERAL has a lot of implied assumptions.
> > > Recoognizers make them unnecessary and are probably the better chocie.
> >
> > Recognizers are a can of worms --- there is no way that I would have recognizers in Straight Forth (recognizers and the Paysan-faked quotations are the two primary reasons why I have abandoned Forth-200x as a lost cause) --- vectorizing LITERAL 2LITERAL and FLITERAL is super-simple and does everything necessary for supporting literal numbers in TARG mode colon definitions.
>
> I wonder why such simple things may cause so much flame. Indeed I know an answer, and this answer not laying in the plane of programming. The solution may be simple also - just explain how to write cross-compiler with very easy modifications and self-claimed experts may sit alone and dream about followers.
A standard would work a lot better if a compiler were written first, and people used the compiler and suggested upgrades, and then after several years everybody said: "This compiler works quite well! Lets call this the standard!"
What happened with ANS-Forth is that Forth Inc. wrote the standard, despite the fact that PolyForth was one of the worst Forth compilers on the market at the time, and Elizabeth Rather said: "In a few years we will hire somebody to write an ANS-Forth compiler for us, because none of us are capable of doing this, but first we want to declare ourselves to be the standard so we can denounce everybody else as being non-standard."
As for your idea, "explain how to write cross-compiler with very easy modifications," I could do that at any time. I've already pretty much done this in various posts on comp.lang.forth. I have the Traditional Forth that is pretty much just Forth-83 with a few enhancements that allow it to support cross-compilers. I also have Straight Forth that is more ambitious, with controversial aspects such as numbers being either 64-bit fixed-point with a 2^32 unity, or being IEEE-754 double-precision floats.
Explaining Traditional Forth is easy, but unproductive. The only result is a lot of ANS-Forth cult members saying: "You are non-standard! You are not a Forth programmer at all!" And, of course, there is the incredibly tedious Alex McDonald: "You have a serious misunderstanding of how pointers work." Plus, Rickman will try to make me do a little dance for him by taunting me with accusations of insanity. Stephen Pelc will say that cross-compilers are more subtle and more complicated than they appear, and everything on the target processor has to be simulated, except that "simulate" means something other than what it usually means. Elizabeth Rather will say that the "unreasonable awesomeness" of ANS-Forth is sacrosanct because it was written on stone tablets by God and brought down from Mt. Sinai by Charles Moore in 1974, and that ANS-Forth's similarity to COBOL was not caused by the fact that Elizabeth Rather's only prior programming experience was in COBOL. Julien Fondren will say that I'm the Devil, and Juergen Pintaske will say that I'm a "Forth killer."
I'll explain Traditional Forth anyway! Let the ANS-Forth cult members howl and gnash their teeth --- they don't bother me --- they do this all the time anyway.
1.) This is Forth-83 compatible (for example, FIND works correctly).
2.) We have the W D and F constants that indicate the size of cells, double-cells and floats (4, 8 and 8 for a 32-bit system).
3.) The system is restored to a rational state on an abort. CONTEXT CURRENT and BASE are not left as they were when the abort occurred, but are set to FORTH FORTH and 10. The state at the time of the abort is saved somewhere however, so it can be examined in a postmortem to find out what happened.
4.) My rquotations are required to work. They already do work in VFX and SwiftForth, and should work under any Forth system, but they are not ANS-Forth compliant.
5.) LITERAL 2LITERAL FLITERAL and ABORT are all vectorized. The variables 'LITERAL '2LITERAL 'FLITERAL and 'ABORT contain the vectors.
6.) We have the following:
LATEST ( -- xt )
IMMEDIATE@ ( xt -- flag )
VOCNO@ ( xt -- vocno )
SMUDGE@ ( xt -- flag )
SMUDGEABLE@ ( xt -- flag )
IMMEDIATE! ( flag xt -- )
VOCNO! ( vocno xt -- )
SMUDGE! ( flag xt -- )
SMUDGEABLE! ( flag xt -- )
I just wrote this down off the top of my head right now. There may be some minor changes. As I said, the thing to do is write the compiler and put it to use, and only make it the standard after it has proven itself. This is not possible right now though, because ANS-Forth is the standard --- ANS-Forth and Forth-200x have to be killed first --- only then can innovation flourish. I'm not enthusiastic about writing a compiler that nobody will use because it is non-standard and hence meaningless. The design of the compiler has to be collaborative in order for it to be accepted as a new standard.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-22 07:05 +0100 |
| Message-ID | <oftusk$bt1$1@dont-email.me> |
| In reply to | #59704 |
On 5/22/2017 02:46, hughaguilar96@gmail.com wrote: > I just wrote this down off the top of my head right now. Something else we can agree on. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-05-23 13:45 -0700 |
| Message-ID | <2c29d493-9365-454d-8c43-c65503c9af8d@googlegroups.com> |
| In reply to | #59704 |
понедельник, 22 мая 2017 г., 3:46:17 UTC+2 пользователь hughag...@gmail.com написал: > On Sunday, May 21, 2017 at 4:32:11 PM UTC-7, Ilya Tarasov wrote: > > понедельник, 22 мая 2017 г., 0:43:36 UTC+3 пользователь hughag...@gmail.com написал: > > > > >3. More vectorized words like EMIT LITERAL etc. > > > > > > > > Vectorizing LITERAL has a lot of implied assumptions. > > > > Recoognizers make them unnecessary and are probably the better chocie. > > > > > > Recognizers are a can of worms --- there is no way that I would have recognizers in Straight Forth (recognizers and the Paysan-faked quotations are the two primary reasons why I have abandoned Forth-200x as a lost cause) --- vectorizing LITERAL 2LITERAL and FLITERAL is super-simple and does everything necessary for supporting literal numbers in TARG mode colon definitions. > > > > I wonder why such simple things may cause so much flame. Indeed I know an answer, and this answer not laying in the plane of programming. The solution may be simple also - just explain how to write cross-compiler with very easy modifications and self-claimed experts may sit alone and dream about followers. > > A standard would work a lot better if a compiler were written first, and people used the compiler and suggested upgrades, and then after several years everybody said: "This compiler works quite well! Lets call this the standard!" Yes, this is obvious... I hope, for all :) > What happened with ANS-Forth is that Forth Inc. wrote the standard, despite the fact that PolyForth was one of the worst Forth compilers on the market at the time, and Elizabeth Rather said: "In a few years we will hire somebody to write an ANS-Forth compiler for us, because none of us are capable of doing this, but first we want to declare ourselves to be the standard so we can denounce everybody else as being non-standard." This is what I'm suspecting. From strategy point of view, this leads to failure, but if core persons are retired or plan to retire soon, this is understandable. Keeping themselves as world leaders of Forth is pretty well. > As for your idea, "explain how to write cross-compiler with very easy modifications," I could do that at any time. I've already pretty much done this in various posts on comp.lang.forth. I have the Traditional Forth that Yes, I suppose you are ready to explain aspects of Forth known to you. I can confirm this behavior is effective enough, because can create thinking forthers rather than just followers. > I'll explain Traditional Forth anyway! Let the ANS-Forth cult members howl and gnash their teeth --- they don't bother me --- they do this all the time anyway. I'm sure right position will be rewarded sooner or later. To lead a right way is better than to try to guess the conjucture. > 1.) This is Forth-83 compatible (for example, FIND works correctly). > > 2.) We have the W D and F constants that indicate the size of cells, double-cells and floats (4, 8 and 8 for a 32-bit system). Yes, explicit specification od datawidth is useful. I use prefixes derived from Asdsembler^ C, B - byte W - 16-bit word D - 32-bit (double word) Q - 64 bit H (for future) - 128-bit F, SF - for floats and short floats. I think Forth should not redefine datawidth prefixes defined in other languages. Assembler has priority, because handling data at low level looks like approach known for Assembler programmers, so they can switch to Forth easier. > 3.) The system is restored to a rational state on an abort. CONTEXT CURRENT and BASE are not left as they were when the abort occurred, but are set to FORTH FORTH and 10. The state at the time of the abort is saved somewhere however, so it can be examined in a postmortem to find out what happened. Yes. > 4.) My rquotations are required to work. They already do work in VFX and SwiftForth, and should work under any Forth system, but they are not ANS-Forth compliant. I think this is an example of optional feature added by certain developer/team. From my side I think it is rightto add some hooks for features and extensions of such kind. > 5.) LITERAL 2LITERAL FLITERAL and ABORT are all vectorized. The variables 'LITERAL '2LITERAL 'FLITERAL and 'ABORT contain the vectors. This is a kind of hooks I just described. With minor efforts we can add many possibilities. > I just wrote this down off the top of my head right now. There may be some minor changes. As I said, the thing to do is write the compiler and put it to use, and only make it the standard after it has proven itself. This is not possible right now though, because ANS-Forth is the standard --- ANS-Forth and Forth-200x have to be killed first --- only then can innovation flourish. I'm not enthusiastic about writing a compiler that nobody will use because it is non-standard and hence meaningless. The design of the compiler has to be collaborative in order for it to be accepted as a new standard. At least, I can give a link to c.l.f. and ask "do you really want to be like ANS followers?" :)
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-23 22:02 +0100 |
| Message-ID | <og27r5$b9g$1@dont-email.me> |
| In reply to | #59759 |
On 5/23/2017 21:45, Ilya Tarasov wrote: > понедельник, 22 мая 2017 г., 3:46:17 UTC+2 пользователь > hughag...@gmail.com написал: >> >> A standard would work a lot better if a compiler were written >> first, and people used the compiler and suggested upgrades, and >> then after several years everybody said: "This compiler works quite >> well! Lets call this the standard!" > > Yes, this is obvious... I hope, for all :) No, it's not. But hey, if you think you can make it fly, you and Hugh go for it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-24 01:00 -0700 |
| Message-ID | <5f173d73-503d-4ed3-a209-9f244cab057c@googlegroups.com> |
| In reply to | #59704 |
On Monday, 22 May 2017 02:46:17 UTC+1, hughag...@gmail.com wrote: > A standard would work a lot better if a compiler were written first, and people used the compiler and suggested upgrades, and then after several years everybody said: "This compiler works quite well! Lets call this the standard!" > You don't even need a compiler. Just an appendix, showing, for each word the outputs/system state for a given set of inputs. Showing (of course) illegal states, corner cases etc. However, Forth is not alone in not providing this. No standard that I can recall has such content, either as an appendix or any other type of document. They all seem to leave to it the interpretation of the reader. At least Forth has the ANS compliance harness, which is a step in the right direction.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-24 14:07 +0100 |
| Message-ID | <og40d0$9ms$1@dont-email.me> |
| In reply to | #59769 |
On 5/24/2017 09:00, Mark Wills wrote:
> On Monday, 22 May 2017 02:46:17 UTC+1, hughag...@gmail.com wrote:
>> A standard would work a lot better if a compiler were written first, and people used the compiler and suggested upgrades, and then after several years everybody said: "This compiler works quite well! Lets call this the standard!"
>>
> You don't even need a compiler. Just an appendix, showing, for each word
> the outputs/system state for a given set of inputs. Showing (of course)
> illegal states, corner cases etc.
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
means just what I choose it to mean -- neither more nor less."
"The question is," said Alice, "whether you can make words mean so many
different things."
"The question is," said Humpty Dumpty, "which is to be master -- that's
all."
The problem with describing with any accuracy or hope of mutual
understanding and then being able to declare mastery of the word is well
known to people who work on and with standards. Language and words are
hard to pin down. Look at the RFCs like
https://www.ietf.org/rfc/rfc2119.txt RFC 2119,
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Even with that imprecation and a whole page of detailed specification of
the terms in the body of the RFC, look at the next paragraph that
follows the above;
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Oh dear. How do you square all this with your appendix requirements?
Can you do it for just one word for me please? SWAP will do. Now define
corner cases and illegals states. What should happen on stack underflow
or overflow when we try to SWAP, for example <empty> SWAP or <empty> 1
SWAP? Currently, stack overflow and underflow are ambiguous conditions.
How would you rectify that?
The discussion will suddenly move on. SWAP will be relegated to
tomorrow's business. We will spend a couple of hours, then days & weeks
in committee & by web conference & email discussing it, tearing it
apart. Finally we will take a vote on it, assuming that the original
proposer is still sane or even alive.
Consensus may not be reached, as the group breaks into pro and anti
groups, with a developing third party insisting that their stacks are
circular, so overflow & underflow are wind & chuff caused by being
reactionary old-style LIFO stack farts. Humpty Dumpty will be much in
evidence, and poor Alice will much too puzzled to say much of anything.
Meanwhile, the rest of us will be SWAPping values on the stack without
really caring that your appendix (or the mythical compiler based on it)
is unfinished.
>
> However, Forth is not alone in not providing this. No standard that I can
> recall has such content, either as an appendix or any other type of document.
> They all seem to leave to it the interpretation of the reader.
For reasons you are about to discover as you define illegal states and
corner cases for SWAP.
>
> At least Forth has the ANS compliance harness, which is a step in the right
> direction.
>
Agreed. But even that isn't (and can't be) comprehensive.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | gavino himself <jackvanc3@gmail.com> |
|---|---|
| Date | 2017-05-18 22:14 -0700 |
| Message-ID | <d1a6080c-df6e-4f5a-9399-75356fa4135e@googlegroups.com> |
| In reply to | #59445 |
On Wednesday, May 17, 2017 at 3:02:25 PM UTC-4, hughag...@gmail.com wrote: > On Wednesday, May 17, 2017 at 11:30:57 AM UTC-7, Alex wrote: > > On 5/17/2017 19:06, hughaguilar96@gmail.com wrote: > > > I feel confident that I can always come up with a better solution > > > than any other solution (past, present or future) written by anybody > > > else. > > > > Misplaced confidence, as usual. Counter evidence and two fairly > > significant clangers are: providing late binding macros and a sort that > > swaps records rather than pointers to records. > > I'm the only Forth programmer who has ever written a late-binding MACRO: --- it is in the novice-package to be released soon --- I had a late-binding MACRO: in MFX written in 1994, but I was slow to implement this in ANS-Forth because I first had to figure out how to write the disambiguifiers so FIND would work, but I am the only Forther to ever write this in either Forth-83 or ANS-Forth. > > My SORT has always worked with elements of any size --- the element can be a record or a pointer to a record --- your claim that I don't understand that an array can contain pointers to records is bizarre; this is very basic programming; I knew this much when I was still in high-school. The line-number BASIC I used in high-school on the Apple-II didn't support pointers or records though, so I would have an array containing indices into other arrays (one array for each field in a pseudo-record) > > ANS-Forth is a cult! ANS-Forth is founded entirely upon the idea that the "leading expert" Elizabeth Rather and her appointed committee know everything there is to know about Forth --- and that any critic (me) is utterly incompetent, and doesn't even know what a pointer is. This is very comparable to religious cults that claim to have a monopoly on knowledge of spirituality --- and that any critic is utterly ignorant, and no better than an animal. huge ever do forth cgi? I am kinda interested in it...... and forthish database to support it....for e commerce or blog etc.... how hard to do forth cgi werc.cat-v.org some thing like this but I assume forth is more powerful than rc shell and awk sed etc.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web