Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49278 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2016-07-21 07:09 -0700 |
| Last post | 2016-07-28 05:33 -0700 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 07:09 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-21 07:21 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 14:58 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 11:23 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 12:42 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 12:40 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:07 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:32 -0500
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-21 17:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:50 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:53 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:58 +0300
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:54 +0300
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:48 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 00:19 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 02:33 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 10:45 +0300
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 19:41 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:52 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:22 -0400
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:49 -0500
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:16 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:11 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:32 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:58 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-21 17:02 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:11 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 15:57 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-22 13:25 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 20:24 -0700
Re: Dictionary separated from code ... PROS and CONs stephen@mpeforth.com (Stephen Pelc) - 2016-07-22 11:32 +0000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 12:49 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 23:10 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:36 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:58 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 21:56 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:38 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 10:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 14:18 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:55 -1000
Re: Dictionary separated from code ... PROS and CONs "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 11:34 +0000
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:36 -0400
Re: Dictionary separated from code ... PROS and CONs Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-22 11:15 +0200
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:37 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:56 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-24 13:16 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 12:58 -0700
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-25 18:09 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 22:34 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-27 23:08 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 08:58 -1000
CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 09:17 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 00:19 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 14:54 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-07-28 10:00 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 21:47 +1000
Re: CREATE...DOES> etc. and flash Coos Haak <chforth@hccnet.nl> - 2016-07-29 15:04 +0200
Re: CREATE...DOES> etc. and flash "HAA" <someone@microsoft.com> - 2016-07-30 18:42 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 15:05 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 02:21 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-31 13:05 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 21:24 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-31 19:07 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:24 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:14 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-02 10:45 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 06:59 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 00:34 -0700
Re: CREATE...DOES> etc. and flash Coos Haak <htrofhc@gmail.com> - 2016-08-02 13:57 +0200
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 06:19 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 15:28 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:34 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 07:32 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-03 11:51 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 08:21 +0000
Re: CREATE...DOES> etc. and flash stephen@mpeforth.com (Stephen Pelc) - 2016-08-04 13:18 +0000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 14:02 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 12:26 -0500
Re: CREATE...DOES> etc. and flash Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:24 -0700
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 07:36 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:14 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:17 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-06 13:35 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:20 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:43 -0500
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 09:19 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 05:15 +0000
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 21:50 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 08:24 +0000
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 10:08 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 15:06 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-30 06:22 +0000
Re: CREATE...DOES> etc. and flash Paul Rubin <no.email@nospam.invalid> - 2016-07-30 01:07 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 01:30 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-30 10:17 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 00:51 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 05:20 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 13:06 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 08:13 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 14:08 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 15:24 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 20:12 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 17:36 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 21:54 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:03 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:00 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:19 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 20:40 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-23 22:23 +1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:48 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 16:04 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 19:31 -0400
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 17:20 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 17:54 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 21:27 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 19:18 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 22:25 -0400
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-24 20:39 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:32 -0700
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:30 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 21:36 -1000
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:46 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-25 09:19 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:35 -0400
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:32 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 17:48 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:09 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:43 -0400
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-23 06:58 +0000
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-23 04:02 -0500
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-23 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-23 10:48 -0700
Re: Dictionary separated from code ... PROS and CONs humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:53 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-23 11:24 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-24 03:33 -0500
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 08:16 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:28 -0500
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 11:59 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 07:36 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 10:44 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 11:36 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 11:53 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 12:47 -0700
Re: Dictionary separated from code ... PROS and CONs foxaudioresearch@gmail.com - 2016-07-27 13:27 -0700
Re: Dictionary separated from code ... PROS and CONs all2001@spambog.com (Wolfgang Allinger) - 2016-07-27 18:20 -0300
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-27 19:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 19:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-28 00:44 -0400
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:14 -0500
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 18:38 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 16:03 -0400
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:09 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:13 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 15:25 +0000
Re: Dictionary separated from code ... PROS and CONs Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:53 -0700
Re: Dictionary separated from code ... PROS and CONs JennyB <jennybrien@googlemail.com> - 2016-07-27 09:44 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 13:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:36 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 12:43 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:53 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:32 -0500
Re: Dictionary separated from code ... PROS and CONs Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-07-23 14:47 +0200
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 12:24 -1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 19:47 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-28 05:33 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-07-22 08:13 -0700 |
| Message-ID | <61422d41-99b4-48bf-91cd-a744684e5bf8@googlegroups.com> |
| In reply to | #49325 |
On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote: > Chris Curl <ccurl...@gmail.com> writes: > >So if I am understanding the discussion here, in many Forth implementations, > >the actual machine code is static (the system's primitives), and essentially > >everything else is data. > > That would be a classic threaded-code implementation. The current > mainstream is to have a native-code implementation, though, e.g., > SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with > --no-dynamic your description fits, but in the default configuration > it generates native code at run-time (unless there is some red flag > that turns this off). > > - anton Thanks for the clarification ... one last clarification please ... Since I am not doing something totally new and different, I might as use words that other implementations have used for the same sorts of operations. In a native code implementation, what do "," and "C," operate on ... the data or the code area? Hugh referred to a "COMPILE," word for adding to the code area, which implies that "," and "C," are used for the data/dictionary area ... is that pretty common, and if so, does it take 8, 16, 32, or 64 bit value? It almost feels like it would be clearer to have words like "CODE,", "CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup like that, "," and "C," would be shortcuts for one of the 3 different more specific words. Thanks
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-22 09:09 -1000 |
| Message-ID | <Jdydnbx7UKLr8g_KnZ2dnUU7-WXNnZ2d@supernews.com> |
| In reply to | #49328 |
On 7/22/16 5:13 AM, Chris Curl wrote: > On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote: >> Chris Curl <ccurl...@gmail.com> writes: >>> So if I am understanding the discussion here, in many Forth implementations, >>> the actual machine code is static (the system's primitives), and essentially >>> everything else is data. >> >> That would be a classic threaded-code implementation. The current >> mainstream is to have a native-code implementation, though, e.g., >> SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with >> --no-dynamic your description fits, but in the default configuration >> it generates native code at run-time (unless there is some red flag >> that turns this off). >> >> - anton > Thanks for the clarification ... one last clarification please ... > > Since I am not doing something totally new and different, I might as > use words that other implementations have used for the same sorts of > operations. > > In a native code implementation, what do "," and "C," operate on ... > the data or the code area? > > Hugh referred to a "COMPILE," word for adding to the code area, which > implies that "," and "C," are used for the data/dictionary area ... is > that pretty common, and if so, does it take 8, 16, 32, or 64 bit value? COMPILE, is in ANS Forth and its successors. It's used to compile contents of colon definitions. Exactly what they compile depends on the implementation strategy: pointers, JSRs, tokens, or actual machine code (potentially optimized), but whatever it is will go in code space. "," and "C," compile one-cell and one-char items in data space. > It almost feels like it would be clearer to have words like "CODE,", > "CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup > like that, "," and "C," would be shortcuts for one of the 3 different > more specific words. ANS Forth and successors try to be very clear what spaces words work in, as I describe above. HERE is specified to return the next address in data space. Implementations that segregate code and data space commonly use THERE for the equivalent next code space location. In implementations with mixed code and data space, compilation may affect HERE; this exception is clearly spelled out in the standard. Application writers are cautioned not to assume any particular implementation or to attempt to modify either definition heads or contents, only data. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-07-22 14:08 -0700 |
| Message-ID | <daa7131e-1129-4326-a9f0-b0b24a308323@googlegroups.com> |
| In reply to | #49341 |
On Friday, July 22, 2016 at 3:09:48 PM UTC-4, Elizabeth D. Rather wrote: > On 7/22/16 5:13 AM, Chris Curl wrote: > > On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote: > >> Chris Curl <ccurl...@gmail.com> writes: > >>> So if I am understanding the discussion here, in many Forth implementations, > >>> the actual machine code is static (the system's primitives), and essentially > >>> everything else is data. > >> > >> That would be a classic threaded-code implementation. The current > >> mainstream is to have a native-code implementation, though, e.g., > >> SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with > >> --no-dynamic your description fits, but in the default configuration > >> it generates native code at run-time (unless there is some red flag > >> that turns this off). > >> > >> - anton > > Thanks for the clarification ... one last clarification please ... > > > > Since I am not doing something totally new and different, I might as > > use words that other implementations have used for the same sorts of > > operations. > > > > In a native code implementation, what do "," and "C," operate on ... > > the data or the code area? > > > > Hugh referred to a "COMPILE," word for adding to the code area, which > > implies that "," and "C," are used for the data/dictionary area ... is > > that pretty common, and if so, does it take 8, 16, 32, or 64 bit value? > > COMPILE, is in ANS Forth and its successors. It's used to compile > contents of colon definitions. Exactly what they compile depends on the > implementation strategy: pointers, JSRs, tokens, or actual machine code > (potentially optimized), but whatever it is will go in code space. "," > and "C," compile one-cell and one-char items in data space. > > > It almost feels like it would be clearer to have words like "CODE,", > > "CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup > > like that, "," and "C," would be shortcuts for one of the 3 different > > more specific words. > > ANS Forth and successors try to be very clear what spaces words work in, > as I describe above. HERE is specified to return the next address in > data space. Implementations that segregate code and data space commonly > use THERE for the equivalent next code space location. In > implementations with mixed code and data space, compilation may affect > HERE; this exception is clearly spelled out in the standard. Application > writers are cautioned not to assume any particular implementation or to > attempt to modify either definition heads or contents, only data. > > Cheers, > Elizabeth So ... "HERE" "THERE", and "COMPILE," Do "," and "C," increment HERE, while "COMPILE," increments THERE?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 15:24 -0700 |
| Message-ID | <823e9d60-5cee-4e4b-b511-4885949e7d7c@googlegroups.com> |
| In reply to | #49345 |
On Friday, July 22, 2016 at 2:08:55 PM UTC-7, Chris Curl wrote: > On Friday, July 22, 2016 at 3:09:48 PM UTC-4, Elizabeth D. Rather wrote: > > On 7/22/16 5:13 AM, Chris Curl wrote: > > > On Friday, July 22, 2016 at 9:12:14 AM UTC-4, Anton Ertl wrote: > > >> Chris Curl <ccurl...@gmail.com> writes: > > >>> So if I am understanding the discussion here, in many Forth implementations, > > >>> the actual machine code is static (the system's primitives), and essentially > > >>> everything else is data. > > >> > > >> That would be a classic threaded-code implementation. The current > > >> mainstream is to have a native-code implementation, though, e.g., > > >> SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with > > >> --no-dynamic your description fits, but in the default configuration > > >> it generates native code at run-time (unless there is some red flag > > >> that turns this off). > > >> > > >> - anton > > > Thanks for the clarification ... one last clarification please ... > > > > > > Since I am not doing something totally new and different, I might as > > > use words that other implementations have used for the same sorts of > > > operations. > > > > > > In a native code implementation, what do "," and "C," operate on ... > > > the data or the code area? > > > > > > Hugh referred to a "COMPILE," word for adding to the code area, which > > > implies that "," and "C," are used for the data/dictionary area ... is > > > that pretty common, and if so, does it take 8, 16, 32, or 64 bit value? > > > > COMPILE, is in ANS Forth and its successors. It's used to compile > > contents of colon definitions. Exactly what they compile depends on the > > implementation strategy: pointers, JSRs, tokens, or actual machine code > > (potentially optimized), but whatever it is will go in code space. "," > > and "C," compile one-cell and one-char items in data space. > > > > > It almost feels like it would be clearer to have words like "CODE,", > > > "CODE-C,", "DICT,", "DICT-C,", "DATA,", and "DATA-C,". With a setup > > > like that, "," and "C," would be shortcuts for one of the 3 different > > > more specific words. > > > > ANS Forth and successors try to be very clear what spaces words work in, > > as I describe above. HERE is specified to return the next address in > > data space. Implementations that segregate code and data space commonly > > use THERE for the equivalent next code space location. In > > implementations with mixed code and data space, compilation may affect > > HERE; this exception is clearly spelled out in the standard. Application > > writers are cautioned not to assume any particular implementation or to > > attempt to modify either definition heads or contents, only data. > > > > Cheers, > > Elizabeth > So ... "HERE" "THERE", and "COMPILE," > > Do "," and "C," increment HERE, while "COMPILE," increments THERE? COMPILE, compiles an xt. In the old days of Forth-83, there was just comma and it was also used for compiling a cfa --- this worked given the assumption that the system was ITC --- with STC and/or an optimizing compiler however, comma doesn't work. In a simple ITC system, COMPILE, is just like comma except for code-space rather than data-space. In a simple STC system, COMPILE, will compile a CALL instruction and the cfa as the operand. In an optimizing system, COMPILE, isn't necessarily going to compile into the code-space at all --- it may compile into an intermediate data-structure, then semicolon will call the optimizer that will compile that intermediate code into machine-code for the entire function. As I said before, you don't want the user to have any expectation of what COMPILE, does, or to mess with code-space himself --- this is definitely unlawful carnal knowledge --- if you're going to have portability of programs, then COMPILE, has to be a black-box and you define it with terms such as "compile the xt" that are purposely left undefined. One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible. That lie used to drive Jeff Fox up the wall! Elizabeth Rather really knew how to push his buttons, and that lie made him mad every time! There were optimizing compilers before ANS-Forth (some written by Jeff Fox) but they weren't Forth-83 compliant because they had something other than comma for compiling an xt, so Forth-83 program that used comma wouldn't work. What is really dumb about Elizabeth Rather bragging that ANS-Forth was such an improvement over Forth-83, is that it was Forth Inc. that screwed up both the Forth-83 and ANS-Forth Standards. In Forth-83 days, all the Forth programmers had to work around the bugs in the Forth-83 design --- then, in ANS-Forth days, all the Forth programmers had to work around the bugs in the ANS-Forth design --- when Forth-200x comes out, etc... The Forth Standards over the decades have documented Elizabeth Rather's glacial progress through programming-101 concepts that most programmers learn in one year --- now Elizabeth Rather's appointed Forth-200x committee are writing a new Standard, but as usual it looks like the work of a programming-101 'D' student, just like every other time. There is never going to be a meaningful Forth Standard until Forth Inc. gets kicked out --- they have screwed up every standard so far --- Forth Inc. is a boat-anchor chained to the ankle of the Forth community.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-22 20:12 -0700 |
| Message-ID | <386cd6c3-7210-44e3-837b-6f40b10a483c@googlegroups.com> |
| In reply to | #49347 |
On Friday, July 22, 2016 at 3:24:11 PM UTC-7, hughag...@gmail.com wrote: > One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible. "It's not a lie if you believe it" -- George Castanza The "Dr Dobbs Toolbook of Forth" (1987) described a subroutine threaded Forth for the 68000 with peephole optimization and native code generation. MacForth was one of the first programming SDKs for the Mac (1984). It switched to subroutine threading in 1987. MacForth (Carbon and Cocoa) is alive and well 30 years later at MPE, running under VFX.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-22 17:36 -1000 |
| Message-ID | <o6adnYkX9Jfeew_KnZ2dnUU7-T_NnZ2d@supernews.com> |
| In reply to | #49350 |
On 7/22/16 5:12 PM, Brad Eckert wrote: > On Friday, July 22, 2016 at 3:24:11 PM UTC-7, hughag...@gmail.com wrote: >> One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible. > > "It's not a lie if you believe it" -- George Castanza > > The "Dr Dobbs Toolbook of Forth" (1987) described a subroutine threaded Forth for the 68000 with peephole optimization and native code generation. MacForth was one of the first programming SDKs for the Mac (1984). It switched to subroutine threading in 1987. MacForth (Carbon and Cocoa) is alive and well 30 years later at MPE, running under VFX. Indeed, MacForth was an outstanding, and in some ways groundbreaking, Forth. But it was not Forth83 compatible, and suffered some in the marketplace for that reason. Don Colburn was an enthusiastic participant in the development of ANS Forth, and delighted to be able to offer a *Standard* version of MacForth with all its nice features. The version of locals adopted for Forth94 came from MacForth. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 21:54 -0700 |
| Message-ID | <953d36c7-bfc0-4579-a3ba-18e6e7a07062@googlegroups.com> |
| In reply to | #49351 |
On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote: > On 7/22/16 5:12 PM, Brad Eckert wrote: > > On Friday, July 22, 2016 at 3:24:11 PM UTC-7, hughag...@gmail.com wrote: > >> One of the lies that Elizabeth Rather likes to tell, is that there were no optimizing compilers prior to ANS-Forth and that ANS-Forth made optimizing compilers possible. > > > > "It's not a lie if you believe it" -- George Castanza > > > > The "Dr Dobbs Toolbook of Forth" (1987) described a subroutine threaded Forth for the 68000 with peephole optimization and native code generation. MacForth was one of the first programming SDKs for the Mac (1984). It switched to subroutine threading in 1987. MacForth (Carbon and Cocoa) is alive and well 30 years later at MPE, running under VFX. > > Indeed, MacForth was an outstanding, and in some ways groundbreaking, > Forth. But it was not Forth83 compatible, and suffered some in the > marketplace for that reason. Don Colburn was an enthusiastic participant > in the development of ANS Forth, and delighted to be able to offer a > *Standard* version of MacForth with all its nice features. The version > of locals adopted for Forth94 came from MacForth. So, it was Don Colburn's fault that the parameters for LOCALS| were backwards --- you always blame somebody else for the myriad screw-ups in ANS-Forth! --- to a large extent, the purpose of having a Forth-200x committee, and appointing people to be on the committee, is so you will have somebody to blame when the bad design of Forth-200x becomes obvious. There was no ANS-Forth compiler until 3 years after ANS-Forth became the Standard. This was SwiftForth, and up through version-2 of SwiftForth (LOCAL) would crash the system when it was used (SwiftForth had so many bugs as to be unusable for professional programming). It seems more likely that the locals design for ANS-Forth is completely screwed up because nobody ever tested it --- if you want to blame Don Colburn for this, then go ahead --- it was, however, your job as the chairperson of the ANS-Forth committee to test the design and make sure it made sense. You were in a hurry to get ANS-Forth ratified by ANSI --- this is why you didn't take the time to test any of this stuff --- all you cared about was declaring yourself to be the person who writes the Standard for the entire Forth community, and actually having a Standard that made sense was unimportant to you. Earlier it was said that Rick Van Norman was to blame for all the bugs in SwiftForth, and that you were not to blame --- this is how your little cult works --- they always blame somebody other than you for your failures.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-22 22:03 -0700 |
| Message-ID | <4b658c82-c445-4c9b-801c-715128aeb0df@googlegroups.com> |
| In reply to | #49352 |
On Friday, July 22, 2016 at 9:54:49 PM UTC-7, hughag...@gmail.com wrote: > -- this is how your little cult works --- they always blame somebody other than you for your failures. The hooded brown robes are actually quite comfy.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-22 22:00 -0700 |
| Message-ID | <0d246713-81f2-467f-9704-d28cccd15bcb@googlegroups.com> |
| In reply to | #49351 |
On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote: > > Indeed, MacForth was an outstanding, and in some ways groundbreaking, > Forth. But it was not Forth83 compatible, and suffered some in the > marketplace for that reason. Don Colburn was an enthusiastic participant > in the development of ANS Forth, and delighted to be able to offer a > *Standard* version of MacForth with all its nice features. The version > of locals adopted for Forth94 came from MacForth. > It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice. For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994. But now that the dust has settled, what are the most popular objections to the ANS way of doing things?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 22:19 -0700 |
| Message-ID | <bc1da2b6-c067-49c4-9115-3f1cc225dbf6@googlegroups.com> |
| In reply to | #49353 |
On Friday, July 22, 2016 at 10:00:53 PM UTC-7, Brad Eckert wrote: > It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice. The MiniForth processor, developed in 1994/1995 did not have an overflow flag. The only flag that it had was Carry --- it was possible to test for minus and zero and obtain a flag on the data-stack for use by 0BRANCH --- there was no easy way to test for overflow (the only time this became an issue for me was when I wrote the DO loops). > For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994. > > But now that the dust has settled, what are the most popular objections to the ANS way of doing things? ambiguity
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-22 20:40 -1000 |
| Message-ID | <x6ednVd4nNDOjA7KnZ2dnUU7-X_NnZ2d@supernews.com> |
| In reply to | #49353 |
On 7/22/16 7:00 PM, Brad Eckert wrote: > On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote: >> >> Indeed, MacForth was an outstanding, and in some ways groundbreaking, >> Forth. But it was not Forth83 compatible, and suffered some in the >> marketplace for that reason. Don Colburn was an enthusiastic participant >> in the development of ANS Forth, and delighted to be able to offer a >> *Standard* version of MacForth with all its nice features. The version >> of locals adopted for Forth94 came from MacForth. >> > It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice. > > For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994. > > But now that the dust has settled, what are the most popular objections to the ANS way of doing things? The major conflicts in developing Forth94 were between the small/simple/classical system purists (predominantly the Boston FIG group) and the big systen "Forth ought to do everything every other language can do" contingent. There was also a "Forth83 was perfect" contingent. The middle ground was occupied by folks such as FORTH, Inc. and MPE who were (and are) are less interested in theoretical issues than in getting applications written for our clients and improving their confidence that these applications will be maintainable and not trashed by a totally re-written standard. It's important to understand that standards exist for application writers, not system developers. An individual system developer is always free to do whatever; what remains to be seen is whether others adopt that technology. Companies whose lives depend upon developed applications that they are dependent upon require that these applications are written in standardized languages, so that there will be a market of programmers to help maintain them over the years. They are far more interested in stability than in innovation and cute features. These are the markets that MPE and FORTH, Inc. are dependent upon. As we are continually involved in writing and maintaining applications for these clients, we identify what application needs there and develop solutions. We are less interested in theoretical things (*this language* has *this* feature, how can we do this in Forth?) than "*this feature* was necessary in the last <n> projects we worked on, so we should standardize it." Chuck and the GreenArrays folks have a completely different set of desiderata from any of the above. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-23 22:23 +1000 |
| Message-ID | <nmvne5$1fum$1@gioia.aioe.org> |
| In reply to | #49359 |
Elizabeth D. Rather wrote: > ... > The middle ground was occupied by folks such as FORTH, Inc. > and MPE who were (and are) are less interested in theoretical issues > than in getting applications written for our clients and improving their > confidence that these applications will be maintainable and not trashed > by a totally re-written standard. > > It's important to understand that standards exist for application > writers, not system developers. An individual system developer is always > free to do whatever; what remains to be seen is whether others adopt > that technology. Companies whose lives depend upon developed > applications that they are dependent upon require that these > applications are written in standardized languages, so that there will > be a market of programmers to help maintain them over the years. They > are far more interested in stability than in innovation and cute > features. These are the markets that MPE and FORTH, Inc. are dependent > upon. As we are continually involved in writing and maintaining > applications for these clients, we identify what application needs there > and develop solutions. We are less interested in theoretical things > (*this language* has *this* feature, how can we do this in Forth?) than > "*this feature* was necessary in the last <n> projects we worked on, so > we should standardize it." Compare the above with that below from a couple weeks ago. It's amazing what a bit of emphasis can do. Elizabeth D. Rather wrote: > > The "Forth Community" has always been a strong consideration, including > not only professional vendors like FORTH, Inc. and MPE (who have > collaborated on projects and have never been hostile competitors) but > also implementer of systems in widespread use such as GForth and > Win32Forth and FIG back in the day, not to mention Open Firmware, which > contributed several great concepts to ANS Forth. Experience and a user > base count for a lot. Individual bright ideas are a good thing, but as > candidates for standardization they become more valuable when they have > been shared and picked up by others and developed a body of users.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-24 15:48 -0700 |
| Message-ID | <51998d95-6644-4544-a138-27d258944777@googlegroups.com> |
| In reply to | #49359 |
On Friday, July 22, 2016 at 11:40:25 PM UTC-7, Elizabeth D. Rather wrote: > On 7/22/16 7:00 PM, Brad Eckert wrote: > > On Friday, July 22, 2016 at 8:36:40 PM UTC-7, Elizabeth D. Rather wrote: > >> > >> Indeed, MacForth was an outstanding, and in some ways groundbreaking, > >> Forth. But it was not Forth83 compatible, and suffered some in the > >> marketplace for that reason. Don Colburn was an enthusiastic participant > >> in the development of ANS Forth, and delighted to be able to offer a > >> *Standard* version of MacForth with all its nice features. The version > >> of locals adopted for Forth94 came from MacForth. > >> > > It's interesting that the biggest ANS opponents were the Forth hardware guys. It's as if ANS was geared to use all four flags in CPUs designed to run C code: Overflow, Carry, Minus and Zero. Of course all architectures going forward have to support C, so that was the main target of ANS. So, : < - 0< ; is nonstandard in one case that will probably never happen in practice. > > > > For all the arm waving, I never saw a compelling example of what's so wrong with ANS. I think the biggest objection is the limited access to the compiler internals, which forces you to write your own QUIT loop to do much customization of the interpreter. But the facilities are there to do that. The TC had the job of parsing out religious issues from technical issues. The 2012 standard revisited locals and other things that couldn't reach a consensus in 1994. > > > > But now that the dust has settled, what are the most popular objections to the ANS way of doing things? > > The major conflicts in developing Forth94 were between the > small/simple/classical system purists (predominantly the Boston FIG > group) and the big systen "Forth ought to do everything every other > language can do" contingent. There was also a "Forth83 was perfect" > contingent. The debate is not between whether we should have fewer features or more features, the debate is between whether we should design the features in an intelligent way or whether we should design the features in a stupid way. You screwed up the design of *all* the features in ANS-Forth! The locals were completely screwed up. Your ANS-Forth is also rife with ambiguity --- you routinely standardized two features that were incompatible with each other. You are a sales-person --- all sales-people are stupid --- you are stupid! > The middle ground was occupied by folks such as FORTH, Inc. > and MPE who were (and are) are less interested in theoretical issues > than in getting applications written for our clients and improving their > confidence that these applications will be maintainable and not trashed > by a totally re-written standard. This isn't true either. If writing applications is important, then you need to have a compiler to compile those applications. ANS-Forth was sent to ANSI in 1994 without any ANS-Forth compiler being written. It would not be until 1997 that the first ANS-Forth compiler, SwiftForth, came out. SwiftForth was a bug-ridden mess and was not suitable for professional programming due to the bugs. It is laughable that you say that your goal was to improve the confidence of your clients --- nobody has any confidence that Forth Inc. can succeed at writing any program --- that was true in 1994 and continues to be true today.
[toc] | [prev] | [next] | [standalone]
| From | missycurl@gmail.com |
|---|---|
| Date | 2016-07-24 16:04 -0700 |
| Message-ID | <1753dc4a-5337-4f22-a11c-f07aeab14a86@googlegroups.com> |
| In reply to | #49407 |
On Sunday, July 24, 2016 at 6:48:37 PM UTC-4, hughag...@gmail.com wrote: > The debate is not between whether we should have fewer features or more features, the debate is between whether we should design the features in an intelligent way or whether we should design the features in a stupid way. > > You screwed up the design of *all* the features in ANS-Forth! The locals were completely screwed up. Your ANS-Forth is also rife with ambiguity --- you routinely standardized two features that were incompatible with each other. > > You are a sales-person --- all sales-people are stupid --- you are stupid! > > This isn't true either. If writing applications is important, then you need to have a compiler to compile those applications. ANS-Forth was sent to ANSI in 1994 without any ANS-Forth compiler being written. It would not be until 1997 that the first ANS-Forth compiler, SwiftForth, came out. SwiftForth was a bug-ridden mess and was not suitable for professional programming due to the bugs. > > It is laughable that you say that your goal was to improve the confidence of your clients --- nobody has any confidence that Forth Inc. can succeed at writing any program --- that was true in 1994 and continues to be true today. Hugh, do you realize that the only thing your rants do is tuen off people like me? Your constant bashing of Elizabeth does not help anything, and it certainly is off topic for this thread. We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have to go by before you put it behind you?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-24 19:31 -0400 |
| Message-ID | <nn3j4r$rf7$1@dont-email.me> |
| In reply to | #49410 |
On 7/24/2016 7:04 PM, missycurl@gmail.com wrote: > On Sunday, July 24, 2016 at 6:48:37 PM UTC-4, hughag...@gmail.com wrote: >> The debate is not between whether we should have fewer features or more features, the debate is between whether we should design the features in an intelligent way or whether we should design the features in a stupid way. >> >> You screwed up the design of *all* the features in ANS-Forth! The locals were completely screwed up. Your ANS-Forth is also rife with ambiguity --- you routinely standardized two features that were incompatible with each other. >> >> You are a sales-person --- all sales-people are stupid --- you are stupid! >> >> This isn't true either. If writing applications is important, then you need to have a compiler to compile those applications. ANS-Forth was sent to ANSI in 1994 without any ANS-Forth compiler being written. It would not be until 1997 that the first ANS-Forth compiler, SwiftForth, came out. SwiftForth was a bug-ridden mess and was not suitable for professional programming due to the bugs. >> >> It is laughable that you say that your goal was to improve the confidence of your clients --- nobody has any confidence that Forth Inc. can succeed at writing any program --- that was true in 1994 and continues to be true today. > > Hugh, do you realize that the only thing your rants do is tuen off people > like me? Your constant bashing of Elizabeth does not help anything, and it > certainly is off topic for this thread. > > We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have > to go by before you put it behind you? I guess I'm as guilty as anyone as I don't always resist the impulse to respond to Hugh. But I can assure you it is pointless. He genuinely has no idea of how crazy he sounds. He doesn't understand his actions are absurd. He is powerless to control his compulsion to rant and rave. Nothing any of us can do will help Hugh. We can help ourselves by not responding to him. However, that isn't going to happen. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-24 17:20 -0700 |
| Message-ID | <48942ecc-a922-4997-bc13-8d20aba60d77@googlegroups.com> |
| In reply to | #49412 |
On Sunday, July 24, 2016 at 4:31:40 PM UTC-7, rickman wrote: > > Nothing any of us can do will help Hugh. We can help ourselves by not > responding to him. However, that isn't going to happen. > It seems most readers are pretty tolerant of Hugh's unique way of processing reality.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-24 17:54 -0700 |
| Message-ID | <587ebb6a-d2e7-4281-a698-b0cb0a32e6ba@googlegroups.com> |
| In reply to | #49410 |
On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote: > Hugh, do you realize that the only thing your rants do is tuen off people > like me? Your constant bashing of Elizabeth does not help anything, and it > certainly is off topic for this thread. > > We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have > to go by before you put it behind you? When you say, "put it behind you," you mean that I should just give up and become one of Elizabeth Rather's sycophants --- start sucking and learn to like it --- I'm never going to do that! I know you will say that you aren't a sycophant, but that isn't really true. You complain that I'm off topic, but you don't complain that Elizabeth Rather is off topic. Look at what Elizabeth Rather said that your were okay with: On Friday, July 22, 2016 at 11:40:25 PM UTC-7, Elizabeth D. Rather wrote: > The middle ground was occupied by folks such as FORTH, Inc. > and MPE who were (and are) are less interested in theoretical issues > than in getting applications written for our clients and improving their > confidence that these applications will be maintainable and not trashed > by a totally re-written standard. > > It's important to understand that standards exist for application > writers, not system developers. An individual system developer is always > free to do whatever; what remains to be seen is whether others adopt > that technology. Companies whose lives depend upon developed > applications that they are dependent upon require that these > applications are written in standardized languages, so that there will > be a market of programmers to help maintain them over the years. They > are far more interested in stability than in innovation and cute > features. These are the markets that MPE and FORTH, Inc. are dependent > upon. As we are continually involved in writing and maintaining > applications for these clients, we identify what application needs there > and develop solutions. We are less interested in theoretical things > (*this language* has *this* feature, how can we do this in Forth?) than > "*this feature* was necessary in the last <n> projects we worked on, so > we should standardize it." This is just meaningless sales blather --- she is saying that only Forth Inc. and MPE were interested in writing application programs --- really??? This isn't true anyway. ANS-Forth wasn't designed for writing application programs. ANS-Forth was purposely crippled to prevent application programs from being written --- all of the Forth community would be relegated to programming in ANS-Forth in gForth which has never been used for professional programming and never will --- to become professional programmers, they have to abandon ANS-Forth and go non-standard (that is what MPE does in every professional program that MPE writes). I know that you think you can work within Forth-200x to improve ANS-Forth. This is not true either. I have said many times that a cross-compiler needs to be able to examine an xt and determine the word's attributes (which vocabulary is it in?, is it immediate or not?, is it smudged or not?, is it smudge-ready or not?), and also to change these attributes --- this is actually trivial to implement --- Forth-200x refuses to do this because they want to prevent the Forth community from writing cross-compilers in competition with Forth Inc. and MPE. Elizabeth Rather said that her goal was to have: "a market of programmers to help maintain [legacy programs at Forth Inc. and MPE] over the years." ANS-Forth was purposely crippled to so that it would only support toy programs (what Anton Ertl's students write) and would not support professional programming. If you become an ANS-Forth programmer though, then you learn ultra-basic concepts (what is taught in "Starting Forth") and you become qualified to maybe work as a maintenance programmer at Forth Inc. or MPE --- those legacy programs aren't actually ANS-Forth though, so you will have to learn a lot of vendor-specific features that were used in the programs --- as an ANS-Forth programmer however you will never write professional programs (not Forth Inc. or MPE or anybody else has ever written a professional program in ANS-Forth). The topic of this thread is code and data separation. Since you seem to want to be stay on-topic, lets go with that. Here is what Stephen Pelc says on the subject (section 21.9.1 of the VFX manual): "CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location." Later on we have section 21.9.3 with the ominous heading: "Gotchas." This says: ------------------------------------------------------------------------- When +IDATA is in use, standard defining words such as VARIABLE and VALUE will reserve space in the IDATA areas, but ALLOT still reserves space in the dictionary. Consequently code such as: VARIABLE <name> <size> ALLOT will break when +IDATA is active. Use: <size> BUFFER: <name> for all such allocations. Words such as >BODY and BODY> will not work correctly on words whose data area is in an IDATA region. ------------------------------------------------------------------------- Essentially what this means is that ANS-Forth can't work in a system that separates code and data, because it typically won't work. So, ANS-Forth screwed up by allowing code and data to be intermixed --- there is no way to smooth this over --- it is just a screw-up typical of what you get when you put somebody in charge who doesn't know assembly-language. ANS-Forth was built on compromises. Back in 1994 Stephen Pelc knew that code and data needed to be separated (this is basic assembly-language programming that everybody knows). He wanted to be ANS-Forth compliant, so Elizabeth Rather said fine, separating code and data is ANS-Forth. Forth Inc. however had code and data intermixed (and continues to do so today), so she said that this is is also ANS-Forth compliant. Everybody gets to be ANS-Forth compliant! The only problem is that (as Stephen Pelc admits in the VFX manual as quoted above) ANS-Forth code won't run on a Forth system that has code and data separated --- a lot of code that runs on SwiftForth will fail on VFX unless this feature is turned off with the -IDATA switch --- so, anybody who wants to write portable code has to assume the worst-case scenario (invariable, this means assuming SwiftForth, because SwiftForth is always the worst-case). Stephen Pelc is fine with this situation. He wants people to just buy VFX and write code that is VFX-specific (the +IDATA switch is the default in VFX) and forget about porting their programs to other ANS-Forth compilers. So, how is this different from not having a standard at all? What exactly was accomplished by Elizabeth Rather in 1994?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-24 21:27 -0400 |
| Message-ID | <nn3pu0$a8t$1@dont-email.me> |
| In reply to | #49416 |
On 7/24/2016 8:54 PM, hughaguilar96@gmail.com wrote: > On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote: >> Hugh, do you realize that the only thing your rants do is tuen off people >> like me? Your constant bashing of Elizabeth does not help anything, and it >> certainly is off topic for this thread. >> >> We all get it that you have a big problem with the positions taken by the ANS Forth committee, and you blame Elizabeth for much of it. How many years have >> to go by before you put it behind you? > > When you say, "put it behind you," you mean that I should just give up and become one of Elizabeth Rather's sycophants --- start sucking and learn to like it --- I'm never going to do that! > > I know you will say that you aren't a sycophant, but that isn't really true. You complain that I'm off topic, but you don't complain that Elizabeth Rather is off topic. Look at what Elizabeth Rather said that your were okay with: > > On Friday, July 22, 2016 at 11:40:25 PM UTC-7, Elizabeth D. Rather wrote: >> The middle ground was occupied by folks such as FORTH, Inc. >> and MPE who were (and are) are less interested in theoretical issues >> than in getting applications written for our clients and improving their >> confidence that these applications will be maintainable and not trashed >> by a totally re-written standard. >> >> It's important to understand that standards exist for application >> writers, not system developers. An individual system developer is always >> free to do whatever; what remains to be seen is whether others adopt >> that technology. Companies whose lives depend upon developed >> applications that they are dependent upon require that these >> applications are written in standardized languages, so that there will >> be a market of programmers to help maintain them over the years. They >> are far more interested in stability than in innovation and cute >> features. These are the markets that MPE and FORTH, Inc. are dependent >> upon. As we are continually involved in writing and maintaining >> applications for these clients, we identify what application needs there >> and develop solutions. We are less interested in theoretical things >> (*this language* has *this* feature, how can we do this in Forth?) than >> "*this feature* was necessary in the last <n> projects we worked on, so >> we should standardize it." > > This is just meaningless sales blather --- she is saying that only Forth Inc. and MPE were interested in writing application programs --- really??? > > This isn't true anyway. ANS-Forth wasn't designed for writing application programs. ANS-Forth was purposely crippled to prevent application programs from being written --- all of the Forth community would be relegated to programming in ANS-Forth in gForth which has never been used for professional programming and never will --- to become professional programmers, they have to abandon ANS-Forth and go non-standard (that is what MPE does in every professional program that MPE writes). > > I know that you think you can work within Forth-200x to improve ANS-Forth. This is not true either. I have said many times that a cross-compiler needs to be able to examine an xt and determine the word's attributes (which vocabulary is it in?, is it immediate or not?, is it smudged or not?, is it smudge-ready or not?), and also to change these attributes --- this is actually trivial to implement --- Forth-200x refuses to do this because they want to prevent the Forth community from writing cross-compilers in competition with Forth Inc. and MPE. > > Elizabeth Rather said that her goal was to have: "a market of programmers to help maintain [legacy programs at Forth Inc. and MPE] over the years." ANS-Forth was purposely crippled to so that it would only support toy programs (what Anton Ertl's students write) and would not support professional programming. If you become an ANS-Forth programmer though, then you learn ultra-basic concepts (what is taught in "Starting Forth") and you become qualified to maybe work as a maintenance programmer at Forth Inc. or MPE --- those legacy programs aren't actually ANS-Forth though, so you will have to learn a lot of vendor-specific features that were used in the programs --- as an ANS-Forth programmer however you will never write professional programs (not Forth Inc. or MPE or anybody else has ever written a professional program in ANS-Forth). > > The topic of this thread is code and data separation. Since you seem to want to be stay on-topic, lets go with that. Here is what Stephen Pelc says on the subject (section 21.9.1 of the VFX manual): > "CPUs from the Pentium 3 onwards have serious performance problems when data is close to code, leading to a wide variation in performance depending on data location." > > Later on we have section 21.9.3 with the ominous heading: "Gotchas." This says: > ------------------------------------------------------------------------- > When +IDATA is in use, standard defining words such as VARIABLE and VALUE will reserve space > in the IDATA areas, but ALLOT still reserves space in the dictionary. Consequently code such as: > VARIABLE <name> <size> ALLOT > will break when +IDATA is active. Use: > <size> BUFFER: <name> > for all such allocations. > Words such as >BODY and BODY> will not work correctly on words whose data area is in an > IDATA region. > ------------------------------------------------------------------------- > > Essentially what this means is that ANS-Forth can't work in a system that separates code and data, because it typically won't work. So, ANS-Forth screwed up by allowing code and data to be intermixed --- there is no way to smooth this over --- it is just a screw-up typical of what you get when you put somebody in charge who doesn't know assembly-language. > > ANS-Forth was built on compromises. Back in 1994 Stephen Pelc knew that code and data needed to be separated (this is basic assembly-language programming that everybody knows). He wanted to be ANS-Forth compliant, so Elizabeth Rather said fine, separating code and data is ANS-Forth. Forth Inc. however had code and data intermixed (and continues to do so today), so she said that this is is also ANS-Forth compliant. Everybody gets to be ANS-Forth compliant! The only problem is that (as Stephen Pelc admits in the VFX manual as quoted above) ANS-Forth code won't run on a Forth system that has code and data separated --- a lot of code that runs on SwiftForth will fail on VFX unless this feature is turned off with the -IDATA switch --- so, anybody who wants to write portable code has to assume the worst-case scenario (invariable, this means assuming SwiftForth, because SwiftForth is always the worst-case). > > Stephen Pelc is fine with this situation. He wants people to just buy VFX and write code that is VFX-specific (the +IDATA switch is the default in VFX) and forget about porting their programs to other ANS-Forth compilers. So, how is this different from not having a standard at all? What exactly was accomplished by Elizabeth Rather in 1994? I think this serves as installment 2 of Hugh's manifesto. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-24 19:18 -0700 |
| Message-ID | <8ab95bd6-8eab-4dfa-8d0f-bc87cabf1809@googlegroups.com> |
| In reply to | #49417 |
On Sunday, July 24, 2016 at 6:27:29 PM UTC-7, rickman wrote: > On 7/24/2016 8:54 PM, hughaguilar96@gmail.com wrote: > > On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote: > >> Your constant bashing of Elizabeth does not help anything, and it > >> certainly is off topic for this thread. > > I think this serves as installment 2 of Hugh's manifesto. Why do you complain that my constant bashing of Elizabeth does not help anything and is off topic --- but you don't complain that Rickman's constant talk about a "manifesto" does not help anything and is off topic? Somewhat of a double-standard there, don't you think?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-24 22:25 -0400 |
| Message-ID | <nn3t9u$hbs$1@dont-email.me> |
| In reply to | #49419 |
On 7/24/2016 10:18 PM, hughaguilar96@gmail.com wrote: > On Sunday, July 24, 2016 at 6:27:29 PM UTC-7, rickman wrote: >> On 7/24/2016 8:54 PM, hughaguilar96@gmail.com wrote: >>> On Sunday, July 24, 2016 at 4:04:52 PM UTC-7, miss...@gmail.com wrote: >>>> Your constant bashing of Elizabeth does not help anything, and it >>>> certainly is off topic for this thread. >> >> I think this serves as installment 2 of Hugh's manifesto. > > Why do you complain that my constant bashing of Elizabeth does not help anything and is off topic --- but you don't complain that Rickman's constant talk about a "manifesto" does not help anything and is off topic? > > Somewhat of a double-standard there, don't you think? No, a single standard applied to all, but one that you are not capable of understanding. I really and truly feel sorry for you. I'm sorry that you live the life you do and will never get help. I can't imagine what it's like to feel so persecuted as you. There are *lots* of off topic posts in this group. But most are sane. The complaint was that your post was obnoxious. The mention of it being off topic was secondary. But you are not capable of understanding any of that, are you? -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web