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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-16 19:35 -0700 |
| Message-ID | <70a17eb9-c4bd-4202-b174-5c16d4dfa546@googlegroups.com> |
| In reply to | #59388 |
On Wednesday, May 17, 2017 at 3:21:44 AM UTC+9, hughag...@gmail.com wrote: > On Tuesday, May 16, 2017 at 4:05:27 AM UTC-7, Gerry wrote: > > On 15/05/2017 19:43, hughaguilar96@somewhere wrote: > > > What I am saying, is that if they are going to describe themselves as leaders of the Forth community, they should first write useful Forth code-libraries --- this would be a good start toward gaining the respect of Forthers such as myself --- this is actually the only way to gain credence as leaders. > > > > > > > Evidently they don't agree. I don't think they "declare themselves to be > > the rulers of the world" - only the world of ANS Forth and Forth 2012 > > and following standards. And as the Forth 200X Standard Committee that > > is their right and responsibility. > > Obviously, I meant the world of Forth --- the Forth-200x committee also mean the world of Forth --- they use the terms "Forth" and "ANS-Forth" as synonyms, despite the fact that Charles Moore said that ANS-Forth is not Forth but is a Forth-like language at best. > > Your use of the word "right" is interesting --- is this a God-given right? --- this sounds a lot like the monarchies of the Middle Ages when the royal families claimed to have a divine right to rule over the peasants. > Actually, according to some people, the authors of a creative work do have a natural right to exercise a certain amount of influence over what is done with the creative work. What that factoid has to do with the rest of this discussion is not something I want to take the time to rant about today. I have lots of other things I want to do. -- Joel Rees Ranting randomly http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 11:06 -0700 |
| Message-ID | <76594ad7-b488-49ce-acbd-08942fb2b017@googlegroups.com> |
| In reply to | #59411 |
On Tuesday, May 16, 2017 at 7:35:22 PM UTC-7, Joel Rees wrote: > On Wednesday, May 17, 2017 at 3:21:44 AM UTC+9, hughag...@gmail.com wrote: > > On Tuesday, May 16, 2017 at 4:05:27 AM UTC-7, Gerry wrote: > > > On 15/05/2017 19:43, hughaguilar96@somewhere wrote: > > > > What I am saying, is that if they are going to describe themselves as leaders of the Forth community, they should first write useful Forth code-libraries --- this would be a good start toward gaining the respect of Forthers such as myself --- this is actually the only way to gain credence as leaders. > > > > > > > > > > Evidently they don't agree. I don't think they "declare themselves to be > > > the rulers of the world" - only the world of ANS Forth and Forth 2012 > > > and following standards. And as the Forth 200X Standard Committee that > > > is their right and responsibility. > > > > Obviously, I meant the world of Forth --- the Forth-200x committee also mean the world of Forth --- they use the terms "Forth" and "ANS-Forth" as synonyms, despite the fact that Charles Moore said that ANS-Forth is not Forth but is a Forth-like language at best. > > > > Your use of the word "right" is interesting --- is this a God-given right? --- this sounds a lot like the monarchies of the Middle Ages when the royal families claimed to have a divine right to rule over the peasants. > > > > Actually, according to some people, the authors of a creative work do > have a natural right to exercise a certain amount of influence over what > is done with the creative work. I'm not doing anything with Stephen Pelc's creative work. I have no idea what you are talking about --- I wrote MFX myself --- your suggestion that I'm dependent upon Stephen Pelc or anybody else is just insulting nonsense. I have never seen the source-code for any other cross-compiler. I have not read the Forth-200x document on cross-compilation --- Jeff Fox told me that it was over-complicated and not worth reading --- only in rare circumstances (the LLRB tree in the novice-package) do I use somebody else's code as a basis for my code, and MFX was not one of these circumstances. I prefer to figure things out myself. 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.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-17 19:30 +0100 |
| Message-ID | <ofi4ml$tnf$1@dont-email.me> |
| In reply to | #59441 |
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. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 12:02 -0700 |
| Message-ID | <4bf4f6e1-03c6-44b9-b588-e2a954a99cf5@googlegroups.com> |
| In reply to | #59443 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-17 20:41 +0100 |
| Message-ID | <ofi8qv$dgd$1@dont-email.me> |
| In reply to | #59445 |
On 5/17/2017 20:02, hughaguilar96@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. The problem was that your macros were late binding, and you claimed to be changing them to early binding. See this thread. https://groups.google.com/d/msg/comp.lang.forth/92KNs8p4J6Y/QJVXfKbGDQAJ And no, you're not the only person to have written a macro (early or late bound) in Forth. Forth is one huge macro factory. I think you think too rigidly about how code is written & consumed. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-17 19:17 -0700 |
| Message-ID | <fe03bf9d-e414-4d8c-afb3-9ba123f917fd@googlegroups.com> |
| In reply to | #59447 |
On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex wrote: > [...] Forth is one huge macro factory. That is one way to look at it, but there are limits to the approach. Forth words aren't text macros, and they aren't in-line machine/assembly code macros. (And they aren't, for example, CAD macros.) > I think you think > too rigidly about how code is written & consumed. From my point of view, we all on this list think too rigidly about how code is written and used, etc. (Including me. I've just, yesterday and today, finally seen past a few mental blocks that had me stuck when working with double integer division. Talking over use of the FP stack with Anton helped, even though the blocked thinking was not related to the stack question, and even though we aren't coming to a *perfect* meeting of minds there.) It's not necessarily a bad thing. Moving ahead requires finding somewhat stable ground to put our feet on. -- Joel Rees Delusions of being a writer: http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 20:58 -0700 |
| Message-ID | <fcd02164-f109-432e-9f5e-004fd7143049@googlegroups.com> |
| In reply to | #59455 |
On Wednesday, May 17, 2017 at 7:17:09 PM UTC-7, Joel Rees wrote:
> On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex wrote:
> > [...] Forth is one huge macro factory.
>
> That is one way to look at it, but there are limits to the approach.
>
> Forth words aren't text macros, and they aren't in-line machine/assembly
> code macros. (And they aren't, for example, CAD macros.)
>
> > I think you think
> > too rigidly about how code is written & consumed.
>
> From my point of view, we all on this list think too rigidly about
> how code is written and used, etc.
Most likely, when he says that, "Forth is one huge macro factory," he is referring to code like this:
: bounds ( adr cnt -- past-adr adr )
postpone over
postpone +
postpone swap
; immediate
I've got quite a lot of this in the novice-package. This would be more easily written as:
macro: bounds ( adr cnt -- past-adr adr )
over + swap ;
MACRO: is a general-purpose defining word (the novice-packag is all about general-purpose code). I was only able to write MACRO: with early-binding after I figured out how two write disambiguifiers because I need FIND to work on all words (including IF etc. that FIND in ANS-Forth is ambiguous on and may even abort on).
As I said, I had MACRO: with early-binding working in MFX written in 1994/1995 (written in UR/Forth). Getting it to work in ANS-Forth was more difficult because I needed the disambiguifiers --- I had a late-binding version that I used for several years.
I'm not "thinking too rigidly" --- I'm writing general-purpose code --- that is the opposite of being rigid.
> (Including me. I've just, yesterday and today, finally seen past a
> few mental blocks that had me stuck when working with double integer
> division. Talking over use of the FP stack with Anton helped, even
> though the blocked thinking was not related to the stack question,
> and even though we aren't coming to a *perfect* meeting of minds
> there.)
>
> It's not necessarily a bad thing. Moving ahead requires finding
> somewhat stable ground to put our feet on.
I have a double-precision division in the novice-package --- it is in CF.4TH --- this is the one file in the novice-package that I didn't write myself (it was written by Nathaniel Grossman and published in "Forth Dimensions" in Sept/Oct 1984, and all I did was upgrade it from 16-bit Forth-83 to 32-bit ANS-Forth).
This kind of math is pretty much out of my league --- I might be able to figure it out --- I just copied the code from Grossman's article though, without understanding it.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 10:46 +0100 |
| Message-ID | <ofjqbv$rkv$1@dont-email.me> |
| In reply to | #59457 |
On 5/18/2017 04:58, hughaguilar96@gmail.com wrote:
>
> Most likely, when he says that, "Forth is one huge macro factory," he
> is referring to code like this:
>
> : bounds ( adr cnt -- past-adr adr ) postpone over postpone +
> postpone swap ; immediate
>
> I've got quite a lot of this in the novice-package. This would be
> more easily written as:
>
> macro: bounds ( adr cnt -- past-adr adr ) over + swap ;
With recognizers (which I sincerely hope get ANS-ified soon), that becomes
: bounds ]] over + swap [[ ; immediate
This gets rid of a lot of the deficiencies of MACRO: type approaches,
such as getting undesirable late binding as a side effect of
EVALUATEing. It also has the advantage that it's programmable; the macro
bit is only between ]] and [[
variable useover?
true useover? !
: check13
useover? @ if
]] 13 over = if [[
else
]] dup 13 = if [[
then ; immediate
>
> MACRO: is a general-purpose defining word (the novice-packag is all
> about general-purpose code). I was only able to write MACRO: with
> early-binding after I figured out how two write disambiguifiers
> because I need FIND to work on all words (including IF etc. that FIND
> in ANS-Forth is ambiguous on and may even abort on).
>
> As I said, I had MACRO: with early-binding working in MFX written in
> 1994/1995 (written in UR/Forth). Getting it to work in ANS-Forth was
> more difficult because I needed the disambiguifiers --- I had a
> late-binding version that I used for several years.
>
> I'm not "thinking too rigidly" --- I'm writing general-purpose code
> --- that is the opposite of being rigid.
Rigidity is, for example, designing code that only uses arrays or
"chains", something you recommend frequently as part of your
StraightForth agenda. That it's claimed as general purpose doesn't
change that.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 08:43 -0500 |
| Message-ID | <PrudnVxOtqt6OYDEnZ2dnUU7-dXNnZ2d@supernews.com> |
| In reply to | #59483 |
Alex <alex@rivadpm.com> wrote: > On 5/18/2017 04:58, hughaguilar96@gmail.com wrote: > >> >> Most likely, when he says that, "Forth is one huge macro factory," he >> is referring to code like this: >> >> : bounds ( adr cnt -- past-adr adr ) postpone over postpone + >> postpone swap ; immediate >> >> I've got quite a lot of this in the novice-package. This would be >> more easily written as: >> >> macro: bounds ( adr cnt -- past-adr adr ) over + swap ; > > With recognizers (which I sincerely hope get ANS-ified soon), that becomes > > : bounds ]] over + swap [[ ; immediate IMO, defining BOUNDS as a macro is usually the wrong thing to do. Firstly, Forth is designed to make calls as fast as possible, so that people don't have to worry about the cost of entry + exit. It would be a damn shame if all the one-liners ended up being defined as macros. Secondly, inlining is straightforward optimization technology for Forth compilers; let the optimizer do its job. Thirdly, most uses of BOUNDS will not be in a hot code path because they're outside a loop. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 16:00 +0100 |
| Message-ID | <ofkcol$rqu$1@dont-email.me> |
| In reply to | #59494 |
On 5/18/2017 14:43, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>> On 5/18/2017 04:58, hughaguilar96@gmail.com wrote:
>>
>>>
>>> Most likely, when he says that, "Forth is one huge macro factory," he
>>> is referring to code like this:
>>>
>>> : bounds ( adr cnt -- past-adr adr ) postpone over postpone +
>>> postpone swap ; immediate
>>>
>>> I've got quite a lot of this in the novice-package. This would be
>>> more easily written as:
>>>
>>> macro: bounds ( adr cnt -- past-adr adr ) over + swap ;
>>
>> With recognizers (which I sincerely hope get ANS-ified soon), that becomes
>>
>> : bounds ]] over + swap [[ ; immediate
>
> IMO, defining BOUNDS as a macro is usually the wrong thing to do.
> Firstly, Forth is designed to make calls as fast as possible, so that
> people don't have to worry about the cost of entry + exit. It would
> be a damn shame if all the one-liners ended up being defined as
> macros. Secondly, inlining is straightforward optimization technology
> for Forth compilers; let the optimizer do its job. Thirdly, most uses
> of BOUNDS will not be in a hot code path because they're outside a
> loop.
>
> Andrew.
>
One of the interesting aspects of optimizing Forth is the benefit of
decomposing words to simple literals, and stack operations which can be
eliminated, especially on register based machines.
Yes, simple peephole optimization and inlining of words like
: bounds over + swap ;
can be done at the time it's compiled, and it's pretty easy to judge if
the code is an inline opportunity.
But we need some way to express the individual parts to more
sophisticated code generators (say, those based on SSA) that optimize
for much larger chunks and not just this word.
Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't be
interpreted. WF32 supports separate interpret/compile semantics.
: bounds over + swap
compiles> drop ]] over + swap [[ ;
This helps the optimizer, but unfortunately the construction is not
automatically derived from the plain colon definition (and perhaps for
some definitions it may not be possible to do so).
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-20 01:47 -0700 |
| Message-ID | <b950d211-a6e5-4465-8a24-9460cadb20b4@googlegroups.com> |
| In reply to | #59504 |
On Thursday, May 18, 2017 at 8:00:49 AM UTC-7, Alex wrote:
> Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't be
> interpreted. WF32 supports separate interpret/compile semantics.
>
> : bounds over + swap
> compiles> drop ]] over + swap [[ ;
A fatal flaw! All the Forth code that I write has fatal flaws, according to Alex McDonald.
This is trivial to fix though:
macro: bounds ( adr cnt -- past-adr adr )
over + swap ;
: bounds state @ if postpone bounds else bounds then ;
> This helps the optimizer, but unfortunately the construction is not
> automatically derived from the plain colon definition (and perhaps for
> some definitions it may not be possible to do so).
A lot of macros can't be turned into colon words. For example:
SwiftForth? [if]
icode next>r ( node -- node ) \ r: -- next-node
0 [ebx] push
ret end-code
[else]
macro: next>r ( node -- node ) \ r: -- next-node
dup .fore @ >r ;
[then]
macro: each[ \ toucher: i*x node -- j*x
begin dup while
next>r ;
macro: ]each
r> repeat drop ;
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-20 13:03 +0100 |
| Message-ID | <ofpb3c$sro$1@dont-email.me> |
| In reply to | #59579 |
On 5/20/2017 09:47, hughaguilar96@gmail.com wrote: > On Thursday, May 18, 2017 at 8:00:49 AM UTC-7, Alex wrote: >> Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't be >> interpreted. WF32 supports separate interpret/compile semantics. >> >> : bounds over + swap compiles> drop ]] over + swap [[ ; > > A fatal flaw! All the Forth code that I write has fatal flaws, > according to Alex McDonald. > > This is trivial to fix though: > > macro: bounds ( adr cnt -- past-adr adr ) over + swap ; > > : bounds state @ if postpone bounds else bounds then ; This has a fatal flaw. But I'll let you work out why. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-20 17:51 -0700 |
| Message-ID | <996f68b4-5359-4582-b9c6-b7e30b91a640@googlegroups.com> |
| In reply to | #59588 |
On Saturday, May 20, 2017 at 5:03:05 AM UTC-7, Alex wrote: > On 5/20/2017 09:47, hughaguilar96@gmail.com wrote: > > On Thursday, May 18, 2017 at 8:00:49 AM UTC-7, Alex wrote: > >> Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't be > >> interpreted. WF32 supports separate interpret/compile semantics. > >> > >> : bounds over + swap compiles> drop ]] over + swap [[ ; > > > > A fatal flaw! All the Forth code that I write has fatal flaws, > > according to Alex McDonald. > > > > This is trivial to fix though: > > > > macro: bounds ( adr cnt -- past-adr adr ) over + swap ; > > > > : bounds state @ if postpone bounds else bounds then ; > This has a fatal flaw. But I'll let you work out why. Alex McDonald wants to be a teacher! In order to be a teacher, it is necessary for him to assume gross ignorance on my part. I have every expectation that he is now going to spend the next four years teaching me the evils of ticking a state-smart word. The problem with comp.lang.forth is that we have too many people with very minimal knowledge who want to be teachers. Here is a nausea-inducing example: https://groups.google.com/forum/#!topic/comp.lang.forth/eZPi8DA6Aso Here is another example: https://groups.google.com/forum/#!topic/comp.lang.forth/hEUsPvmxqbg%5B76-100%5D Alex has been trying for four years to teach me the fact that it is possible to have an array of pointers to structs. This is so tedious! I mean, four years is a long time! On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > > On Monday, March 6, 2017 at 7:07:08 AM UTC-7, Alex wrote: > > >> By the way, any progress on your understanding of pointers? Can you > >> for example sort a singly linked list with Wil Baden's sort yet? Or > >> do the same with your inefficent sort? > > > > You think that you are beating me strong by claiming that I don't > > understand pointers. This is why I expect ANS-Forth to die --- every > > time that I write any code, even simple stuff like a SORT function, > > the ANS-Forth cult respond by making great fools out of themselves > > --- I don't have to shine a spotlight on the stupidity of ANS-Forth, > > because the cult members are shining the spotlight in the own eyes, > > making themselves look stupid and simultaneously blinding themselves > > to the real world. > > > > Anyway, I've never seen Wil Baden's much-touted SORT function. I > > tried to download it but the webpage was kaput. > > http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still > confusing the heck out of you. How can it sort anything other than an > array of cells? Hmm? How?
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-21 07:51 +0100 |
| Message-ID | <ofrd76$t8b$1@dont-email.me> |
| In reply to | #59622 |
On 5/21/2017 01:51, hughaguilar96@gmail.com wrote: > On Saturday, May 20, 2017 at 5:03:05 AM UTC-7, Alex wrote: >> On 5/20/2017 09:47,hughaguilar96@gmail.com wrote: >>> On Thursday, May 18, 2017 at 8:00:49 AM UTC-7, Alex wrote: >>>> Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't >>>> be interpreted. WF32 supports separate interpret/compile >>>> semantics. >>>> >>>> : bounds over + swap compiles> drop ]] over + swap [[ ; >>> A fatal flaw! All the Forth code that I write has fatal flaws, >>> according to Alex McDonald. >>> >>> This is trivial to fix though: >>> >>> macro: bounds ( adr cnt -- past-adr adr ) over + swap ; >>> >>> : bounds state @ if postpone bounds else bounds then ; >> This has a fatal flaw. But I'll let you work out why. > Alex McDonald wants to be a teacher! In order to be a teacher, it is > necessary for him to assume gross ignorance on my part. I have every > expectation that he is now going to spend the next four years > teaching me the evils of ticking a state-smart word. No, that's not what's wrong. Did you tried running it and looking at what your code generated? : foo bounds ; It's not OVER + SWAP because the last definition of BOUNDS is missing an immediate. For anyone who's interested, Hugh's reference to state-smartness evils is covered here by Anton Ertl http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-21 00:11 -0700 |
| Message-ID | <6bc25f23-37fd-4ead-a4e2-7797241e836a@googlegroups.com> |
| In reply to | #59629 |
On Saturday, May 20, 2017 at 11:51:32 PM UTC-7, Alex wrote:
> On 5/21/2017 01:51, hughaguilar96@gmail.com wrote:
> > On Saturday, May 20, 2017 at 5:03:05 AM UTC-7, Alex wrote:
> >> On 5/20/2017 09:47,hughaguilar96@gmail.com wrote:
> >>> On Thursday, May 18, 2017 at 8:00:49 AM UTC-7, Alex wrote:
> >>>> Hugh's MACRO: definition of BOUNDS has one fatal flaw; it can't
> >>>> be interpreted. WF32 supports separate interpret/compile
> >>>> semantics.
> >>>>
> >>>> : bounds over + swap compiles> drop ]] over + swap [[ ;
> >>> A fatal flaw! All the Forth code that I write has fatal flaws,
> >>> according to Alex McDonald.
> >>>
> >>> This is trivial to fix though:
> >>>
> >>> macro: bounds ( adr cnt -- past-adr adr ) over + swap ;
> >>>
> >>> : bounds state @ if postpone bounds else bounds then ;
> >> This has a fatal flaw. But I'll let you work out why.
> > Alex McDonald wants to be a teacher! In order to be a teacher, it is
> > necessary for him to assume gross ignorance on my part. I have every
> > expectation that he is now going to spend the next four years
> > teaching me the evils of ticking a state-smart word.
>
> No, that's not what's wrong. Did you tried running it and looking at
> what your code generated?
>
> : foo bounds ;
>
> It's not OVER + SWAP because the last definition of BOUNDS is missing an
> immediate.
That was a typo --- I forgot the IMMEDIATE --- it should have been:
macro: bounds ( adr cnt -- past-adr adr )
over + swap ;
: bounds state @ if postpone bounds else bounds then ;
immediate
Anyway --- go fuck yourself --- you are not my peer!
Elizabeth Rather and Stephen Pelc appreciate your brown-nosing --- they believe that you are supporting ANS-Forth, and they may even appoint you to the Forth-200x committee --- but you just shine a spotlight on the fact that ANS-Forth is a cult, and this helps to kill ANS-Forth in the real world.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-21 17:46 +0100 |
| Message-ID | <ofsg3f$7gp$1@dont-email.me> |
| In reply to | #59632 |
On 5/21/2017 08:11, hughaguilar96@gmail.com wrote: > > Anyway --- go fuck yourself --- you are not my peer! That's something we can both agree on. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-21 10:34 -0700 |
| Message-ID | <95db3410-35e8-4f6a-b600-942ffb4949d1@googlegroups.com> |
| In reply to | #59670 |
On Sunday, May 21, 2017 at 9:46:53 AM UTC-7, Alex wrote: > On 5/21/2017 08:11, hughaguilar96@gmail.com wrote: > > > > > Anyway --- go fuck yourself --- you are not my peer! > > That's something we can both agree on. > > -- > Alex My disambiguifiers are the heart and soul of ANS-Forth programming! It is not really possible to write non-trivial ANS-Forth code without disambiguifiers (assuming that FIND is needed for non-trivial programs, which is usually the case). But the disambiguifiers undermine the credibility of ANS-Forth because this shines a spotlight on the fact that ANS-Forth is ambiguous, which implies that ANS-Forth was designed by an idiot and should not be taken seriously. So, the disambiguifiers both keep ANS-Forth on life-support and show everybody that ANS-Forth deserves to die --- keeping ANS-Forth on life-support does not help the Forth community --- this is like chemotherapy in reverse: it kills the patient and saves the tumor! My early-binding MACRO: only works because of the disambiguifiers. The reason why it didn't work back in 2009 when I ported it from UR/Forth to ANS-Forth was that FIND in ANS-Forth didn't work --- this is why I wrote a late-binding MACRO: instead, and used that for years --- I wasn't able to write an early-binding MACRO: in ANS-Forth until I had disambiguifiers available. All in all, my early-binding MACRO: was a real coup --- this totally undermines the credibility of the Forth-200x committee --- they are incapable of writing code like this, because they refuse to acknowledge the existence of the disambiguifiers (because they don't want to publicly admit that ANS-Forth is ambiguous, because this makes them look ridiculous). Here is an example of MACRO: in action: macro: programmer-type ( flag -- str ) if c" smart" else c" dumb" then ; ok : alex 0 programmer-type count type ; ok : hugh 1 programmer-type count type ; ok alex dumb ok hugh smart ok The ANS-Forth cult members, such as Alex McDonald, are incapable of writing an early-binding MACRO: --- this is because they refuse to acknowledge the existence of the disambiguifiers --- they are in denial regarding the ambiguity of FIND in ANS-Forth, which is a fatal flaw for them.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-21 20:57 +0100 |
| Message-ID | <ofsr93$e9c$1@dont-email.me> |
| In reply to | #59673 |
On 5/21/2017 18:34, hughaguilar96@gmail.com wrote: > On Sunday, May 21, 2017 at 9:46:53 AM UTC-7, Alex wrote: >> On 5/21/2017 08:11, hughaguilar96@gmail.com wrote: >> >>> >>> Anyway --- go fuck yourself --- you are not my peer! >> >> That's something we can both agree on. >> >> -- Alex > > My disambiguifiers are the heart and soul of ANS-Forth programming! No, they're not. Seriously. They address your obsession of using FIND to build steatopygic macros. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-18 04:08 -0500 |
| Message-ID | <dLednZAUu6vq-YDEnZ2dnUU7-aOdnZ2d@supernews.com> |
| In reply to | #59455 |
Joel Rees <joel.rees@gmail.com> wrote: > On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex wrote: >> [...] Forth is one huge macro factory. > > That is one way to look at it, but there are limits to the approach. > > Forth words aren't text macros, and they aren't in-line machine/assembly > code macros. (And they aren't, for example, CAD macros.) But they are macros in the same sense as LISP macros. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 10:51 +0100 |
| Message-ID | <ofjql7$si3$1@dont-email.me> |
| In reply to | #59455 |
On 5/18/2017 03:17, Joel Rees wrote:
> On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex wrote:
>> [...] Forth is one huge macro factory.
>
> That is one way to look at it, but there are limits to the approach.
What are they?
>
> Forth words aren't text macros, and they aren't in-line machine/assembly
> code macros. (And they aren't, for example, CAD macros. >
I'm not sure what you mean by "text macro" or "inline assembley macro".
On my understanding of what you might mean, Forth words can be these
things. For example:
: generate-mov-eax-1
also assembler
mov eax 1
previous ;
--
Alex
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web