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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-18 05:15 -0700 |
| Message-ID | <810b8769-5f5f-44b5-a755-c3fb04fa2541@googlegroups.com> |
| In reply to | #59484 |
On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: > 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? Is a function call equivalent to a macro invocation? > > 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" What is text? What is substitution? What is macro substitution? What is the language m4? What is a C preprocessor? > or "inline assembley macro". > On my understanding of what you might mean, Forth words can be these > things. Can be. Most usually, they are other things. > For example: > > : generate-mov-eax-1 > also assembler > mov eax 1 > previous ; > > -- > Alex And that looks something like an assembler macro. But that is not a typical Forth word, either. Some people note that function or subroutine calls behave in a way similar to macro invocation, but there are fundamental differences. Most prominently, Forth words write their substitutions to the time domain instead of into a file stream. -- Joel Rees Delusions of reinventing the industry all by myself: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 14:51 +0100 |
| Message-ID | <ofk8mn$dbn$1@dont-email.me> |
| In reply to | #59492 |
On 5/18/2017 13:15, Joel Rees wrote: > On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: >> 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? > > Is a function call equivalent to a macro invocation? Yes. Forth doesn't make that distinction, since interpretation (or parsing if you wish) and compilation (code generation) are not separate nor serial phases of execution as in other languages. > >>> 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" > > What is text? What is substitution? > > What is macro substitution? > > What is the language m4? > > What is a C preprocessor? Great questions. What problem are you addressing that Forth not having "text macros" is an issue? You might want to consider my first answer above on interpreting/compiling. > >> or "inline assembley macro". On my understanding of what you might >> mean, Forth words can be these things. > > Can be. > > Most usually, they are other things. Well, it's moved you on from your prior statement that "Forth words aren't [x] macros". > >> For example: >> >> : generate-mov-eax-1 also assembler mov eax 1 previous ; >> >> -- Alex > > And that looks something like an assembler macro. > > But that is not a typical Forth word, either. What's typical? (This is a serious question, since I can't see the point you're trying to make here at all.) > > Some people note that function or subroutine calls behave in a way > similar to macro invocation, but there are fundamental differences. > Most prominently, Forth words write their substitutions to the time > domain instead of into a file stream. You've lost me completely now. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-18 09:18 -0700 |
| Message-ID | <b0df9242-7930-41c3-bfcf-3d50de546fdf@googlegroups.com> |
| In reply to | #59495 |
On Thursday, May 18, 2017 at 10:51:31 PM UTC+9, Alex wrote: > On 5/18/2017 13:15, Joel Rees wrote: > > On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: > >> 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? > > > > Is a function call equivalent to a macro invocation? > > Yes. Forth doesn't make that distinction, since interpretation (or > parsing if you wish) and compilation (code generation) are not separate > nor serial phases of execution as in other languages. Where I come from, macros involve substitution. An optimizing Forth compiler does flatten leaf calls, and that looks like substitution (and is), but the paradigm is a call paradigm, not a substitution paradigm. Otherwise, we'd have no need for the inner interpreter, and our program objects would lose their compactness. > >>> 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" > > > > What is text? What is substitution? > > > > What is macro substitution? > > > > What is the language m4? > > > > What is a C preprocessor? > > Great questions. What problem are you addressing that Forth not having > "text macros" is an issue? You might want to consider my first answer > above on interpreting/compiling. Who said I was addressing a problem. Someone said Forth could be called a macro factory or something like that, and I thought it worth the trouble to try to point out that routine call and code substitution are two rather different approaches to interpreting the symbols of a program language. > >> or "inline assembley macro". On my understanding of what you might > >> mean, Forth words can be these things. > > > > Can be. > > > > Most usually, they are other things. > > Well, it's moved you on from your prior statement that "Forth words > aren't [x] macros". You took exception to a misinterpretation of what I said, I guess. > >> For example: > >> > >> : generate-mov-eax-1 also assembler mov eax 1 previous ; > >> > >> -- Alex > > > > And that looks something like an assembler macro. > > > > But that is not a typical Forth word, either. > > What's typical? (This is a serious question, since I can't see the point > you're trying to make here at all.) Well, I don't imagine that a typical application written in Forth has a lot of words which directly invoke the assembler for the target CPU, at any rate. Maybe I'm wrong and the target CPU is one of the reasons a lot of Forth Applications are not portable. > > Some people note that function or subroutine calls behave in a way > > similar to macro invocation, but there are fundamental differences. > > Most prominently, Forth words write their substitutions to the time > > domain instead of into a file stream. > > You've lost me completely now. Do my comments about flattening leaf calls help? -- Joel Rees Randomly ranting: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 21:15 +0100 |
| Message-ID | <ofkv6a$ua1$1@dont-email.me> |
| In reply to | #59508 |
On 5/18/2017 17:18, Joel Rees wrote: > On Thursday, May 18, 2017 at 10:51:31 PM UTC+9, Alex wrote: >> On 5/18/2017 13:15, Joel Rees wrote: >>> On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: >>>> 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? >>> >>> Is a function call equivalent to a macro invocation? >> >> Yes. Forth doesn't make that distinction, since interpretation (or >> parsing if you wish) and compilation (code generation) are not >> separate nor serial phases of execution as in other languages. > > Where I come from, macros involve substitution. But not necessarily textual substitution. > > An optimizing Forth compiler does flatten leaf calls, and that looks > like substitution (and is), but the paradigm is a call paradigm, not > a substitution paradigm. > > Otherwise, we'd have no need for the inner interpreter, and our > program objects would lose their compactness. I get "is a call paradigm, not a substitution paradigm" but beyond that you've lost me again. > >>>>> 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" >>> >>> What is text? What is substitution? >>> >>> What is macro substitution? >>> >>> What is the language m4? >>> >>> What is a C preprocessor? >> >> Great questions. What problem are you addressing that Forth not >> having "text macros" is an issue? You might want to consider my >> first answer above on interpreting/compiling. > > Who said I was addressing a problem. > > Someone said Forth could be called a macro factory or something like > that, and I thought it worth the trouble to try to point out that > routine call and code substitution are two rather different > approaches to interpreting the symbols of a program language. Again, I don't know what you mean here. An example might help. >>>> For example: >>>> >>>> : generate-mov-eax-1 also assembler mov eax 1 previous ; >>>> >>>> -- Alex >>> >>> And that looks something like an assembler macro. >>> >>> But that is not a typical Forth word, either. >> >> What's typical? (This is a serious question, since I can't see the >> point you're trying to make here at all.) > > Well, I don't imagine that a typical application written in Forth has > a lot of words which directly invoke the assembler for the target > CPU, at any rate. > > Maybe I'm wrong and the target CPU is one of the reasons a lot of > Forth Applications are not portable. It was an example of your case of "inline assembley macro", hence it used assembler (which is usually not portable). It doesn't indicate a fundamental lack of portability in Forth. > >>> Some people note that function or subroutine calls behave in a >>> way similar to macro invocation, but there are fundamental >>> differences. Most prominently, Forth words write their >>> substitutions to the time domain instead of into a file stream. >> >> You've lost me completely now. > > Do my comments about flattening leaf calls help? I'm sorry, no. Quite the reverse. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-18 19:49 -0700 |
| Message-ID | <ad035ad4-09be-4f30-876a-f210064ee2da@googlegroups.com> |
| In reply to | #59515 |
On Friday, May 19, 2017 at 5:15:18 AM UTC+9, Alex wrote: > On 5/18/2017 17:18, Joel Rees wrote: > > On Thursday, May 18, 2017 at 10:51:31 PM UTC+9, Alex wrote: > >> On 5/18/2017 13:15, Joel Rees wrote: > >>> On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: > >>>> 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? > >>> > >>> Is a function call equivalent to a macro invocation? > >> > >> Yes. Forth doesn't make that distinction, since interpretation (or > >> parsing if you wish) and compilation (code generation) are not > >> separate nor serial phases of execution as in other languages. > > > > Where I come from, macros involve substitution. > > But not necessarily textual substitution. > > > > > An optimizing Forth compiler does flatten leaf calls, and that looks > > like substitution (and is), but the paradigm is a call paradigm, not > > a substitution paradigm. > > > > Otherwise, we'd have no need for the inner interpreter, and our > > program objects would lose their compactness. > > I get "is a call paradigm, not a substitution paradigm" but beyond that > you've lost me again. Interesting. Are you familiar with an inner interpreter? Not just the concept, but an actual inner interpreter? Are you familiar with the Forth symbol table? Are you familiar with the concept of an i-code (as we used to call them before the Java community implicitly made byte-code an improper synonym for i-code)? > >>>>> 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" > >>> > >>> What is text? What is substitution? > >>> > >>> What is macro substitution? > >>> > >>> What is the language m4? > >>> > >>> What is a C preprocessor? > >> > >> Great questions. What problem are you addressing that Forth not > >> having "text macros" is an issue? You might want to consider my > >> first answer above on interpreting/compiling. > > > > Who said I was addressing a problem. > > > > Someone said Forth could be called a macro factory or something like > > that, and I thought it worth the trouble to try to point out that > > routine call and code substitution are two rather different > > approaches to interpreting the symbols of a program language. > > Again, I don't know what you mean here. An example might help. Here's something from a project I've been spinning my wheels on: ----------------- ( This probably isn't really a good idea. Much better to just implement UMD* in assembler. ) ( AL AH B --- QL QML QMH : unsigned double by unsigned single yielding three-cell unsigned ) : UDS* ( ud u --- uhq ) DUP >R SWAP >R ( AL B ) UM* 0 ( ready to sum into ) R> R> ( AH B ) UM* D+ ; ----------------- The above is not a macro. Now, if you consider the time domain to be a medium, and semantics to be symbols, then we can say we don't need to make a distinction. And semantics are, in fact, symbolic. And the time domain is, in fact, a medium for writing behavior into. For us mortals, it helps to make a distinction between symbolic behavior and non-symbolic behavior. Otherwise, we don't know when to stop talking and start doing. I'm sure that doesn't help. Back to the example I just gave you. That's a list of instructions. Conceptually, a Forth compiler is going to string that together as a series of calls to code. Many modern Forths can in-line that, but let's set that aside for a moment. In-lining is not a fundamental characteristic of Forth interpreters. It's a relatively advanced mode of operation. > >>>> For example: > >>>> > >>>> : generate-mov-eax-1 also assembler mov eax 1 previous ; > >>>> > >>>> -- Alex > >>> > >>> And that looks something like an assembler macro. > >>> > >>> But that is not a typical Forth word, either. > >> > >> What's typical? (This is a serious question, since I can't see the > >> point you're trying to make here at all.) > > > > Well, I don't imagine that a typical application written in Forth has > > a lot of words which directly invoke the assembler for the target > > CPU, at any rate. > > > > Maybe I'm wrong and the target CPU is one of the reasons a lot of > > Forth Applications are not portable. > > It was an example of your case of "inline assembley macro", hence it > used assembler (which is usually not portable). It doesn't indicate a > fundamental lack of portability in Forth. If this is to be used in assembly level source code, it would be an example of a macro that you have defined in your Forth. Elsewhere, it might be more descriptive to call it an in-line call. It is fundamentally different from the example I presented above. (Unless your Forth is really aggressive about in-lining, but let's not get distracted yet.) (Oh, and unless you like to consider time as paper to write on, but let's ignore that question entirely.) > >>> Some people note that function or subroutine calls behave in a > >>> way similar to macro invocation, but there are fundamental > >>> differences. Most prominently, Forth words write their > >>> substitutions to the time domain instead of into a file stream. > >> > >> You've lost me completely now. > > > > Do my comments about flattening leaf calls help? > > I'm sorry, no. Quite the reverse. > > -- > Alex In the example I gave above, pretty much every symbol that appeared in my definition of the word "UDS*" is probably a leaf. That is, the characteristic of each symbol is machine code. 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. DUP, for instance, is likely a read from top of stack into a temporary register and an allocating write back to the stack. That's one to three machine language instructions. Flattening, or in-lining, the code is very similar to what macros do. We would not lose meaning by calling it macro-substitution, although we usually call it in-lining or flattening. If the code is not in-lined, we would call it an i-code (or even just function) call to code stored elsewhere. This is only "macro" if we are considering the time domain as a medium to write into. It is not meaningless to consider a function call as a temporal substitution of semantic for symbol, but usually we make a distinction. The reason for the distinction is in the (minimal in the case of Forth) time consumed by the call, and in the amount of storage saved when the code doesn't have to be repeated everywhere it is referred to. This is the distinction I'm making. You may wonder why I acknowledge CAD macros. That is explicitly temporal domain stuff. Lisp is mathematics, and implicitly temporal. It straddles the boundary line I am pointing out in much the same manner as Forth does, but the focus is on the symbols. In the Forth community, we are more focused on the semantics than on the symbols. We lose something when we forget that. -- Joel Rees Randomly ranting: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-19 07:10 +0200 |
| Message-ID | <86tw4hig8s.fsf@molnjunk.nocrew.org> |
| In reply to | #59523 |
Joel Rees wrote: > Are you familiar with the concept of an i-code (as we used to call > them before the Java community implicitly made byte-code an improper > synonym for i-code)? I'm not. And Google wasn't helpful on this.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-19 07:42 -0500 |
| Message-ID | <toqdnWdfX5KydYPEnZ2dnUU7-LHNnZ2d@supernews.com> |
| In reply to | #59528 |
Lars Brinkhoff <lars.spam@nocrew.org> wrote: > Joel Rees wrote: >> Are you familiar with the concept of an i-code (as we used to call >> them before the Java community implicitly made byte-code an improper >> synonym for i-code)? > > I'm not. And Google wasn't helpful on this. I don't believe it . I think the term "bytecode" used by Java comes from Smalltalk-76; it was certainly in use by the time of Smalltalk- 80. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-05-19 09:59 +0200 |
| Message-ID | <1ocjggpqdz7mf$.dfo3ca3j0wjm.dlg@40tude.net> |
| In reply to | #59523 |
Op Thu, 18 May 2017 19:49:09 -0700 (PDT) schreef Joel Rees: > Here's something from a project I've been spinning my wheels on: > > ----------------- > ( This probably isn't really a good idea. Much better to just implement UMD* in assembler. ) > ( AL AH B --- QL QML QMH : unsigned double by unsigned single yielding three-cell unsigned ) >: UDS* ( ud u --- uhq ) > DUP >R SWAP >R > ( AL B ) UM* > 0 ( ready to sum into ) > R> R> > ( AH B ) UM* > D+ > ; > ----------------- Using more words from the core extension word set: : uds* tuck 2>r um* 0 2r> um* d+ ; groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-19 18:48 -0700 |
| Message-ID | <caebc6f5-70cf-457a-b276-d394320ae219@googlegroups.com> |
| In reply to | #59537 |
On Friday, May 19, 2017 at 4:59:48 PM UTC+9, Coos Haak wrote: > Op Thu, 18 May 2017 19:49:09 -0700 (PDT) schreef Joel Rees: > > > Here's something from a project I've been spinning my wheels on: > > > > ----------------- > > ( This probably isn't really a good idea. Much better to just implement UMD* in assembler. ) > > ( AL AH B --- QL QML QMH : unsigned double by unsigned single yielding three-cell unsigned ) > >: UDS* ( ud u --- uhq ) > > DUP >R SWAP >R > > ( AL B ) UM* > > 0 ( ready to sum into ) > > R> R> > > ( AH B ) UM* > > D+ > > ; > > ----------------- > Using more words from the core extension word set: > > : uds* tuck 2>r um* 0 2r> um* d+ ; > > groet Coos Thank you. I should have mentioned that there were reasons for the baroque usages. It was not intended to be exemplary of anything but the concept that I was trying to demonstrate, that considering Forth as a macro factory may be interesting, but might also be misleading. Clearly, my original attempt to say that was not well worded, since it got Alex sidetracked into an attempt to convince me that Forth does have its "macro-esque" nature. (At least, I guess that was what that was all about.) -- Joel Rees Rantomly randing: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-19 12:40 +0100 |
| Message-ID | <ofmlcd$kj1$1@dont-email.me> |
| In reply to | #59523 |
On 5/19/2017 03:49, Joel Rees wrote: > On Friday, May 19, 2017 at 5:15:18 AM UTC+9, Alex wrote: >> On 5/18/2017 17:18, Joel Rees wrote: >>> On Thursday, May 18, 2017 at 10:51:31 PM UTC+9, Alex wrote: >>>> On 5/18/2017 13:15, Joel Rees wrote: >>>>> On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: >>>>>> On 5/18/2017 03:17, Joel Rees wrote: >>>>>>> On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex >>>>>>> wrote: >> >>> >>> An optimizing Forth compiler does flatten leaf calls, and that >>> looks like substitution (and is), but the paradigm is a call >>> paradigm, not a substitution paradigm. >>> >>> Otherwise, we'd have no need for the inner interpreter, and our >>> program objects would lose their compactness. >> >> I get "is a call paradigm, not a substitution paradigm" but beyond >> that you've lost me again. > > Interesting. > > Are you familiar with an inner interpreter? Not just the concept, > but an actual inner interpreter? Yes. Forgive me, I'm beginning to think you might not be. > > Are you familiar with the Forth symbol table? You mean dictionary. I see a pattern of using terms from other religions that might cause confusion here. > > Are you familiar with the concept of an i-code (as we used to call > them before the Java community implicitly made byte-code an improper > synonym for i-code)? No. P-code, but not i-code. I've never heard of it. > >>>>>>> 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" >>>>> >>>>> What is text? What is substitution? >>>>> >>>>> What is macro substitution? >>>>> >>>>> What is the language m4? >>>>> >>>>> What is a C preprocessor? >>>> >>>> Great questions. What problem are you addressing that Forth >>>> not having "text macros" is an issue? You might want to >>>> consider my first answer above on interpreting/compiling. >>> >>> Who said I was addressing a problem. >>> >>> Someone said Forth could be called a macro factory or something >>> like that, and I thought it worth the trouble to try to point out >>> that routine call and code substitution are two rather different >>> approaches to interpreting the symbols of a program language. >> >> Again, I don't know what you mean here. An example might help. > > Here's something from a project I've been spinning my wheels on: > > ----------------- ( This probably isn't really a good idea. Much > better to just implement UMD* in assembler. ) ( AL AH B --- QL QML > QMH : unsigned double by unsigned single yielding three-cell unsigned > ) : UDS* ( ud u --- uhq ) DUP >R SWAP >R ( AL B ) UM* 0 ( ready to > sum into ) R> R> ( AH B ) UM* D+ ; ----------------- > > The above is not a macro. Thank you, yes, I can see that. > > Now, if you consider the time domain to be a medium, and semantics > to be symbols, then we can say we don't need to make a distinction. > > And semantics are, in fact, symbolic. > > And the time domain is, in fact, a medium for writing behavior into. > > For us mortals, it helps to make a distinction between symbolic > behavior and non-symbolic behavior. Otherwise, we don't know when to > stop talking and start doing. > > I'm sure that doesn't help. How true. Gnosticism was never my bag. > Back to the example I just gave you. > > That's a list of instructions. > > Conceptually, a Forth compiler is going to string that together as a > series of calls to code. > > Many modern Forths can in-line that, but let's set that aside for a > moment. In-lining is not a fundamental characteristic of Forth > interpreters. It's a relatively advanced mode of operation. It's not advanced. It's also not relevant to the discussion. > >>>>>> For example: >>>>>> >>>>>> : generate-mov-eax-1 also assembler mov eax 1 previous ; >>>>>> >>>>>> -- Alex >>>>> >>>>> And that looks something like an assembler macro. >>>>> >>>>> But that is not a typical Forth word, either. >>>> >>>> What's typical? (This is a serious question, since I can't see >>>> the point you're trying to make here at all.) >>> >>> Well, I don't imagine that a typical application written in Forth >>> has a lot of words which directly invoke the assembler for the >>> target CPU, at any rate. >>> >>> Maybe I'm wrong and the target CPU is one of the reasons a lot >>> of Forth Applications are not portable. >> >> It was an example of your case of "inline assembley macro", hence >> it used assembler (which is usually not portable). It doesn't >> indicate a fundamental lack of portability in Forth. > > If this is to be used in assembly level source code, it would be an > example of a macro that you have defined in your Forth. > > Elsewhere, it might be more descriptive to call it an in-line call. No, it isn't an in-line call. > > It is fundamentally different from the example I presented above. To the Forth system, it's identical. > > (Unless your Forth is really aggressive about in-lining, but let's > not get distracted yet.) > > (Oh, and unless you like to consider time as paper to write on, but > let's ignore that question entirely.) I think you're slightly off as to what Forth does with words (& let's ignore numbers for the moment). Forth (the outer interpreter) makes no distinction about what it does when it sees a word (or token if you prefer). It looks the word up in a dictionary (a type of symbol table) and if it finds it, gets back two pieces of information; an execution token (XT) and an immediate flag. It does one of two things, based on a state variable and the immediate flag. If the state is "interpretation state" or the immediate flag is true, it executes the XT immediately. Otherwise, it compiles a call to the XT. What is meant by compilation is part of the nature of the Forth; ITC, DTC, STC or a native code system do different things. At root, they build something that can be executed. That's it. There's no semantic interpretation of the XT by the outer interpreter. The inner interpreter (it's badly named tbf) runs through the compiled code and "executes" it. Threaded systems use fairly simple (and hopefully fast) mechanisms; native code systems use call/return or inlining, or a mixture of the two, where the inner interpreter has become like Banquo's ghost in Hamlet; it's annoyingly present as an idea but it doesn't exist. Again, that's it. > >>>>> Some people note that function or subroutine calls behave in >>>>> a way similar to macro invocation, but there are fundamental >>>>> differences. Most prominently, Forth words write their >>>>> substitutions to the time domain instead of into a file >>>>> stream. >>>> >>>> You've lost me completely now. >>> >>> Do my comments about flattening leaf calls help? >> >> I'm sorry, no. Quite the reverse. >> >> -- Alex > > In the example I gave above, pretty much every symbol that appeared > in my definition of the word "UDS*" is probably a leaf. That is, the > characteristic of each symbol is machine code. Leaf implies some kind of tree structure. The definition of UDS* ends up as is either (a) an array of XTs of other definitions (that's compiled code in a threaded system) or a chunk of code (in a native code compiler). We could talk about leaves, or trees, or other concepts, but we generally don't do so. > > 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 > > DUP, for instance, is likely a read from top of stack into a > temporary register and an allocating write back to the stack. That's > one to three machine language instructions. > > Flattening, or in-lining, the code is very similar to what macros > do. We would not lose meaning by calling it macro-substitution, > although we usually call it in-lining or flattening. Flattening? Neither it nor inlining has anything to do with what I was trying to demonstrate with the example, and I'm sorry if it has only served to confuse you. > > If the code is not in-lined, we would call it an i-code (or even > just function) call to code stored elsewhere. This is only "macro" if > we are considering the time domain as a medium to write into. > > It is not meaningless to consider a function call as a temporal > substitution of semantic for symbol, but usually we make a > distinction. > > The reason for the distinction is in the (minimal in the case of > Forth) time consumed by the call, and in the amount of storage saved > when the code doesn't have to be repeated everywhere it is referred > to. > > This is the distinction I'm making. You need to get the Forth basics first. There's a lot of confusion here, especially with ideas and terminology. Perhaps my example wasn't the best for this kind of discussion. > > You may wonder why I acknowledge CAD macros. That is explicitly > temporal domain stuff. > > Lisp is mathematics, and implicitly temporal. It straddles the > boundary line I am pointing out in much the same manner as Forth > does, but the focus is on the symbols. > > In the Forth community, we are more focused on the semantics than on > the symbols. We lose something when we forget that. We? OK, since it's philosophy week here on clf, let me have a go. This is, as is usual on the intertubes, my humble opinion etc. The we is me. Forthers (I count myself as one) are at heart reductionists. Simplicity is valued above all else, and the ability to reduce to the elements of programming considered one of the key aspects of the language; and one of the key attributes of Forth programs (and programmers). Forthers are perpetually surprised with systems and constructs (and the people that propose them) that are to be treated holistically, trusted, praised and almost worshipped, and never analysed or decomposed into parts. Much of the terminology of programming in the temple of High Level Languages -- templates; macros; objects; currying; lambdas; a whole bestiary of ideas -- are treated as byzantine gnosticism layered on what is just a simple substrate. We exist not to admire other's creations, or to paint descriptions of how to employ them, or to write poetry on the internet about them. These are the actions of worshippers to false gods and idols. (We don't even treat the first prophets of our religion that well either.) We want to use our tools and atom smashers and say -- look, it's just stuff. This is all that it is. Neutrons, protons, that make up the screws, brackets, wires. Here are the simple parts that have been used to assemble your creation. Macros? Ah, you classify them differently, because in your language your symbols write their substitutions into a file stream as opposed to the time domain. That's high-church impenetrable priesthood stuff, good for talking about C. But I wonder, what do they look like when I hit them with my Forth hammer? Anyhow. As you said earlier, I'm sure this doesn't help. Back to the discussion. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-19 20:57 -0700 |
| Message-ID | <7297c009-1ffb-4280-ba2b-29361751b40e@googlegroups.com> |
| In reply to | #59544 |
On Friday, May 19, 2017 at 8:40:11 PM UTC+9, Alex wrote: > On 5/19/2017 03:49, Joel Rees wrote: > > On Friday, May 19, 2017 at 5:15:18 AM UTC+9, Alex wrote: > >> On 5/18/2017 17:18, Joel Rees wrote: > >>> On Thursday, May 18, 2017 at 10:51:31 PM UTC+9, Alex wrote: > >>>> On 5/18/2017 13:15, Joel Rees wrote: > >>>>> On Thursday, May 18, 2017 at 6:51:46 PM UTC+9, Alex wrote: > >>>>>> On 5/18/2017 03:17, Joel Rees wrote: > >>>>>>> On Thursday, May 18, 2017 at 4:41:30 AM UTC+9, Alex > >>>>>>> wrote: > > >> > >>> > >>> An optimizing Forth compiler does flatten leaf calls, and that > >>> looks like substitution (and is), but the paradigm is a call > >>> paradigm, not a substitution paradigm. > >>> > >>> Otherwise, we'd have no need for the inner interpreter, and our > >>> program objects would lose their compactness. > >> > >> I get "is a call paradigm, not a substitution paradigm" but beyond > >> that you've lost me again. > > > > Interesting. > > > > Are you familiar with an inner interpreter? Not just the concept, > > but an actual inner interpreter? > > Yes. Forgive me, I'm beginning to think you might not be. Not as familiar as you, I guess. Sorry for being pedantic. I wanted to found out if we were talking past each other. > > Are you familiar with the Forth symbol table? > > You mean dictionary. I see a pattern of using terms from other religions > that might cause confusion here. I mean symbol table. A Forth dictionary is a symbol table. If I say dictionary and it has to mean a Forth interpreter's symbol table, how are we going to discuss other kinds of dictionaries? > > Are you familiar with the concept of an i-code (as we used to call > > them before the Java community implicitly made byte-code an improper > > synonym for i-code)? > > No. P-code, but not i-code. I've never heard of it. P-code was Pascal's i-code. Then some wise guy thought it was short for tokenized pseudo-code, and started using it as a synonym for i-code. Somewhere in there, bytecodes became the new p-codes and now some people seem to think a list of 64-bit function pointers is just another kind of bytecode. Maybe they are right, in their context. > >>>>>>> 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" > >>>>> > >>>>> What is text? What is substitution? > >>>>> > >>>>> What is macro substitution? > >>>>> > >>>>> What is the language m4? > >>>>> > >>>>> What is a C preprocessor? > >>>> > >>>> Great questions. What problem are you addressing that Forth > >>>> not having "text macros" is an issue? You might want to > >>>> consider my first answer above on interpreting/compiling. > >>> > >>> Who said I was addressing a problem. > >>> > >>> Someone said Forth could be called a macro factory or something > >>> like that, and I thought it worth the trouble to try to point out > >>> that routine call and code substitution are two rather different > >>> approaches to interpreting the symbols of a program language. > >> > >> Again, I don't know what you mean here. An example might help. > > > > Here's something from a project I've been spinning my wheels on: > > > > ----------------- ( This probably isn't really a good idea. Much > > better to just implement UMD* in assembler. ) ( AL AH B --- QL QML > > QMH : unsigned double by unsigned single yielding three-cell unsigned > > ) : UDS* ( ud u --- uhq ) DUP >R SWAP >R ( AL B ) UM* 0 ( ready to > > sum into ) R> R> ( AH B ) UM* D+ ; ----------------- > > > > The above is not a macro. > > Thank you, yes, I can see that. Again, apologies for being pedantic. > > Now, if you consider the time domain to be a medium, and semantics > > to be symbols, then we can say we don't need to make a distinction. > > > > And semantics are, in fact, symbolic. > > > > And the time domain is, in fact, a medium for writing behavior into. > > > > For us mortals, it helps to make a distinction between symbolic > > behavior and non-symbolic behavior. Otherwise, we don't know when to > > stop talking and start doing. > > > > I'm sure that doesn't help. > > How true. Gnosticism was never my bag. You don't have to be gnostic to talk about time as a medium for information. > > Back to the example I just gave you. > > > > That's a list of instructions. > > > > Conceptually, a Forth compiler is going to string that together as a > > series of calls to code. > > > > Many modern Forths can in-line that, but let's set that aside for a > > moment. In-lining is not a fundamental characteristic of Forth > > interpreters. It's a relatively advanced mode of operation. > > It's not advanced. It's also not relevant to the discussion. For you, I suppose it is not advanced. To me, it was relevant, because, relative to the uses I tend to see for the word "macro", substituting the machine code definition for the interpreter's numerical token which represents the machine code definition is the same kind of substitution as certain kinds of macro expansion performed by a macro assembler. > >>>>>> For example: > >>>>>> > >>>>>> : generate-mov-eax-1 also assembler mov eax 1 previous ; > >>>>>> > >>>>>> -- Alex > >>>>> > >>>>> And that looks something like an assembler macro. > >>>>> > >>>>> But that is not a typical Forth word, either. > >>>> > >>>> What's typical? (This is a serious question, since I can't see > >>>> the point you're trying to make here at all.) > >>> > >>> Well, I don't imagine that a typical application written in Forth > >>> has a lot of words which directly invoke the assembler for the > >>> target CPU, at any rate. > >>> > >>> Maybe I'm wrong and the target CPU is one of the reasons a lot > >>> of Forth Applications are not portable. > >> > >> It was an example of your case of "inline assembley macro", hence > >> it used assembler (which is usually not portable). It doesn't > >> indicate a fundamental lack of portability in Forth. > > > > If this is to be used in assembly level source code, it would be an > > example of a macro that you have defined in your Forth. > > > > Elsewhere, it might be more descriptive to call it an in-line call. > > No, it isn't an in-line call. So it's part of an assembler? I can't tell without reference to the rest of the code. I assume you think "also" and "previous" should tell me something, but they don't. > > It is fundamentally different from the example I presented above. > > To the Forth system, it's identical. To your Forth system, maybe so. I don't have your Forth system in front of me. To the human looking at it, unless I am completely misunderstanding what your generate-mov-eax-1 is supposed to do, there is a fundamental difference in purpose. (Since you seem to be allergic to the word, "semantic" here, I guess I'll talk about purpose.) > > (Unless your Forth is really aggressive about in-lining, but let's > > not get distracted yet.) > > > > (Oh, and unless you like to consider time as paper to write on, but > > let's ignore that question entirely.) > > I think you're slightly off as to what Forth does with words (& let's > ignore numbers for the moment). Okay, now it's your turn to be pedantic. > Forth (the outer interpreter) makes no distinction about what it does > when it sees a word (or token if you prefer). It looks the word up in a > dictionary (a type of symbol table) and if it finds it, gets back two > pieces of information; an execution token (XT) and an immediate flag. > > It does one of two things, based on a state variable and the immediate flag. I thought you said it makes no distinction. And, if I really don't know what a Forth interpreter does, why should I have any idea what the immediate flag is, or even means? Sorry. I'll shut up and let you establish your context. > If the state is "interpretation state" or the immediate flag is true, it > executes the XT immediately. > > Otherwise, it compiles a call to the XT. What is meant by compilation is > part of the nature of the Forth; ITC, DTC, STC or a native code system > do different things. At root, they build something that can be executed. You know, it was an interesting thing to discover, by counting cycles, that indirect threading is generally no less efficient in terms of CPU cycle cost than direct threading or subroutine threading. > That's it. There's no semantic interpretation of the XT by the outer > interpreter. That's a very narrow definition of the outer interpreter. But not an invalid definition. But, yeah, if you ignore side-effects, the whole discussion of what a macro is becomes, well, really hard to find meaning in. > The inner interpreter (it's badly named tbf) Okay, I have called the inner interpreter the virtual CPU, but that expression also has certain limits. I also tend to call it the run-time architecture, but that expression tends to cause eyes to glaze over. What would you prefer to call it? > runs through the compiled > code and "executes" it. Threaded systems use fairly simple (and > hopefully fast) mechanisms; native code systems use call/return or > inlining, or a mixture of the two, where the inner interpreter has > become like Banquo's ghost in Hamlet; it's annoyingly present as an idea > but it doesn't exist. Ghost-like. Amusing analogy. > Again, that's it. > > > > >>>>> Some people note that function or subroutine calls behave in > >>>>> a way similar to macro invocation, but there are fundamental > >>>>> differences. Most prominently, Forth words write their > >>>>> substitutions to the time domain instead of into a file > >>>>> stream. > >>>> > >>>> You've lost me completely now. > >>> > >>> Do my comments about flattening leaf calls help? > >> > >> I'm sorry, no. Quite the reverse. > >> > >> -- Alex > > > > In the example I gave above, pretty much every symbol that appeared > > in my definition of the word "UDS*" is probably a leaf. That is, the > > characteristic of each symbol is machine code. > > Leaf implies some kind of tree structure. Yeah. > The definition of UDS* ends up > as is either (a) an array of XTs of other definitions (that's compiled > code in a threaded system) or a chunk of code (in a native code > compiler). Or a mix, if your CPU is designed to mix XTs and machine code. > We could talk about leaves, or trees, or other concepts, but > we generally don't do so. I'm not sure why. > > 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 > > > DUP, for instance, is likely a read from top of stack into a > > temporary register and an allocating write back to the stack. That's > > one to three machine language instructions. > > > Flattening, or in-lining, the code is very similar to what macros > > do. We would not lose meaning by calling it macro-substitution, > > although we usually call it in-lining or flattening. > > Flattening? Neither it nor inlining has anything to do with what I was > trying to demonstrate with the example, and I'm sorry if it has only > served to confuse you. Do you make a distinction between flattening and in-lining? And I'm not really sure that I'm confused. I am sure that we have been talking past each other. (Probably still are.) > > If the code is not in-lined, we would call it an i-code (or even > > just function) call to code stored elsewhere. This is only "macro" if > > we are considering the time domain as a medium to write into. > > > > It is not meaningless to consider a function call as a temporal > > substitution of semantic for symbol, but usually we make a > > distinction. > > > > The reason for the distinction is in the (minimal in the case of > > Forth) time consumed by the call, and in the amount of storage saved > > when the code doesn't have to be repeated everywhere it is referred > > to. > > > > This is the distinction I'm making. > > You need to get the Forth basics first. There's a lot of confusion here, > especially with ideas and terminology. Perhaps my example wasn't the > best for this kind of discussion. What exactly does generate-mov-eax-1 do? Interpreting it naively, I would guess that it writes a bit of machine code, or a proxy token for a bit of machine code, into the Forth dictionary. (If you can stand for me to say it this way, it looks like it adds said code or proxy into the semantic field of a symbol table entry. But, yeah, that expression is less meaningful in this context. Doesn't leave a good taste in the mouth, either.) > > You may wonder why I acknowledge CAD macros. That is explicitly > > temporal domain stuff. > > > > Lisp is mathematics, and implicitly temporal. It straddles the > > boundary line I am pointing out in much the same manner as Forth > > does, but the focus is on the symbols. > > > > In the Forth community, we are more focused on the semantics than on > > the symbols. We lose something when we forget that. > > We? OK, since it's philosophy week here on clf, let me have a go. This > is, as is usual on the intertubes, my humble opinion etc. The we is me. > > Forthers (I count myself as one) are at heart reductionists. Simplicity > is valued above all else, and the ability to reduce to the elements of > programming considered one of the key aspects of the language; and one > of the key attributes of Forth programs (and programmers). What is simplicity, other than an optimization? > Forthers are perpetually surprised with systems and constructs (and the > people that propose them) that are to be treated holistically, trusted, > praised and almost worshipped, and never analysed or decomposed into > parts. Much of the terminology of programming in the temple of High > Level Languages -- templates; macros; objects; currying; lambdas; a > whole bestiary of ideas -- are treated as byzantine gnosticism layered > on what is just a simple substrate. In which case, what do we care for macros? (Not sure why you invoke gnosticism here. Or ancient middle-eastern empires in lower-case.) > We exist not to admire other's creations, or to paint descriptions of > how to employ them, or to write poetry on the internet about them. These > are the actions of worshippers to false gods and idols. (We don't even > treat the first prophets of our religion that well either.) The construction of that paragraph sounded ironic, but I guess you are attempting to describe your utilitarian ideal of the Forth community. > We want to use our tools and atom smashers and say -- look, it's just > stuff. This is all that it is. Neutrons, protons, that make up the > screws, brackets, wires. Here are the simple parts that have been used > to assemble your creation. Still waxing poetic? Rock and roll lyrics is just another kind of poetry. > Macros? Ah, you classify them differently, because in your language your > symbols write their substitutions into a file stream as opposed to the > time domain. Symbolic substitution is one way of looking at the operation of a Forth system, both compiling and interpreting. Macro-substitution is a proper subset of symbolic substitution. > That's high-church impenetrable priesthood stuff, good for > talking about C. But I wonder, what do they look like when I hit them > with my Forth hammer? I was trying to help you not to miss this nail, I think. So to speak. > Anyhow. As you said earlier, I'm sure this doesn't help. Back to the > discussion. > > -- > Alex Well, pardon me for butting in. -- Joel Rees Trying to reinvent the industry all by myself: http://defining-computers.blogspot.com/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-20 03:42 -0500 |
| Message-ID | <jf-dnSbkT9rlnL3EnZ2dnUU7-e_NnZ2d@supernews.com> |
| In reply to | #59573 |
Joel Rees <joel.rees@gmail.com> wrote: > On Friday, May 19, 2017 at 8:40:11 PM UTC+9, Alex wrote: >> >> You mean dictionary. I see a pattern of using terms from other religions >> that might cause confusion here. > > I mean symbol table. > > A Forth dictionary is a symbol table. > > If I say dictionary and it has to mean a Forth interpreter's symbol > table, how are we going to discuss other kinds of dictionaries? From context. This is c.l.f, and Forth has its terms of art. You can't reasonably expect to come here and use terms from Language X, and you certainly can't expect to ask someone using Forth terms whether they are familiar with your idiosyncratic usage. The Forth dictionary does not just contain symbols. It is therefore more than a symbol table. > What exactly does generate-mov-eax-1 do? > > Interpreting it naively, I would guess that it writes a bit of > machine code, or a proxy token for a bit of machine code, into the > Forth dictionary. It writes machine code into the dictionary. >> Forthers (I count myself as one) are at heart reductionists. Simplicity >> is valued above all else, and the ability to reduce to the elements of >> programming considered one of the key aspects of the language; and one >> of the key attributes of Forth programs (and programmers). > > What is simplicity, other than an optimization? What is beauty, other than an optimization? Well, it is philosophy week... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-20 02:00 -0700 |
| Message-ID | <9d921832-23a4-4cc3-be71-0368cc92037a@googlegroups.com> |
| In reply to | #59578 |
On Saturday, May 20, 2017 at 5:42:38 PM UTC+9, Andrew Haley wrote: > Joel Rees <joel.rees@somewhere> wrote: > > On Friday, May 19, 2017 at 8:40:11 PM UTC+9, Alex wrote: > >> > >> You mean dictionary. I see a pattern of using terms from other religions > >> that might cause confusion here. > > > > I mean symbol table. > > > > A Forth dictionary is a symbol table. > > > > If I say dictionary and it has to mean a Forth interpreter's symbol > > table, how are we going to discuss other kinds of dictionaries? > > From context. This is c.l.f, and Forth has its terms of art. You > can't reasonably expect to come here and use terms from Language X, > and you certainly can't expect to ask someone using Forth terms > whether they are familiar with your idiosyncratic usage. > > The Forth dictionary does not just contain symbols. It is therefore > more than a symbol table. In the same vein, Forth is more than a macro factory. > > What exactly does generate-mov-eax-1 do? > > > > Interpreting it naively, I would guess that it writes a bit of > > machine code, or a proxy token for a bit of machine code, into the > > Forth dictionary. > > It writes machine code into the dictionary. Which can, as I thought you or somebody wanted to point out, be viewed as a macro-like behavior. As opposed to the three-quarters division word which I was fretting over last week, which is more of a function (but not like functional program functions, if I understand those correctly). Although, if one is thinking of spreadsheet macros, ..., But it is useful to recognize the locus of the effects as being different. One works on the stack, and one works on one of the tapes. And I was just trying to point at the difference, and maybe I didn't do a very good job of it, and maybe it wasn't necessary anyway. Oh, well. > >> Forthers (I count myself as one) are at heart reductionists. Simplicity > >> is valued above all else, and the ability to reduce to the elements of > >> programming considered one of the key aspects of the language; and one > >> of the key attributes of Forth programs (and programmers). > > > > What is simplicity, other than an optimization? > > What is beauty, other than an optimization? Well, it is philosophy > week... > > Andrew. When you live in Japan, beauty and simplicity seem to take on new meanings. But let's leave that one for another time. -- Joel Rees Delusions of being a novel: http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-20 10:15 +0100 |
| Message-ID | <ofp19b$u4f$1@dont-email.me> |
| In reply to | #59573 |
On 5/20/2017 04:57, Joel Rees wrote:
> On Friday, May 19, 2017 at 8:40:11 PM UTC+9, Alex wrote:
[heavily snipped]
>
> I mean symbol table.
>
> A Forth dictionary is a symbol table.
>
> If I say dictionary and it has to mean a Forth interpreter's symbol
> table, how are we going to discuss other kinds of dictionaries?
>
The terminology is important, and here (clf) using the word dictionary
will generally be understood in its Forth context.
dictionary:
An extensible structure that contains definitions and associated
data space.
word:
Depending on context, either 1) the name of a Forth definition; or
2) a parsed sequence of non-space characters, which could be the name of
a Forth definition.
word list:
A list of associated Forth definition names that may be examined
during a dictionary search.
>
>> We could talk about leaves, or trees, or other concepts, but
>> we generally don't do so.
>
> I'm not sure why.
Because Forth doesn't demand any kind of structure to the code. In
compiler terms, there's no abstract syntax tree (AST), since everything
can be compiled immediately when it's tokenized.
Optimizing compilers delay code generation by building internal
structures and only compiling when needed, i.e. on EXECUTE, or peephole
optimizing. But that's not part of the feature of the language, and the
end effect is the same; everything looks & can be treated like it's
compiled now.
>
>>> 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 >
>>> DUP, for instance, is likely a read from top of stack into a
>>> temporary register and an allocating write back to the stack. That's
>>> one to three machine language instructions. >
>>> Flattening, or in-lining, the code is very similar to what macros
>>> do. We would not lose meaning by calling it macro-substitution,
>>> although we usually call it in-lining or flattening.
>>
>> Flattening? Neither it nor inlining has anything to do with what I was
>> trying to demonstrate with the example, and I'm sorry if it has only
>> served to confuse you.
>
> Do you make a distinction between flattening and in-lining?
>
> And I'm not really sure that I'm confused.
>
> I am sure that we have been talking past each other. (Probably still are.)
Possibly. But what you are describing is not a feature of the language.
>
> What exactly does generate-mov-eax-1 do?
>
> Interpreting it naively, I would guess that it writes a bit of
> machine code, or a proxy token for a bit of machine code, into the
> Forth dictionary.
>
> (If you can stand for me to say it this way, it looks like it adds
> said code or proxy into the semantic field of a symbol table entry.
> But, yeah, that expression is less meaningful in this context.
> Doesn't leave a good taste in the mouth, either.)
>
It was a very bad example. Before explaining it, let me try this example
(which is just for pedagogical purposes).
: [n]@ ( a n -- r ) ( given an index into an array, fetch the entry)
cells + @ ;
Now we can use [N]@ as in
create arr 100 cells allot ( allocate 100 cell array )
: foo arr 40 [n]@ ; ( fetch the 41st entry )
What is being executed by FOO is this stream;
push arr
push 40
call index
call cells
push 4
call *
return
call +
call @
return
return
It's a very expensive way of returning a constant. We can make run-time
a lot faster by doing the leg work at compile time:
: foo [ arr 40 cells + ] literal @ ;
The [ ] indicates "switch to interpreting" and "switch to compiling".
LITERAL compiles what it sees on the stack (the number that represents
the address).
push <addr of arr 40 cells +>
call @
return
If we use a lot of references to the 41st entry, it gets a bit tedious
seeing [ arr 40 cells + ] literal all the time just to get some
performance, so;
: arr[40]@ arr 40 cells + postpone literal postpone @ ; immediate
Now when we write
: foo arr[40]@ ;
the word ARR[40]@ is executed while we're compiling FOO, becuase it's
been marked as IMMEDIATE. POSTPONE delays the compilation of the
following word until ARR[40]@ is executed. That generates this;
push <addr of arr 40 cells +>
call @
return
A macro, albeit one without parameters. Now let's parameterise it.
: array@ ( a n -- ) swap cells + postpone literal postpone @ ; immediate
: foo [ arr 36 ] array@ [ arr 40 ] array@ + ;
and so on.
These macros do have one downside; they're not executable at the
console, since they generate code. But that too is fixable.
>
>> Anyhow. As you said earlier, I'm sure this doesn't help. Back to the
>> discussion.
>
> Well, pardon me for butting in.
No, our discussion. I'm not suggesting you butted in.
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-20 13:34 +0100 |
| Message-ID | <ofpcua$vq9$2@dont-email.me> |
| In reply to | #59583 |
On 5/20/2017 10:15, Alex wrote: > : array@ ( a n -- ) swap cells + postpone literal postpone @ ; immediate Should have read : array@ ( a n -- ) cells + postpone literal postpone @ ; immediate -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-20 02:01 -0700 |
| Message-ID | <85ed817f-f9d3-426e-8762-efb101ebc08f@googlegroups.com> |
| In reply to | #59544 |
On Friday, May 19, 2017 at 4:40:11 AM UTC-7, Alex wrote: > You need to get the Forth basics first. There's a lot of confusion here, > especially with ideas and terminology. Alex McDonald is a troll. He tells people that they don't "get the Forth basics" --- he wants to be a teacher. This reminds me of John Passaniti describing how, if at a job he were given the task of mentoring me, he would first order me to discard all that crap in the novice-package and focus on learning Forth basics --- he wants to be a teacher. And, of course, we have Elizabeth Rather and her employee Andrew Haley --- they taught the novice class at Forth Inc. and taught PAD as the standard way to store strings --- they want to be teachers. > Forthers (I count myself as one) are at heart reductionists. Simplicity > is valued above all else, and the ability to reduce to the elements of > programming considered one of the key aspects of the language; and one > of the key attributes of Forth programs (and programmers). > > Forthers are perpetually surprised with systems and constructs (and the > people that propose them) that are to be treated holistically, trusted, > praised and almost worshipped, and never analysed or decomposed into > parts. Much of the terminology of programming in the temple of High > Level Languages -- templates; macros; objects; currying; lambdas; a > whole bestiary of ideas -- are treated as byzantine gnosticism layered > on what is just a simple substrate. > > We exist not to admire other's creations, or to paint descriptions of > how to employ them, or to write poetry on the internet about them. These > are the actions of worshippers to false gods and idols. (We don't even > treat the first prophets of our religion that well either.) > > We want to use our tools and atom smashers and say -- look, it's just > stuff. This is all that it is. Neutrons, protons, that make up the > screws, brackets, wires. Here are the simple parts that have been used > to assemble your creation. > > Macros? Ah, you classify them differently, because in your language your > symbols write their substitutions into a file stream as opposed to the > time domain. That's high-church impenetrable priesthood stuff, good for > talking about C. But I wonder, what do they look like when I hit them > with my Forth hammer? > > Anyhow. As you said earlier, I'm sure this doesn't help. This thread has predictably devolved into long-winded pseudo-intellectual blather from Alex McDonald. Ironically, the title of the thread is: "comp.lang.forth is THE PROBLEM"
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-20 13:18 +0100 |
| Message-ID | <ofpc16$vq9$1@dont-email.me> |
| In reply to | #59581 |
On 5/20/2017 10:01, hughaguilar96@gmail.com wrote: > On Friday, May 19, 2017 at 4:40:11 AM UTC-7, Alex wrote: >> You need to get the Forth basics first. There's a lot of confusion >> here, especially with ideas and terminology. > Alex McDonald is a troll. He tells people that they don't "get the > Forth basics" --- he wants to be a teacher. > > This reminds me of John Passaniti describing how, if at a job he were > given the task of mentoring me, he would first order me to discard > all that crap in the novice-package and focus on learning Forth > basics --- he wants to be a teacher. > > And, of course, we have Elizabeth Rather and her employee Andrew > Haley --- they taught the novice class at Forth Inc. and taught PAD > as the standard way to store strings --- they want to be teachers. > What do you want to be? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-19 17:06 +0200 |
| Message-ID | <ofn1lq$8q9$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59523 |
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
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-19 08:31 -0700 |
| Message-ID | <01a94a8a-0f53-433b-b9df-9df638688e7c@googlegroups.com> |
| In reply to | #59551 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-19 17:02 +0100 |
| Message-ID | <ofn4oh$gsm$1@dont-email.me> |
| In reply to | #59553 |
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
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web