Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42204 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-09-26 15:17 -0700 |
| Last post | 2015-10-31 10:44 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.forth
New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-26 15:17 -0700
Re: New to the group mentificium@gmail.com - 2015-09-26 17:35 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-26 21:16 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 07:27 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 14:43 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 13:05 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 12:57 -1000
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-27 17:00 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 17:16 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 20:31 -0400
Re: New to the group jfong@ms4.hinet.net - 2015-09-27 18:57 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 19:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 20:53 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 19:02 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-27 23:33 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 04:51 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 12:39 -0400
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 14:29 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 07:18 -0700
Re: New to the group foxaudioresearch@gmail.com - 2015-09-28 08:07 -0700
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 17:23 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 11:16 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 14:25 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-29 09:05 +0000
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 20:31 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 13:20 -0700
Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 22:52 +0200
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 16:40 -0700
Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-09-28 08:41 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-28 11:41 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-28 21:33 -0700
Re: New to the group jfong@ms4.hinet.net - 2015-09-28 19:13 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 00:51 -0400
Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:26 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:55 -0400
Re: New to the group Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-09-30 08:29 +0100
Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:52 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 00:29 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 04:40 -0700
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-29 05:24 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 07:33 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:11 -0700
Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-29 16:46 +0000
Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:15 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 17:34 -0400
Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-30 00:07 +0000
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:54 -0700
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-26 22:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:51 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 17:15 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:58 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 22:03 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-29 21:32 -1000
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 09:06 +0100
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 08:58 -1000
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-30 23:55 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 21:28 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:25 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-10-01 09:33 -0700
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 16:21 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 21:03 -0400
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 19:34 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 23:47 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:31 -0400
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 00:30 -0400
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-01 19:22 -1000
Re: New to the group hughaguilar96@gmail.com - 2015-10-01 23:52 -0700
Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-10-02 01:52 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 08:36 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:00 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-02 14:46 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 18:10 -0400
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 16:08 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 20:44 -0400
Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:54 -0400
Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:16 -1000
Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 18:21 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:38 -1000
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 22:13 -0400
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-03 22:24 +0100
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-03 17:33 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-09-30 17:00 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 20:38 -0400
Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-10-02 14:37 -0400
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:01 -0400
Re: New to the group hughaguilar96@gmail.com - 2015-10-02 23:35 -0700
Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 18:11 -0400
Re: New to the group Coos Haak <chforth@hccnet.nl> - 2015-10-01 02:13 +0200
Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 08:38 +0100
Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-09-30 10:58 -0400
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-01 06:04 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 09:46 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:07 +0000
Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-10-09 04:04 -0700
Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-09 10:29 -0400
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-09 15:30 +0000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-03 00:19 -0700
Re: New to the group visualforth@rocketmail.com - 2015-10-03 17:01 -0700
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:38 +0000
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-07 21:15 -1000
Minimal wordset (was: New to the group) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 13:39 +0000
Re: Minimal wordset (was: New to the group) JUERGEN <epldfpga@aol.com> - 2015-10-08 08:13 -0700
Re: Minimal wordset (was: New to the group) Mark Wills <markwills1970@gmail.com> - 2015-10-09 00:55 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 10:43 +0200
Re: Minimal wordset Chris Curl <ccurl609@gmail.com> - 2015-10-09 06:56 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:44 +0200
Re: Minimal wordset Paul Rubin <no.email@nospam.invalid> - 2015-10-09 14:02 -0700
Re: Minimal wordset Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 09:44 +0100
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-10 11:36 +0000
Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 08:40 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:53 +0200
Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 11:22 -0700
Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:33 -0700
Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 20:38 +0200
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-10-09 20:56 +0000
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-01 20:10 -0500
Re: Minimal wordset Coos Haak <chforth@hccnet.nl> - 2015-11-02 03:05 +0100
Re: Minimal wordset "Elizabeth D. Rather" <erather@forth.com> - 2015-11-01 16:08 -1000
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-02 09:35 +0000
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 12:42 +0000
Re: Minimal wordset humptydumpty <ouatubi@gmail.com> - 2015-11-08 23:22 -0800
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:25 -0500
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 19:36 +0000
Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-08 12:56 +1100
Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-08 16:14 +0000
Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-09 11:55 +1100
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 09:41 +0000
Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:29 -0500
Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 17:01 +0000
Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:27 -0700
Re: Minimal wordset (was: New to the group) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 23:11 -0400
Re: Minimal wordset (was: New to the group) Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 08:38 +0100
Re: New to the group dunno <dunno@dunno.dunno> - 2015-10-14 23:14 +0000
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-14 16:21 -1000
Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-15 08:46 +0000
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-03 09:23 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-03 09:19 -1000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-08 05:24 -0700
Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-08 08:22 -1000
Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-09 08:37 -0700
Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-31 10:44 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-09-29 07:33 -0700 |
| Message-ID | <15dbae46-f249-4b6b-8937-0e9311e32470@googlegroups.com> |
| In reply to | #42251 |
On Tuesday, September 29, 2015 at 7:40:20 AM UTC-4, Chris Curl wrote: > Here is the thing about standards, Hugh ... > > You have these packages you wrote that you referred to earlier. They look like they would be really useful, and I'm sure you put a lot of effort into creating them. Since they are written to the standard, they are usable in any Forth that complies with the standard. > > Now ... my flavor of Forth does not comply, so it is extremely unlikely that I will be able to include those packages as-is in my system. So, without standards, it is really difficult for the community to work together and collaborate to make really amazing stuff. > > Therein lies the good thing about standards. Hugh, are you saying that the ANS standard is so loose that a given package could be developed that is in compliance with the standard, and that package STILL could very well NOT work on ALL Forths that are also in compliance with the standard? If so, then I see your point and agree that the "standard" is meaningless.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-29 14:11 -0700 |
| Message-ID | <649b2b08-895c-47f4-997f-8189a7e3db15@googlegroups.com> |
| In reply to | #42253 |
On Tuesday, September 29, 2015 at 7:33:49 AM UTC-7, Chris Curl wrote: > Hugh, are you saying that the ANS standard is so loose that a given package could be developed that is in compliance with the standard, and that package STILL could very well NOT work on ALL Forths that are also in compliance with the standard? If so, then I see your point and agree that the "standard" is meaningless. Yes. There are multiple cases in which the ANS-Forth document says that something may be one thing or may be another thing, and the two things are incompatible. Almost all programs theoretically conform to the standard because they assume something to be true that may be true, but they only run on one ANS-Forth system that also assumes the same thing to be true. The purpose of a standard, as you mentioned previously, is portability. For example, my novice-package runs on several ANS-Forth systems (SwiftForth, gForth, Win32Forth and now VFX). I had to go to a lot of effort to make it run on multiple systems, and I couldn't be sure until I had tested it on all of those systems; I still can't be sure that it will run on another ANS-Forth system that is untested or if on of the tested systems if it changes one or more of its assumptions in a new version. The way to make code portable, as the novice-package is portable, is to examine each ambiguous statement in the ANS-Forth document and figure out what the worst-case scenario is, and assume that. For example, regarding section 3.2.3.2 the worst-case scenario is that the control-flow stack is the same as the data-stack, so I assumed that, and my code still works on systems that have the feature of the control-flow stack being separate from the data-stack, although it doesn't take advantage of this feature. Similarly, it is necessary to assume that tick aborts on the special-case words (such as IF etc.) because this is the worst-case scenario. I'm not aware of anybody other than myself who has gone to the effort to write ANS-Forth code that is portable to multiple ANS-Forth systems --- everybody else, including all of the Forth-200x committee members, write ANS-Forth code that only works on one particular ANS-Forth system. As I said before, the reason why ANS-Forth code is not portable, is because Elizabeth Rather didn't understand that the purpose of a language standard is to allow code to be portable between systems. She believed that the purpose of a language standard is to allow the chair-person of the committee to claim to be the "leading expert" on the language. When the ANS-Forth document was written, it was all about political concessions. All of that ambiguity was put in to allow various systems to be ANS-Forth compliant despite the fact that they were incompatible with each other. The purpose of this is so the compiler-writers of those various systems would sign their names on the ANS-Forth document --- ANSI needs to see a lot of names on the document in order to certify it as the standard --- ANSI would not have certified the document as the standard if it only had Elizabeth Rather's name on it. Many of the names listed on the ANS-Forth document as supporters are of people who don't actually support ANS-Forth --- people such as Charles Moore and Ray Duncan --- mostly they are just names of people who wanted their Forth system to be the standard of the Forth community (woo hoo!) but who were opposed to portability between systems because they wanted to trap their customers in vendor lock-in (Stephen Pelc is a good example of this category). Elizabeth Rather, typical of all sales-people, is a name-dropper. She claims to hob-nob with Barrack Obama's family in Hawaii. She claims to hob-nob with Nobel Peace Prize winners (yes, plural). Mostly she claims to know everything that Charles Moore knows, because he supposedly taught her everything there is to know about Forth way back in the 1970s. This is a typical example (her response when I complained that ANS-Forth doesn't have a D/ function): On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote: > Forth's design is pragmatic: it has functions that have been needed and > that have proven their usefulness *in Forth*, not necessarily those that > have been required in other languages. Generally speaking, Forth has > the most flexible set of *integer* arithmetic operators of any language. > In particular, M*/ was one of Chuck's most brilliant innovations. I'm > sure if Chuck were trying to do your continued fractions that is what he > would rely on. Yes, that sometimes requires thinking differently, like > many other things in Forth. She doesn't actually know what continued fractions are. As a sales-person, name-dropping is all that matters. This is why the ANS-Forth standard was founded entirely upon name-dropping --- she collected names of compiler-writers who wanted to be standard and put their names on the ANS-Forth document --- but none of their Forth systems were compatible.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-09-29 16:46 +0000 |
| Message-ID | <muef9i$uti$1@dont-email.me> |
| In reply to | #42229 |
Roelf Toxopeus wrote: > I've got this scalding hot cup of coffee > here, would love to throw it ... Dissent must not be allowed. There should be a law. > Hugh Aguilar, I'm amazed, he's sure lucky no > one dragged him in court for slander (yet)! Now there's a law we can use to shut him up! > You're new here apparently... The OP titled the thread "New to the group", but Roelf has just as much trouble reading as thinking. > In utter anger and armed to the teeth, -r Throw Hugh into a dungeon! If he resists, kill him! -- For two years ... he was held in solitary confinement in the Toronto West Detention Centre, on the pretext that he is a threat to national security.... [A] court in Mannheim sentenced him to five years imprisonment for the crime of "popular incitement" under Germany's notorious "Holocaust denial" statute. http://www.revisionists.com/revisionists/zundel.html
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-29 14:15 -0700 |
| Message-ID | <61e8bc5e-26a3-44fa-b1fb-2437811f7552@googlegroups.com> |
| In reply to | #42254 |
On Tuesday, September 29, 2015 at 9:48:44 AM UTC-7, WJ wrote: > Roelf Toxopeus wrote: > > In utter anger and armed to the teeth, -r > > Throw Hugh into a dungeon! If he resists, > kill him! WJ --- I have told you repeatedly that I don't want your support --- please go away!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-29 17:34 -0400 |
| Message-ID | <muf01d$6ph$1@dont-email.me> |
| In reply to | #42256 |
On 9/29/2015 5:15 PM, hughaguilar96@gmail.com wrote: > On Tuesday, September 29, 2015 at 9:48:44 AM UTC-7, WJ wrote: >> Roelf Toxopeus wrote: >>> In utter anger and armed to the teeth, -r >> >> Throw Hugh into a dungeon! If he resists, >> kill him! > > WJ --- I have told you repeatedly that I don't want your support --- please go away! LOL! If only we could all wish away those whose words offend us! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-09-30 00:07 +0000 |
| Message-ID | <muf949$8n6$1@dont-email.me> |
| In reply to | #42229 |
Roelf Toxopeus wrote: > CLF is more damaging to Forth than any Forth standard Oforth: "CLF is more damaging to Forth than any Forth standard" words dup extract(9, 10) swap dup extract(2, 8) swap first + + apply( #. ) ===> Forth standard is more damaging to Forth than any CLF ok
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-09-27 10:54 -0700 |
| Message-ID | <3f89f964-61f6-4e5d-b5fb-1f9cb2c8d164@googlegroups.com> |
| In reply to | #42207 |
On Sunday, September 27, 2015 at 12:16:40 AM UTC-4, hughag...@gmail.com wrote: > If you are interested in application programming in Forth, then you can use my novice package: http://www.forth.org/novice.html That looks interesting, thanks for pointing me to it. I will definitely download it and check it out.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-26 22:37 -0700 |
| Message-ID | <87612wbeyb.fsf@jester.gateway.sonic.net> |
| In reply to | #42204 |
Chris Curl <ccurl609@gmail.com> writes: > Hi ... I am new to the group, but not to programming. Welcome! ;-) > My first PC was a Commodore 64 (6502 CPU), back in the mid 1980s, and > I implemented a FORTH-based macro assembler on that as a learning > experience. I also wrote a terminal emulator in FORTH for 8086 DOS > computers. Nice. I've always wondered what the Forth development process was like in that era. > simple FORTH virtual machine with only 30 primitive instructions and a > few C++ methods that implement the VM. Everything else bootstraps > from that. The main file BootStrap.4th looks very simple and easy to understand. It would be interesting to convert everything to be completely in Forth so it could be self-hosting (using something like gforth to bootstrap from).
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-09-27 10:51 -0700 |
| Message-ID | <fb8b6e95-3c27-4bbb-8eca-1268802d3052@googlegroups.com> |
| In reply to | #42208 |
On Sunday, September 27, 2015 at 1:37:18 AM UTC-4, Paul Rubin wrote: > Chris Curl <...@gmail.com> writes: > > Hi ... I am new to the group, but not to programming. > > Welcome! ;-) > > Nice. I've always wondered what the Forth development process was like > in that era. > LOL, there were no cards to read, and the floppy drive was slow and unreliable. The built in language was basic, and it was easy enough to bring up the interface where you could write machine code. From there, you could do anything you wanted. > The main file BootStrap.4th looks very simple and easy to understand. > It would be interesting to convert everything to be completely in Forth > so it could be self-hosting (using something like gforth to bootstrap > from). Yes, one of the goals is to have as small a machine code footprint as possible, and have the system build itself up incrementally. Thanks for looking!
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-09-29 17:15 -0700 |
| Message-ID | <aaa736c4-0c03-4330-b7c2-271233d3d8f9@googlegroups.com> |
| In reply to | #42204 |
If Hugh's points about portability (or the lack thereof) for ANS compliant Forth systems and packages are accurate and true, then it seems to me that the standard is not worth much. People who disagree with Hugh's assessment ... convince me otherwise. But keep it civil please :).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-29 21:58 -0400 |
| Message-ID | <muffhj$k1n$1@dont-email.me> |
| In reply to | #42260 |
On 9/29/2015 8:15 PM, Chris Curl wrote: > If Hugh's points about portability (or the lack thereof) for ANS compliant Forth systems and packages are accurate and true, then it seems to me that the standard is not worth much. > > People who disagree with Hugh's assessment ... convince me otherwise. But keep it civil please :). Good luck on both counts. I don't think many here care a lot to convince you. Why don't you just study it for yourself? ...or not! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-09-29 22:03 -0700 |
| Message-ID | <4340f7c0-4267-494e-988f-bdf6d3c8af0f@googlegroups.com> |
| In reply to | #42265 |
On Tuesday, September 29, 2015 at 9:59:09 PM UTC-4, rickman wrote: > On 9/29/2015 8:15 PM, Chris Curl wrote: > > If Hugh's points about portability (or the lack thereof) for ANS compliant Forth systems and packages are accurate and true, then it seems to me that the standard is not worth much. > > > > People who disagree with Hugh's assessment ... convince me otherwise. But keep it civil please :). > > Good luck on both counts. I don't think many here care a lot to > convince you. Why don't you just study it for yourself? ...or not! > > -- > > Rick Fair enough. I actually was looking into it a little tonight, because I am getting closer to my interpretation loop, and I was curious about the behavior of ' (TICK). Here is the standard: 6.1.0070 ' tick CORE ( "<spaces>name" -- xt ) Skip leading space delimiters. Parse name delimited by a space. Find name and return xt, the execution token for name. An ambiguous condition exists if name is not found. When interpreting, ' xyz EXECUTE is equivalent to xyz. Isn't is a pretty common scenario that the user fat-fingers and ' doesn't find the word? Why do they not say what should be left on the stack in that case? I understand that it means that I can handle it however I feel like handling it today, and I can change it tomorrow if I want, but it also means that I can't write code that uses ' for other Forths, because I don't know how to determine if it didn't find the word. Seems kinda silly to me.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-09-29 21:32 -1000 |
| Message-ID | <NIudncrvPvOGDZbLnZ2dnUU7-LednZ2d@supernews.com> |
| In reply to | #42266 |
On 9/29/15 7:03 PM, Chris Curl wrote: > On Tuesday, September 29, 2015 at 9:59:09 PM UTC-4, rickman wrote: >> On 9/29/2015 8:15 PM, Chris Curl wrote: >>> If Hugh's points about portability (or the lack thereof) for ANS compliant Forth systems and packages are accurate and true, then it seems to me that the standard is not worth much. >>> >>> People who disagree with Hugh's assessment ... convince me otherwise. But keep it civil please :). >> >> Good luck on both counts. I don't think many here care a lot to >> convince you. Why don't you just study it for yourself? ...or not! >> >> -- >> >> Rick > > Fair enough. I actually was looking into it a little tonight, because I am getting closer to my interpretation loop, and I was curious about the behavior of ' (TICK). Here is the standard: > > 6.1.0070 ' tick CORE ( "<spaces>name" -- xt ) > Skip leading space delimiters. Parse name delimited by a space. Find name and return xt, the execution token for name. An ambiguous condition exists if name is not found. > > When interpreting, ' xyz EXECUTE is equivalent to xyz. > > Isn't is a pretty common scenario that the user fat-fingers and ' doesn't find the word? Why do they not say what should be left on the stack in that case? I understand that it means that I can handle it however I feel like handling it today, and I can change it tomorrow if I want, but it also means that I can't write code that uses ' for other Forths, because I don't know how to determine if it didn't find the word. Seems kinda silly to me. If the word isn't found, you'll get an abort in virtually all systems. Technically, the standard says it's an "ambiguous condition," but in common practice it will abort and nothing will be left on the stack. The standard is only one element in a technology; "common practice" is the other major one. Standards understand common practice, and should not violate it. But they often (appropriately, IMO) do not mandate that all systems follow it. That was the mistake Forth83 made: indirect threaded code, 16-bit cell size, other mandates that were limiting and would have been fatal if allowed to persist unchallenged. I was the chair of the group that produced Forth94, following upon (at that time) 21 years of Forth programming, training, documentation, and project management. I was on the committees that produced Forth79 and Forth83, as well. One of the things that ANSI (American National Standards Committee, the major standards body in the US, which oversaw and approved ANS Forth in 1994) emphasizes is the necessity for a standard to revisit common practice and either reaffirm, modify or withdraw an official standard every 5 years. I am retired now, and not actively participating in the current standards efforts, but I respect what has gone into them and their efforts to find a balance between respecting innovation and maintaining compatibility. I am also strongly of the opinion that reading a standard is no way for a beginner to learn a language, because the constraints under which a standard operates introduces too many ambiguities, such as the one you're pointing out here. Far better to get one of the most popular and well-documented implementations and write a few programs. That'll not only clarify a lot of things for you, it'll also help you avoid a lot of the traps and misconceptions that can take you a long time to work around. 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-09-30 09:06 +0100 |
| Message-ID | <mug52t$gss$1@dont-email.me> |
| In reply to | #42268 |
On 30/09/2015 08:32, Elizabeth D. Rather wrote: >> Fair enough. I actually was looking into it a little tonight, because >> I am getting closer to my interpretation loop, and I was curious about >> the behavior of ' (TICK). Here is the standard: >> >> 6.1.0070 ' tick CORE ( "<spaces>name" -- xt ) >> Skip leading space delimiters. Parse name delimited by a space. Find >> name and return xt, the execution token for name. An ambiguous >> condition exists if name is not found. >> >> When interpreting, ' xyz EXECUTE is equivalent to xyz. >> >> Isn't is a pretty common scenario that the user fat-fingers and ' >> doesn't find the word? Why do they not say what should be left on the >> stack in that case? I understand that it means that I can handle it >> however I feel like handling it today, and I can change it tomorrow if >> I want, but it also means that I can't write code that uses ' for >> other Forths, because I don't know how to determine if it didn't find >> the word. Seems kinda silly to me. > > If the word isn't found, you'll get an abort in virtually all systems. > Technically, the standard says it's an "ambiguous condition," but in > common practice it will abort and nothing will be left on the stack. A better system will throw a -13 exception (undefined word) so that a program could handle the situation without aborting. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-09-30 08:58 -1000 |
| Message-ID | <VdqdnevHjINyrZHLnZ2dnUU7-dmdnZ2d@supernews.com> |
| In reply to | #42270 |
On 9/29/15 10:06 PM, Gerry Jackson wrote: > On 30/09/2015 08:32, Elizabeth D. Rather wrote: >>> Fair enough. I actually was looking into it a little tonight, because >>> I am getting closer to my interpretation loop, and I was curious about >>> the behavior of ' (TICK). Here is the standard: >>> >>> 6.1.0070 ' tick CORE ( "<spaces>name" -- xt ) >>> Skip leading space delimiters. Parse name delimited by a space. Find >>> name and return xt, the execution token for name. An ambiguous >>> condition exists if name is not found. >>> >>> When interpreting, ' xyz EXECUTE is equivalent to xyz. >>> >>> Isn't is a pretty common scenario that the user fat-fingers and ' >>> doesn't find the word? Why do they not say what should be left on the >>> stack in that case? I understand that it means that I can handle it >>> however I feel like handling it today, and I can change it tomorrow if >>> I want, but it also means that I can't write code that uses ' for >>> other Forths, because I don't know how to determine if it didn't find >>> the word. Seems kinda silly to me. >> >> If the word isn't found, you'll get an abort in virtually all systems. >> Technically, the standard says it's an "ambiguous condition," but in >> common practice it will abort and nothing will be left on the stack. > > A better system will throw a -13 exception (undefined word) so that a > program could handle the situation without aborting. Indeed, but that's a mechanism. Many systems will respond to a FIND failure by trying other things (number conversion, alternative searches) before giving up with an abort, but that's an implementation detail. Typically ' will do a FIND. If it fails you will get an abort on most systems, because ' is specifically seeking for an xt, and not finding one, so there isn't really much else it can do. Chris, if you want to see the options for exception handling in Forth check out Section 9 The optional Exception word set. That is one of the most successful innovations in Forth94, because it does provide flexible handling of conditions such as you describe. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-09-30 23:55 -0700 |
| Message-ID | <19d10e04-2626-4150-9c79-261c1685f9c7@googlegroups.com> |
| In reply to | #42281 |
On Wednesday, 30 September 2015 19:58:57 UTC+1, Elizabeth D. Rather wrote: > Indeed, but that's a mechanism. Many systems will respond to a FIND > failure by trying other things (number conversion, alternative searches) > before giving up with an abort, but that's an implementation detail. > Typically ' will do a FIND. If it fails you will get an abort on most > systems, because ' is specifically seeking for an xt, and not finding > one, so there isn't really much else it can do. Yack. It can return 0 0 , which is what my system does if FIND can't find a word. The Forth system should try to minimise the number of aborts that it does. The only time it should abort (IMO) is if it runs out of memory, or the stacks become corrupted (under/overflow). Everything else *I* will handle myself, thank-you-very-much! Perhaps I want to check the dictionary for the existence of a word before creating it. That's a pain if FIND aborts. Of course, it's okay for the interpreter to abort if a word isn't found - not much you can do, as you say, but otherwise, the application should be able to deal with the un-expected. This is Forth, afterall, *we're* in charge - not the Forth system!
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-09-30 21:28 -1000 |
| Message-ID | <rPCdnZonDOQwfZHLnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #42295 |
On 9/30/15 8:55 PM, Mark Wills wrote: > On Wednesday, 30 September 2015 19:58:57 UTC+1, Elizabeth D. Rather wrote: >> Indeed, but that's a mechanism. Many systems will respond to a FIND >> failure by trying other things (number conversion, alternative searches) >> before giving up with an abort, but that's an implementation detail. >> Typically ' will do a FIND. If it fails you will get an abort on most >> systems, because ' is specifically seeking for an xt, and not finding >> one, so there isn't really much else it can do. > > Yack. It can return 0 0 , which is what my system does if FIND can't find > a word. The Forth system should try to minimise the number of aborts that > it does. The only time it should abort (IMO) is if it runs out of memory, > or the stacks become corrupted (under/overflow). Everything else *I* will > handle myself, thank-you-very-much! > > Perhaps I want to check the dictionary for the existence of a word before > creating it. That's a pain if FIND aborts. Of course, it's okay for the > interpreter to abort if a word isn't found - not much you can do, as you > say, but otherwise, the application should be able to deal with the > un-expected. This is Forth, afterall, *we're* in charge - not the Forth > system! FIND should not abort, I agree. It returns a result (success or failure) and the system can try something else. But ' is supposed to return an xt. It's not considering other possibilities. If ' (or ['] in a definition) can't return an xt it needs to abort. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-01 08:25 -0400 |
| Message-ID | <muj8jl$khf$1@dont-email.me> |
| In reply to | #42295 |
On 10/1/2015 2:55 AM, Mark Wills wrote: > On Wednesday, 30 September 2015 19:58:57 UTC+1, Elizabeth D. Rather wrote: >> Indeed, but that's a mechanism. Many systems will respond to a FIND >> failure by trying other things (number conversion, alternative searches) >> before giving up with an abort, but that's an implementation detail. >> Typically ' will do a FIND. If it fails you will get an abort on most >> systems, because ' is specifically seeking for an xt, and not finding >> one, so there isn't really much else it can do. > > Yack. It can return 0 0 , which is what my system does if FIND can't find > a word. The Forth system should try to minimise the number of aborts that > it does. The only time it should abort (IMO) is if it runs out of memory, > or the stacks become corrupted (under/overflow). Everything else *I* will > handle myself, thank-you-very-much! > > Perhaps I want to check the dictionary for the existence of a word before > creating it. That's a pain if FIND aborts. Of course, it's okay for the > interpreter to abort if a word isn't found - not much you can do, as you > say, but otherwise, the application should be able to deal with the > un-expected. This is Forth, afterall, *we're* in charge - not the Forth > system! I'm not sure why the conversation shifted from tick to FIND. FIND is defined to not abort, but rather to return a flag indicating the word was not found. So why all the talk about FIND aborting? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-01 09:33 -0700 |
| Message-ID | <b0a9785c-de44-4625-90da-7108ea3a66b5@googlegroups.com> |
| In reply to | #42295 |
On Wednesday, September 30, 2015 at 11:55:44 PM UTC-7, Mark Wills wrote: > On Wednesday, 30 September 2015 19:58:57 UTC+1, Elizabeth D. Rather wrote: > > Indeed, but that's a mechanism. Many systems will respond to a FIND > > failure by trying other things (number conversion, alternative searches) > > before giving up with an abort, but that's an implementation detail. > > Typically ' will do a FIND. If it fails you will get an abort on most > > systems, because ' is specifically seeking for an xt, and not finding > > one, so there isn't really much else it can do. > > Yack. It can return 0 0 , which is what my system does if FIND can't find > a word. The Forth system should try to minimise the number of aborts that > it does. The only time it should abort (IMO) is if it runs out of memory, > or the stacks become corrupted (under/overflow). Everything else *I* will > handle myself, thank-you-very-much! > > Perhaps I want to check the dictionary for the existence of a word before > creating it. That's a pain if FIND aborts. Of course, it's okay for the > interpreter to abort if a word isn't found - not much you can do, as you > say, but otherwise, the application should be able to deal with the > un-expected. This is Forth, afterall, *we're* in charge - not the Forth > system! Cool your jets Mark --- FIND doesn't abort on not-found, but it returns zero --- Elizabeth Rather said that tick calls FIND internally, and tick aborts on not-found. It isn't necessarily true that tick calls FIND internally, because in gForth tick and FIND behave differently --- FIND is able to find words that tick can't find. Anyway, my disambiguifiers fix the problem. Why don't people accept the disambiguifiers? Mostly they refuse to accept a bug-fix because doing so involves admitting that there is a bug --- they are in denial, similar to old men who start drinking at 6:00am but refuse to admit that they are alcoholic and purposely forget about a time when they didn't do that --- this is how bugs become features. This is the definition of FIND (other than the weasel-word last sentence, it is okay): 6.1.1550 FIND CORE ( c-addr -- c-addr 0 | xt 1 | xt -1 ) Find the definition named in the counted string at c-addr. If the definition is not found, return c-addr and zero. If the definition is found, return its execution token xt. If the definition is immediate, also return one (1),otherwise also return minus-one (-1). For a given string, the values returned by FIND while compiling may differ from those returned while not compiling. This is the definition of tick: 6.1.0070 ' "tick" CORE ( "<spaces>name" -- xt ) Skip leading space delimiters. Parse name delimited by a space. Find name and return xt, the execution token for name. An ambiguous condition exists if name is not found. When interpreting, ' name EXECUTE is equivalent to name. This is the definition of bracket-tick: 6.1.2510 ['] "bracket-tick" CORE Interpretation: Interpretation semantics for this word are undefined. Compilation: ( "<spaces>name" -- ) Skip leading space delimiters. Parse name delimited by a space. Find name. Append the runtime semantics given below to the current definition. An ambiguous condition exists if name is not found. Run-time: ( -- xt ) Place name's execution token xt on the stack. The execution token returned by the compiled phrase "['] X " is the same value returned by "' X " outside of compilation state. Note that it says: The execution token returned by the compiled phrase "['] X " is the same value returned by "' X " outside of compilation state. If ['] calls FIND internally then FIND is executing in compilation-mode, but if ' calls FIND internally then FIND is executing in interpretation-mode --- so they aren't necessarily going to return the "same value" because the definition of FIND says: "For a given string, the values returned by FIND while compiling may differ from those returned while not compiling." The ANS-Forth document is not only ambiguous, but it is also self-contradictory! All of this mind-numbing complexity is not necessary; Forth is an inherently simple language. This weird and pointless complexity is obviously the product of somebody who didn't understand the subject that she was trying to teach. Imagine what would happen if I tried to teach a class on quantum mechanics --- the poor students would leave the class knowing less than they did when they went in --- the same thing happens when a salesperson tries to teach computer programming.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-30 16:21 -0700 |
| Message-ID | <97f1036b-2ca0-488f-a630-566994f8e58d@googlegroups.com> |
| In reply to | #42270 |
On Wednesday, September 30, 2015 at 1:06:46 AM UTC-7, Gerry wrote: > On 30/09/2015 08:32, Elizabeth D. Rather wrote: > >> Fair enough. I actually was looking into it a little tonight, because > >> I am getting closer to my interpretation loop, and I was curious about > >> the behavior of ' (TICK). Here is the standard: > >> > >> 6.1.0070 ' tick CORE ( "<spaces>name" -- xt ) > >> Skip leading space delimiters. Parse name delimited by a space. Find > >> name and return xt, the execution token for name. An ambiguous > >> condition exists if name is not found. > >> > >> When interpreting, ' xyz EXECUTE is equivalent to xyz. > >> > >> Isn't is a pretty common scenario that the user fat-fingers and ' > >> doesn't find the word? Why do they not say what should be left on the > >> stack in that case? I understand that it means that I can handle it > >> however I feel like handling it today, and I can change it tomorrow if > >> I want, but it also means that I can't write code that uses ' for > >> other Forths, because I don't know how to determine if it didn't find > >> the word. Seems kinda silly to me. > > > > If the word isn't found, you'll get an abort in virtually all systems. > > Technically, the standard says it's an "ambiguous condition," but in > > common practice it will abort and nothing will be left on the stack. > > A better system will throw a -13 exception (undefined word) so that a > program could handle the situation without aborting. > > -- > Gerry The word "ambiguous" doesn't belong in a language standard, because it doesn't standardize anything. Errors should not result in ambiguous conditions --- they should be handled in a consistent well-defined manner. Gerry is right that it is a good idea to throw an exception rather than abort because this might happen during the run-time of a program (dictionary look-up is legal during run-time in Forth, not just compile-time) and you don't want your program to crash. The situation is actually much worse than Chris realizes. Over 50 of the words in the standard have this sentence in their definition: "Interpretation semantics for this word are undefined." An example is If (section 6.1.1700). Weirdly enough, the words in the standard aren't defined as being immediate or non-immediate (another ambiguity!). A word such as IF that was always immediate can legally be non-immediate in ANS-Forth. But it is an error to execute such a word in interpretive mode; it is only supposed to be executed inside of a colon definition. Rather than define this as an error however, the ANS-Forth document defines it as "undefined" (section 6.1.1700 above), and "undefined" is just another word for "ambiguous" because it doesn't standardize anything. Now the weirdness deepens! We have section 4.1.2 with the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." What this means is that using tick or FIND on a word such as IF is an ambiguous condition, and anything can happen. For example, gForth aborts if you tick IF but it doesn't abort if you use FIND to look up IF. All of the ANS-Forth implementations (SwiftForth, VFX and gForth) do something different when IF is given to tick or to FIND --- that is what ambiguity is all about, doing anything you want to do (including aborting, as gForth does) and calling it standard. Fortunately, it is possible to defeat all of this ambiguity and make ANS-Forth behave in a rational consistent manner. I have my disambiguifiers, such as: : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate If you write a disambiguifier for every special-case word in the standard, the words will be disambiguified: 1.) The word is not always immediate. 2.) The word will provide an xt when given to tick or to FIND 3.) The xt will work when executed in compilation mode but will abort with a meaningful error message when executed in interpretation mode. The disambiguifiers work on all the ANS-Forth implementations (SwiftForth, VFX and gForth) and provide a rational consistent result (the three points described above). As you might predict, the Forth-200x committee absolutely refuse to use the disambiguifiers --- they insist that ANS-Forth and Forth-200x remain ambiguous in regard to what tick and FIND do when encountering special-case words such IF etc.. What is really sad about this, is that Forth is an inherently simple language. For decades words such as IF were rational and consistent and easy to understand. Then ANS-Forth came along, and all of a sudden these words were ambiguous and the inconsistent between one ANS-Forth system and another --- it is really mind-blowing that the ANS-Forth committee could take what was simple and easy, and completely screw it up --- this is why I describe ANS-Forth as being a purely negative contribution to Forth.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web