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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-22 14:18 -0400 |
| Message-ID | <nmto2l$hc7$1@dont-email.me> |
| In reply to | #49337 |
On 7/22/2016 1:56 PM, Chris Curl wrote: > On Friday, July 22, 2016 at 1:43:55 PM UTC-4, Brad Eckert wrote: >> We live in age in which the costs of complexity are almost universally underestimated. > > Very well put. I agree completely. > > One of my primary gauges for code is that it should be "intuitively obvious > upon casual inspection". If it isn't, then there better be a damn good reason > why not. Sometimes the problem is just that complex. I wrote some VHDL code to search for a sync to an external signal and then keep the internal signal in step. I tried more than once to simplify the code, but the functional elements were all required with lots of interaction between them. If it were written in Forth, I don't think it could have been factored any better with the possibility of a bit more reuse. Factoring and reuse is not as easy in VHDL, but it isn't limited, just verbose. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-22 08:55 -1000 |
| Message-ID | <Q82dnXJZUpyP8Q_KnZ2dnUU7-TnNnZ2d@supernews.com> |
| In reply to | #49336 |
On 7/22/16 7:43 AM, Brad Eckert wrote: > What I get from all this is that you can't design Forth by > committee. You have to do it like Chuck. One committed guy > does the whole thing his way. When Chuck left Forth Inc, the > basic philosophy was frozen in amber. When the ANS TC came > along, Chuck found this amber too hard to chisel through. > The level of implementation creativity inspired by ANS Forth's emphasis on semantics (behavior) rather than implementation (as in Forth83) has led to major improvements in performance, by various optimizing compiler techniques and other things. No amber there. However, the existence of a large and growing number of significant existing applications, as well as the need to encourage organizations and professional programmers to use Forth, meant that a level of stability had to be provided. This is true of all programming languages that aspire to be more than a personal toy. During the Forth94 development the TC members received from ANSI all the official correspondence of other language TCs. During that period both Fortran and Cobol standards were undergoing development. The level of outrage against some of the changes being discussed was impressive, including multi-million $$ lawsuits. I gather that the C standards have strayed somewhat from the original K&R, but I'll bet it's still pretty recognizable. > So, you have you and Chris and others implementing their > own Forths. It's a big job to work your way up to Chuck level. > Many Forths to write. But, Forth will never be finished. > It's a way of life, this pursuit of elegant minimalism. > We live in age in which the costs of complexity are almost > universally underestimated. If you really want Forth to flourish, you need to be writing applications and publishing application-oriented code, rather than re-designing the elegantly simple wheel itself. 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 | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-07-25 11:34 +0000 |
| Message-ID | <nn4tgh$519$1@dont-email.me> |
| In reply to | #49311 |
> she hates anybody who has accomplished > anything with Forth, and she tells > gross lies about the person, but she > praises those who have never > accomplished anything (so long as they > praise her as the "leading expert" of > Forth). From Ambrose Bierce's "Devil's Dictionary": commendation, n. The tribute that we pay to achievements that resemble, but do not equal, our own. -- [W]e had enough employees who made more than 85 to fill all the openings. The highest score that any of the blacks scored on the test was 11. The lowest score that any black made on the test was 4. All four of those blacks went into skilled-trades training. https://archive.org/download/TheOldmanArchives/oldman29-081003.mp3
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-22 11:36 -0400 |
| Message-ID | <nmteif$ehp$1@dont-email.me> |
| In reply to | #49310 |
On 7/22/2016 12:56 AM, Brad Eckert wrote: > On Thursday, July 21, 2016 at 8:58:15 PM UTC-7, hughag...@gmail.com > wrote: >> >> If both code and data are in the same cache-line, then you are >> wasting cache space --- also, there is the awkward problem of what >> happens if your code writes into data that is in the code-cache. >> > Yes, that is awkward. How do you propose handling two different > behaviors of comma (compile to code space or compile to data space)? > >> Stupid! Why do you even get involved in these technical >> discussions? You really know nothing about programming! You should >> just stick to braying about how you are the "leading expert" who >> writes the Standard for all Forth programmers, and avoid getting >> involved in technical discussions because you invariably make fool >> out of yourself with your ignorance. > > Did I mention the ANS TC was a quarter century ago? She and Ned wrote > a nice book on ANS, which is an information-dense reference. > Regardless, there's a book. How about you write a book as you write > your cool new Forth. If you develop the book and Forth together, you > will have a good reference book so people can actually use it. > > I've never met Elizabeth Rather (now Conklin), so I can't really say > much about her apart from what I read on c.l.f. However, I've never > seen her call anyone stupid. Really? Is there any reason to believe anything you say will have even the tiniest impact on Hugh's behavior? The one thing I do know is that in replying to him you give him an opportunity to continue ranting and raving. He is clearly not completely balanced. Would you try to talk sense to someone on the street who ranted about secret conspiracies? No, you would just walk away and most likely very quickly. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-07-22 11:15 +0200 |
| Message-ID | <867fcejanz.fsf@molnjunk.nocrew.org> |
| In reply to | #49301 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Yes, but cache sizes have grown much bigger. The system I'm typing on > has 6M cache. Two problems with that statement: - There may be a cache hierarchy. On a desktop computer, 6M is typically at level 3. If you stay inside the much smaller L1, or the L2 cache, your code will be much faster. - Embedded targets usually have smaller caches.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-22 11:37 -0400 |
| Message-ID | <nmtejj$ehp$2@dont-email.me> |
| In reply to | #49319 |
On 7/22/2016 5:15 AM, Lars Brinkhoff wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Yes, but cache sizes have grown much bigger. The system I'm typing on >> has 6M cache. > > Two problems with that statement: > > - There may be a cache hierarchy. On a desktop computer, 6M is > typically at level 3. If you stay inside the much smaller L1, or the L2 > cache, your code will be much faster. > > - Embedded targets usually have smaller caches. If any at all. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-22 08:56 -1000 |
| Message-ID | <Q82dnW1ZUpzh8Q_KnZ2dnUU7-TlQAAAA@supernews.com> |
| In reply to | #49319 |
On 7/21/16 11:15 PM, Lars Brinkhoff wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Yes, but cache sizes have grown much bigger. The system I'm typing on >> has 6M cache. > > Two problems with that statement: > > - There may be a cache hierarchy. On a desktop computer, 6M is > typically at level 3. If you stay inside the much smaller L1, or the L2 > cache, your code will be much faster. > > - Embedded targets usually have smaller caches. > ...or no cache at all. But embedded Forths and applications generally *do* segregate code and data spaces. 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-24 13:16 +1000 |
| Message-ID | <nn1bq0$1m7u$1@gioia.aioe.org> |
| In reply to | #49291 |
Brad Eckert wrote: > On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote: > > As you folks may remember, I am implementing my own little Forth. > > > > I have implemented two flavors of the memory organization, one where > > the code and dictionary start at opposite ends of the memory space and > > grow towards each other, and one where the dictionary entries are interspersed > > with the code. > > > If header space is separate from code space, you can possibly do things like: > > : place ( a u dest -) 0 over c! [ > : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; I have but the benefit is questionable. When primitives are involved you may be saving space at the cost of efficiency e.g. PLACE needs overlap checking whereas +PLACE does not. > Also, the code is smaller so you have fewer cache misses. As processors get faster, it > seems cache misses get more expensive. That's why small virtual machines sometimes beat > native code implementations. The VM fits in cache. > > You also have the option of discarding the header space, such as when creating a ROM > image for an embedded system. Unless you can discard the compiler, separated heads don't offer much IMO. An exception is segmented architectures like the 8086 where putting heads in their own segment meant more room for code.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-24 12:58 -0700 |
| Message-ID | <e5334450-3055-4dcc-9b27-06568c9f855e@googlegroups.com> |
| In reply to | #49383 |
On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote: > Brad Eckert wrote: >> If header space is separate from code space, you can possibly do >> things like: >> >> : place ( a u dest -) 0 over c! [ >> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; > > I have but the benefit is questionable. When primitives are involved you > may be saving space at the cost of efficiency e.g. PLACE needs overlap > checking whereas +PLACE does not. > I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can compile a branch over the header data. Or in my example above, : ;: postpone [ : ; : place ( a u dest -) 0 over c! ;: +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ;
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-25 18:09 +1000 |
| Message-ID | <nn4hac$1i03$1@gioia.aioe.org> |
| In reply to | #49398 |
Brad Eckert wrote: > On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote: > > Brad Eckert wrote: > >> If header space is separate from code space, you can possibly do > >> things like: > >> > >> : place ( a u dest -) 0 over c! [ > >> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; > > > > I have but the benefit is questionable. When primitives are involved you > > may be saving space at the cost of efficiency e.g. PLACE needs overlap > > checking whereas +PLACE does not. > > > I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can compile a > branch over the header data. Or in my example above, > : ;: postpone [ : ; > > : place ( a u dest -) 0 over c! ;: +place ( a u dest -) > 2dup >r >r count + swap move r> r> c+! ; It's a good name. While the resulting coding style takes getting used to, a reader can't but help notice PLACE is dependent upon +PLACE. OTOH I have the same problem with multiple entry points as quotations. It's hard to find enough compelling cases to justify their use ... unlike say +string which has everyday uses e.g. : +place count +string swap 1- c! ;
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-24 22:34 -1000 |
| Message-ID | <04KdnWxKbtCzUgjKnZ2dnUU7-RPNnZ2d@supernews.com> |
| In reply to | #49454 |
On 7/24/16 10:09 PM, HAA wrote: > Brad Eckert wrote: >> On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote: >>> Brad Eckert wrote: >>>> If header space is separate from code space, you can possibly do >>>> things like: >>>> >>>> : place ( a u dest -) 0 over c! [ >>>> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; >>> >>> I have but the benefit is questionable. When primitives are involved you >>> may be saving space at the cost of efficiency e.g. PLACE needs overlap >>> checking whereas +PLACE does not. >>> >> I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can compile a >> branch over the header data. Or in my example above, >> : ;: postpone [ : ; >> >> : place ( a u dest -) 0 over c! ;: +place ( a u dest -) >> 2dup >r >r count + swap move r> r> c+! ; > > It's a good name. While the resulting coding style takes getting used to, > a reader can't but help notice PLACE is dependent upon +PLACE. > > OTOH I have the same problem with multiple entry points as quotations. > It's hard to find enough compelling cases to justify their use ... unlike say > +string which has everyday uses e.g. : +place count +string swap 1- c! ; Historical note: ;: was Chuck's original name for the structure which for many years now has been CREATE DOES> (by separating the creation from the instance behaviors you get more flexibility). 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-27 23:08 +1000 |
| Message-ID | <nnabiq$4qh$1@gioia.aioe.org> |
| In reply to | #49458 |
Elizabeth D. Rather wrote: > On 7/24/16 10:09 PM, HAA wrote: > > Brad Eckert wrote: > >> On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote: > >>> Brad Eckert wrote: > >>>> If header space is separate from code space, you can possibly do > >>>> things like: > >>>> > >>>> : place ( a u dest -) 0 over c! [ > >>>> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; > >>> > >>> I have but the benefit is questionable. When primitives are involved you > >>> may be saving space at the cost of efficiency e.g. PLACE needs overlap > >>> checking whereas +PLACE does not. > >>> > >> I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can > >> compile a branch over the header data. Or in my example above, > >> : ;: postpone [ : ; > >> > >> : place ( a u dest -) 0 over c! ;: +place ( a u dest -) > >> 2dup >r >r count + swap move r> r> c+! ; > > > > It's a good name. While the resulting coding style takes getting used to, > > a reader can't but help notice PLACE is dependent upon +PLACE. > > > > OTOH I have the same problem with multiple entry points as quotations. > > It's hard to find enough compelling cases to justify their use ... unlike say > > +string which has everyday uses e.g. : +place count +string swap 1- c! ; > > Historical note: ;: was Chuck's original name for the structure which > for many years now has been CREATE DOES> (by separating the creation > from the instance behaviors you get more flexibility). > > Cheers, > Elizabeth It's listed among the Forth-79 'reference words'. Was it functionally different from DOES> ?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-27 08:58 -1000 |
| Message-ID | <LY2dnf9BXvXOmQTKnZ2dnUU7-XHNnZ2d@supernews.com> |
| In reply to | #49560 |
On 7/27/16 3:08 AM, HAA wrote: > Elizabeth D. Rather wrote: >> On 7/24/16 10:09 PM, HAA wrote: >>> Brad Eckert wrote: >>>> On Saturday, July 23, 2016 at 8:14:11 PM UTC-7, HAA wrote: >>>>> Brad Eckert wrote: >>>>>> If header space is separate from code space, you can possibly do >>>>>> things like: >>>>>> >>>>>> : place ( a u dest -) 0 over c! [ >>>>>> : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; >>>>> >>>>> I have but the benefit is questionable. When primitives are involved you >>>>> may be saving space at the cost of efficiency e.g. PLACE needs overlap >>>>> checking whereas +PLACE does not. >>>>> >>>> I just thought of ;: for multiple entry points. In a mixed dictionary, ;: can >>>> compile a branch over the header data. Or in my example above, >>>> : ;: postpone [ : ; >>>> >>>> : place ( a u dest -) 0 over c! ;: +place ( a u dest -) >>>> 2dup >r >r count + swap move r> r> c+! ; >>> >>> It's a good name. While the resulting coding style takes getting used to, >>> a reader can't but help notice PLACE is dependent upon +PLACE. >>> >>> OTOH I have the same problem with multiple entry points as quotations. >>> It's hard to find enough compelling cases to justify their use ... unlike say >>> +string which has everyday uses e.g. : +place count +string swap 1- c! ; >> >> Historical note: ;: was Chuck's original name for the structure which >> for many years now has been CREATE DOES> (by separating the creation >> from the instance behaviors you get more flexibility). >> >> Cheers, >> Elizabeth > > It's listed among the Forth-79 'reference words'. Was it functionally different > from DOES> ? I don't really remember the details, but as I recall it didn't have the separate CREATE step, and the current formulation allows more control in the defining part. There was an evolution from ;: to <BUILDS ... DOES> and then CREATE ... DOES> with somewhat different assumptions for each. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-28 09:17 +0000 |
| Subject | CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <2016Jul28.111700@mips.complang.tuwien.ac.at> |
| In reply to | #49580 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 7/27/16 3:08 AM, HAA wrote:
>> Elizabeth D. Rather wrote:
>>> Historical note: ;: was Chuck's original name for the structure which
>>> for many years now has been CREATE DOES> (by separating the creation
>>> from the instance behaviors you get more flexibility).
...
>I don't really remember the details, but as I recall it didn't have the
>separate CREATE step,
That's interesting, because I have been thinking about how to deal
with the problem that Forth systems compiling to flash have
difficulties with CREATE...DOES>, because DOES> overwrites a field
that ideally would lie in flash (and which we don't want to
overwrite).
With the existence of quotations, a way to do this would be to replace
: foo
create code1
does>
code2 ;
with
: foo
[: code2 ;] <does-create code1 ;
With this syntax there would be no intermediate stage where the
created word just pushes an address, and whichj has later to be
changed into a word that runs code2.
However, that's not the only issue in this context; we also have other
words that change existing words, in particular, IMMEDIATE; among
non-standard words, we have e.g., COMPILE-ONLY and SET-OPTIMIZER/OPT:.
Doing all of that in one step is not very practical. We could have a
word with one parameter for each of these options that creates a word
with these options in one step, maybe something like:
new-word ( flag1 flag2 xt1 xt2 xt3 xt4 "name" -- )
\ flag1 specifies immediacy
\ flag2 specifies compile-only
\ xt1 specifies interpretation/execution semantics
\ xt2 specifies compilation semantics
\ xt3 specifies what to do when COMPILE,ing the xt of "name" (for optimization)
\ xt4 specifies TO "name" semantics
But, apart from the sheer uglyness, that would require standardizing
all these features, and leaving no room for non-standard features. So
I lean more towards recording the things for the next definition in a
RAM buffer, and then the next defining word puts all these features in
the newly-defined word (in flash, in one step), and wipe the (RAM)
slate clean for the next word to be defined; i.e. for an immediate
word, it would be something like:
next-immediate : bar ... ;
For the DOES>-using foo example above it would be:
: foo
[: code2 ;] next-does create code1 ;
For an optimizing 2DUP it would be
:noname drop postpone over postpone over ; next-optimizer
: 2dup over over ;
And then one could combine several of these setup words. E.g., for
defining <http://forth-standard.org/standard/facility/PlusFIELD>:
: +field ( n1 n2 "name" -- n3 )
[: @ + ;] next-does
[: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
create over , + ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-29 00:19 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <nnd43i$5j8$1@gioia.aioe.org> |
| In reply to | #49607 |
Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >On 7/27/16 3:08 AM, HAA wrote: > >> Elizabeth D. Rather wrote: > >>> Historical note: ;: was Chuck's original name for the structure which > >>> for many years now has been CREATE DOES> (by separating the creation > >>> from the instance behaviors you get more flexibility). > ... > >I don't really remember the details, but as I recall it didn't have the > >separate CREATE step, > > That's interesting, because I have been thinking about how to deal > with the problem that Forth systems compiling to flash have > difficulties with CREATE...DOES>, because DOES> overwrites a field > that ideally would lie in flash (and which we don't want to > overwrite). > > With the existence of quotations, a way to do this would be to replace > > : foo > create code1 > does> > code2 ; > > with > > : foo > [: code2 ;] <does-create code1 ; > > With this syntax there would be no intermediate stage where the > created word just pushes an address, and whichj has later to be > changed into a word that runs code2. > > However, that's not the only issue in this context; we also have other > words that change existing words, in particular, IMMEDIATE; among > non-standard words, we have e.g., COMPILE-ONLY and SET-OPTIMIZER/OPT:. > ... You could do : foo ['] xt2 <does-create code1 ; For basic systems xt2 is what you expect but for systems requiring multiple xt's and/or other info, xt2 can be a system-specific struct containing all the information foo needs to create child words.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-28 14:54 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <2016Jul28.165423@mips.complang.tuwien.ac.at> |
| In reply to | #49612 |
"HAA" <someone@microsoft.com> writes:
>You could do
>
>: foo ['] xt2 <does-create code1 ;
>
>For basic systems xt2 is what you expect but for systems requiring
>multiple xt's and/or other info, xt2 can be a system-specific struct
>containing all the information foo needs to create child words.
Yes, having an explicit word-descriptor structure, with a default
content (or content coming from an existing word), rather than an
implicit next-word-descriptor structure is also a possibility.
E.g., for the implicit example from my posting
: +field ( n1 n2 "name" -- n3 )
[: @ + ;] next-does
[: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
create over , + ;
an explicit-descriptor variant might look like this:
word-descriptor field-desc
:noname @ + ; field-desc word-does!
:noname >body @ ?dup if postpone literal postpone + then ;
field-desc word-optimizer!
: +field ( n1 n2 "name" -- n3 )
field-desc word-create over , + ;
I think it would be more cumbersome to use, and does not offer much,
if any, benefit in implementation simplicity.
There is one disadvantage with the implicit descriptor, though: Using
:NONAME to create words interpretively with the NEXT-... words
consumes the stuff set up up to now, and resets the descriptor.
Bernd Paysan has proposed (and, in Gforth, implemented) interpretive
[:...;], and that could save and restore the descriptor context; AFAIK
it already does something conceptually similar in Gforth, where, e.g.,
interpretive "[: ... ;] SET-OPTIMIZER" applies to the word defined
before the [: ... ;], not to the [: ... ;]. The disadvantage of this
approach is that it introduces another one of these horrible words
with non-default non-immediate compilation semantics.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-07-28 10:00 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <cae428f7-71a8-4975-8e65-28fed00f0edb@googlegroups.com> |
| In reply to | #49617 |
On Thursday, July 28, 2016 at 6:21:35 PM UTC+3, Anton Ertl wrote: > "HAA" writes: > >You could do > > > >: foo ['] xt2 <does-create code1 ; > > > >For basic systems xt2 is what you expect but for systems requiring > >multiple xt's and/or other info, xt2 can be a system-specific struct > >containing all the information foo needs to create child words. > > Yes, having an explicit word-descriptor structure, with a default > content (or content coming from an existing word), rather than an > implicit next-word-descriptor structure is also a possibility. > > E.g., for the implicit example from my posting > > : +field ( n1 n2 "name" -- n3 ) > [: @ + ;] next-does > [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer > create over , + ; > > an explicit-descriptor variant might look like this: > > word-descriptor field-desc > :noname @ + ; field-desc word-does! > :noname >body @ ?dup if postpone literal postpone + then ; > field-desc word-optimizer! > > : +field ( n1 n2 "name" -- n3 ) > field-desc word-create over , + ; > > I think it would be more cumbersome to use, and does not offer much, > if any, benefit in implementation simplicity. > > There is one disadvantage with the implicit descriptor, though: Using > :NONAME to create words interpretively with the NEXT-... words > consumes the stuff set up up to now, and resets the descriptor. > > Bernd Paysan has proposed (and, in Gforth, implemented) interpretive > [:...;], and that could save and restore the descriptor context; AFAIK > it already does something conceptually similar in Gforth, where, e.g., > interpretive "[: ... ;] SET-OPTIMIZER" applies to the word defined > before the [: ... ;], not to the [: ... ;]. The disadvantage of this > approach is that it introduces another one of these horrible words > with non-default non-immediate compilation semantics. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2016: http://www.euroforth.org/ef16/ Hi! It looks too complex. :) I'll think that I'll drop 'structures' use and adopt something like 'templates': \ templates.fs Sketch. Author: humptydumpty : TEMPLATE CREATE HERE ; : SIZE HERE swap - CONSTANT ; : -> dup CONSTANT cell+ ; \ Template Usage Example: TEMPLATE PIX 1 , 2 , 3 , size /PIXEL PIX -> X -> Y -> Z drop : PIXELS /PIXEL * ; : PIXEL PIX - ; : .pixel ( apixel -- ) PIXEL dup X + ? dup Y + ? Z + ? ; CREATE ORIGIN 0 , 0 , 0 , ORIGIN .pixel Command-line test: gforth templates.fs -e '.s cr bye' 0 0 0 <0> Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-29 21:47 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <nnffjo$182j$1@gioia.aioe.org> |
| In reply to | #49617 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >You could do > > > >: foo ['] xt2 <does-create code1 ; > > > >For basic systems xt2 is what you expect but for systems requiring > >multiple xt's and/or other info, xt2 can be a system-specific struct > >containing all the information foo needs to create child words. > > Yes, having an explicit word-descriptor structure, with a default > content (or content coming from an existing word), rather than an > implicit next-word-descriptor structure is also a possibility. > > E.g., for the implicit example from my posting > > : +field ( n1 n2 "name" -- n3 ) > [: @ + ;] next-does > [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer > create over , + ; > > an explicit-descriptor variant might look like this: > > word-descriptor field-desc > :noname @ + ; field-desc word-does! > :noname >body @ ?dup if postpone literal postpone + then ; > field-desc word-optimizer! > > : +field ( n1 n2 "name" -- n3 ) > field-desc word-create over , + ; > > I think it would be more cumbersome to use, and does not offer much, > if any, benefit in implementation simplicity. > > There is one disadvantage with the implicit descriptor, though: Using > :NONAME to create words interpretively with the NEXT-... words > consumes the stuff set up up to now, and resets the descriptor. > > Bernd Paysan has proposed (and, in Gforth, implemented) interpretive > [:...;], and that could save and restore the descriptor context; AFAIK > it already does something conceptually similar in Gforth, where, e.g., > interpretive "[: ... ;] SET-OPTIMIZER" applies to the word defined > before the [: ... ;], not to the [: ... ;]. The disadvantage of this > approach is that it introduces another one of these horrible words > with non-default non-immediate compilation semantics. The problem with using quotations is that it won't work on all systems. Run-time code needs to reside in target space. Defining words and quotations created by them will reside in host/compiler space. Systems where these spaces are different (e.g. target compilers) will require a strategy other than quotations.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-07-29 15:04 +0200 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <n92fdl43xxxq.err4r4s2mbab$.dlg@40tude.net> |
| In reply to | #49651 |
Op Fri, 29 Jul 2016 21:47:24 +1000 schreef HAA: > Anton Ertl wrote: >> "HAA" <someone@microsoft.com> writes: >>>You could do >>> >>>: foo ['] xt2 <does-create code1 ; >>> >>>For basic systems xt2 is what you expect but for systems requiring >>>multiple xt's and/or other info, xt2 can be a system-specific struct >>>containing all the information foo needs to create child words. >> >> Yes, having an explicit word-descriptor structure, with a default >> content (or content coming from an existing word), rather than an >> implicit next-word-descriptor structure is also a possibility. >> >> E.g., for the implicit example from my posting >> >>: +field ( n1 n2 "name" -- n3 ) >> [: @ + ;] next-does >> [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer >> create over , + ; >> >> an explicit-descriptor variant might look like this: >> >> word-descriptor field-desc >>:noname @ + ; field-desc word-does! >>:noname >body @ ?dup if postpone literal postpone + then ; >> field-desc word-optimizer! >> >>: +field ( n1 n2 "name" -- n3 ) >> field-desc word-create over , + ; >> >> I think it would be more cumbersome to use, and does not offer much, >> if any, benefit in implementation simplicity. >> >> There is one disadvantage with the implicit descriptor, though: Using >>:NONAME to create words interpretively with the NEXT-... words >> consumes the stuff set up up to now, and resets the descriptor. >> >> Bernd Paysan has proposed (and, in Gforth, implemented) interpretive >> [:...;], and that could save and restore the descriptor context; AFAIK >> it already does something conceptually similar in Gforth, where, e.g., >> interpretive "[: ... ;] SET-OPTIMIZER" applies to the word defined >> before the [: ... ;], not to the [: ... ;]. The disadvantage of this >> approach is that it introduces another one of these horrible words >> with non-default non-immediate compilation semantics. > > The problem with using quotations is that it won't work on all systems. > Run-time code needs to reside in target space. Defining words and > quotations created by them will reside in host/compiler space. > Systems where these spaces are different (e.g. target compilers) > will require a strategy other than quotations. A quotation is code like a :NONAME definition. Why couldn't it reside in target memory? groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-30 18:42 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <nnhp3d$9c9$1@gioia.aioe.org> |
| In reply to | #49653 |
Coos Haak wrote: > Op Fri, 29 Jul 2016 21:47:24 +1000 schreef HAA: > > ... > > The problem with using quotations is that it won't work on all systems. > > Run-time code needs to reside in target space. Defining words and > > quotations created by them will reside in host/compiler space. > > Systems where these spaces are different (e.g. target compilers) > > will require a strategy other than quotations. > > A quotation is code like a :NONAME definition. Why couldn't it > reside in target memory? > > groet Coos Quotations were justified on the grounds it was too much trouble to name them and linking them to a parent would not create any issues.
[toc] | [prev] | [next] | [standalone]
Page 3 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