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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-02 15:38 -1000 |
| Message-ID | <Z_WdnTuSrpc6rJLLnZ2dnUU7-T2dnZ2d@supernews.com> |
| In reply to | #42328 |
On 10/2/15 3:21 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> A system *shall* document the system action taken upon each of the >> general or specific ambiguous conditions > > Oh cool! I wonder how many actually do that. Any that are compliant :-) You'll find a whole section in the back of FORTH, Inc. system manuals itemizing implementation-defined options and actions on ambiguous conditions. Unfortunately, there are a few ambiguous conditions that are very difficult to detect, and it's perfectly legal for your response to be "Ignore and continue" for cases where the cost of detection isn't justified. 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-02 22:13 -0400 |
| Message-ID | <mundhd$4kv$1@dont-email.me> |
| In reply to | #42327 |
On 10/2/2015 9:16 PM, Elizabeth D. Rather wrote: > On 10/2/15 1:08 PM, Paul Rubin wrote: >> Chris Curl <ccurl609@gmail.com> writes: >>> Are you saying that if my implementation of that use case results in a >>> condition I can predict, then my implementation is not compliant? >> >> Of course not. It means that if all you know about someone else's >> implementation is that it's compliant, you can't predict what will >> happen on ambiguous conditions. They (and you) can of course implement >> something predictable and maybe even document it. > > Not "maybe". A compliant system *must* document its response to the > ambiguous conditions called out in the standard: > > 4.1.2 Ambiguous conditions > A system *shall* document the system action taken upon each of the > general or specific ambiguous conditions identified in this standard. > See 3.4.4 Possible actions on an ambiguous condition. This section uses the word, "interpretating". Is that supposed to be "interpreting"? Turns out it is a word, but an archaic one. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-10-03 22:24 +0100 |
| Message-ID | <mupgu3$7p0$1@dont-email.me> |
| In reply to | #42331 |
On 03/10/2015 03:13, rickman wrote: >> 4.1.2 Ambiguous conditions >> A system *shall* document the system action taken upon each of the >> general or specific ambiguous conditions identified in this standard. >> See 3.4.4 Possible actions on an ambiguous condition. > > This section uses the word, "interpretating". Is that supposed to be > "interpreting"? Turns out it is a word, but an archaic one. It's been changed to "interpreting" in the Forth 2012 document which supersedes the ANS Forth document. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-03 17:33 -0400 |
| Message-ID | <muphfn$88r$3@dont-email.me> |
| In reply to | #42342 |
On 10/3/2015 5:24 PM, Gerry Jackson wrote: > On 03/10/2015 03:13, rickman wrote: >>> 4.1.2 Ambiguous conditions >>> A system *shall* document the system action taken upon each of the >>> general or specific ambiguous conditions identified in this standard. >>> See 3.4.4 Possible actions on an ambiguous condition. >> >> This section uses the word, "interpretating". Is that supposed to be >> "interpreting"? Turns out it is a word, but an archaic one. > > It's been changed to "interpreting" in the Forth 2012 document which > supersedes the ANS Forth document. Of course, if there weren't any typos to catch we wouldn't be reading this version. lol -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-30 17:00 -0700 |
| Message-ID | <e5b45028-b7c4-411c-abff-b85915c0eaf6@googlegroups.com> |
| In reply to | #42268 |
On Wednesday, September 30, 2015 at 12:32:45 AM UTC-7, Elizabeth D. Rather wrote:
> On 9/29/15 7:03 PM, Chris Curl wrote:
> > ...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.
What does "virtually all" mean? Some ANS-Forth compliant systems do one thing, and some do another thing --- this is just another word for "ambiguous."
You don't understand what the concept of portability means --- this is why you failed so badly at writing a language standard --- the whole purpose of a language standard is so programs will be portable.
> 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.
ANS-Forth actually violates almost all of the common practice of decades of Forth programming. In my previous post I discussed how words such as IF that were always immediate can now be non-immediate, and how tick and FIND are now completely screwed up although they were a fundamental aspect of Forth from the very beginning.
Another example of common practice is the use of { to define locals. This predates ANS-Forth and has been in use for over two decades. You hate locals though; you have infamously said: "I hate locals :-)" The smiley face is part of the quote. Because of this, SwiftForth doesn't provide { but instead uses { for multi-line comments.
So, Forth-200x wants a new way to define locals because the parameters are backwards in LOCALS|. They can't use { however, despite the fact that { has been common practice for over 20 years. Instead they have to change the name to {: so SwiftForth can continue to use { for multi-line comments. This means that everybody in the Forth community has to rewrite all of their legacy code to use {: rather than { just so Forth Inc. can continue to use { for multi-line comments.
Quite humorously, VFX now allows both { and {: for defining locals! That has got to be confusing for novices. They see some code that uses { and some code that uses {: and they wonder what the difference is. But there is no difference!
Once again, Forth Inc. manages to take something simple that has been done for decades, and completely screw it up.
Writing a standard is not all that difficult. Most of these decisions are easy and obvious --- yet, Forth Inc. screws up every decision every time.
> 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.
It was Forth Inc. that screwed up the Forth-83 standard, then Forth Inc. screwed up the ANS-Forth standard, and now Forth Inc. is screwing up the Forth-200x standard --- definitely a pattern there!
> 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.
This is total baloney! You have never written a Forth program in your life -- you are a salesperson.
Every code example that you have posted on comp.lang.forth was copied directly out of the "Starting Forth" book, with only one exception:
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;
> 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.
Why are you so strongly of the opinion that people learning Forth should not read the ANS-Forth document? Is it because you are embarrassed by all of the ambiguity? I totally agree with you though --- I also recommend that novices not read the ANS-Forth document --- I recommend that nobody read the ANS-Forth document.
The "constraints under which a standard operates" are all of the political concessions that you made to get Forth compiler-writers to sign on to the ANS-Forth standard, despite the fact that all of their Forth systems were incompatible with each other --- this "introduces too many ambiguities."
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-30 20:38 -0400 |
| Message-ID | <op.x5sxe8ofyfako5@localhost> |
| In reply to | #42288 |
On Wed, 30 Sep 2015 20:00:34 -0400, <hughaguilar96@gmail.com> wrote: > [blah] We're still waiting for Hugh-Forth ... RP -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-10-02 14:37 -0400 |
| Message-ID | <mumiu1$nhp$1@speranza.aioe.org> |
| In reply to | #42288 |
On 30/09/2015 8:00 PM, hughaguilar96@gmail.com wrote: > Writing a standard is not all that difficult. Most of these > decisions are easy and obvious Hugh, Why not write a standard for forth and create a set of conforming test suites. It is actually a serious suggestion not a rhetorical comment. You have spent quite a bit of time criticizing existing efforts and are forth knowledgeable put both knowledge bases to work. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-02 17:01 -0400 |
| Message-ID | <mumr7l$gth$1@dont-email.me> |
| In reply to | #42319 |
On 10/2/2015 2:37 PM, Walter Banks wrote: > On 30/09/2015 8:00 PM, hughaguilar96@gmail.com wrote: > >> Writing a standard is not all that difficult. Most of these >> decisions are easy and obvious > > Hugh, > > Why not write a standard for forth and create a set of conforming test > suites. It is actually a serious suggestion not a rhetorical comment. > > You have spent quite a bit of time criticizing existing efforts and are > forth knowledgeable put both knowledge bases to work. Yes, he who makes the suggestion gets to bell the cat. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-02 23:35 -0700 |
| Message-ID | <8a36933a-0f8c-4e94-a2cb-ff59d7af9fc4@googlegroups.com> |
| In reply to | #42319 |
On Friday, October 2, 2015 at 11:37:57 AM UTC-7, Walter Banks wrote:
> On 30/09/2015 8:00 PM, hughaguilar96@gmail.com wrote:
>
> > Writing a standard is not all that difficult. Most of these
> > decisions are easy and obvious
>
> Hugh,
>
> Why not write a standard for forth and create a set of conforming test
> suites. It is actually a serious suggestion not a rhetorical comment.
>
> You have spent quite a bit of time criticizing existing efforts and are
> forth knowledgeable put both knowledge bases to work.
>
> w..
I could fairly easily write a standard-document. It would be similar to the ANS-Forth document with the following differences:
1.) No use of the word "ambiguous" as that doesn't standardize anything.
2.) No use of the word "may" as that doesn't standardize anything. An example is the infamous section 3.2.3.2.. Another example: "For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."
3.) No ambiguity in compilation. An example is Anton Ertl's {: that initializes the local right of the | to whatever happened to be in memory previously. Another example is that the word "align" isn't defined in ANS-Forth, so ALIGN can align to cell-size or align to 1, or align to anything else, and so data doesn't compile the same from one system to another.
4.) It would follow common practice, such as in defining locals using the John Hopkins format, rather than LOCALS| that was never used before (if it had been used, somebody would have noticed that the parameters were backwards).
5.) It would define words like D/ and SMUDGE (or something similar to SMUDGE) that need to be written in assembly-language by the compiler-writer, but are either grossly inefficient when written in Forth by the user or can't be written without carnal knowledge.
6.) It would support cross-compilation as an inherent aspect of the language.
7.) It would support quotations.
Anyway, all of this seems easy to me. The reason why I haven't done it, is because I don't want to do what Elizabeth Rather did with ANS-Forh, which is publish a standard-document and declare it to be the standard, without having written a reference compiler for it so that it could be tested by the people who are expected to either accept or reject it.
I've got a lot of the compiler written in FASM, but there is a huge amount of programming involved in writing a commercial-quality compiler (the development of the MiniForth processor, the writing of MFX, and the writing of the motion-control program took most of a year with three people working full-time). I work for a plumbing company now, so I only have time available in the evenings after work and on the weekends, so it just takes a while to write all of this.
Another factor here is that I don't want it to be open-source because it will just get stolen. I have already seen Marcel Hendrix post my code on comp.lang.forth with my name removed from the copyright notice (later on he said: "(I don't know what it is designed to do"), and all of the comp.lang.forth leadership said that this was acceptable. If I make it open-source, a lot of people will make minor modifications to it (likely screwing it up) and claim that they improved it, so pretty soon there will be multiple incompatible versions and multiple people declaring authorship. I'm not really such an altruist that I want to program for free, especially if I"m not going to be given any credit, and this will be the result if it is open-source. OTOH, if I make it closed-source nobody will use it except me so I might as well not make it available at all.
The whole thing seems pointless --- there are maybe 20 Forth programmers remaining on the planet, and all of them are over 40 years old, and none of them have any money --- there is no market for Forth, and there hasn't been since 1994.
As an example of the typical attitude toward Forth, I got only one response to my mention of the FMITE processor on this forum:
https://embdev.net/topic/370139
---------------------------------------------------------------------------
Looks like pure academic fun to me.
But you don't seriously expect us to fully read and understand your
entire text file, do you?
We do share a lot of academic fun, but I guess you'll have to a wee bit
of 'marketing' and tell us what your processor is good at.
Bytecode stuff is interesting, but eventually people will care about
robustness and how easy they can achieve their goal. Programming aspects
DO count, and you'll get very little attention from the industry by
using Forth..
---------------------------------------------------------------------------
AFAIK, only three people have read my FMITE document and only one of them understood it --- but several people who haven't read it have denounced it on comp.lang.forth and/or have made straw-man arguments against it claiming that it is something that it isn't --- these same numbers would be my expectation for a Forth standard document.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-30 18:11 -0400 |
| Message-ID | <op.x5sqlnljyfako5@localhost> |
| In reply to | #42266 |
On Wed, 30 Sep 2015 01:03:32 -0400, Chris Curl <ccurl609@gmail.com> 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. > ' (tick) for fig-Forth used -FIND and appears to have left a clean stack. -FIND is an immediate which compiles the xt directly. -FIND ( pfa b ft | ff ) Other Forth's might use a sequence similar to this for ' (tick) to work with ANS' FIND: : ' BL WORD FIND DROP ; " 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. " - ANS 94 So, it's likely that c-addr, the original address of the counted string to be found by FIND, will be returned or remain on the stack if a user "fat-fingers" tick, unless an extra IF-ELSE is used to check the state of the flag to also DROP c-addr. Obviously, this depends on the implementation. BTW, when posting to Usenet via Google Groups, your lines should be wrapped at 72 to 75 characters. I fixed your line lengths for you. You might consider wrapping them even shorter so that a few levels of replies indent correctly. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-10-01 02:13 +0200 |
| Message-ID | <1pjvlwmqiq2ii$.amvgjx5cpz1h$.dlg@40tude.net> |
| In reply to | #42284 |
Op Wed, 30 Sep 2015 18:11:37 -0400 schreef Rod Pemberton: <snip> > ' (tick) for fig-Forth used -FIND and appears to have > left a clean stack. -FIND is an immediate which compiles > the xt directly. Wrong, ' (tick) was immediate, not -FIND. : ' -FIND 0= 0 ?ERROR DROP [COMPILE] LITERAL ; IMMEDIATE When compiling it compiled the PFA as literal and when interpreting it left the PFA on the stack. INTERPRET converted the PFA to a CFA for compiling c.q. executing. What do you mean with 'clean stack'? FIGFORTH (about 1978) did not know about xt's (execution tokens). That is a term in DPANS94. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-09-30 08:38 +0100 |
| Message-ID | <mug3dh$bgg$1@dont-email.me> |
| In reply to | #42260 |
On 30/09/2015 01:15, 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 :). > It is perfectly possible to write portable programs in ANS Forth and Forth 2012. You just have to be aware of various aspects of standard Forth that can trip you up such as the compiler leaving control information on the data stack. Such things are usually a legacy of the early days of Forth when machine resources were limited [1]. I don't like many of the restrictions and my system doesn't have most of them but I choose to take account of them as I'd rather my programs are portable. I routinely run my programs on a number of Forths (my system, GForth, VFX, SwiftForth, Win32 Forth, iForth) with few problems. There are standard libraries available e.g. the Forth Foundation Library, the Scientific library (I believe), Hugh's Novice package. To me the question on whether to follow the standard or not is simple to answer, if you want to write software that you want to be used by others, (or post code on c.l.f that will be understood by others) follow the standard. If not, don't, do your own thing, plenty of others do this already - nobody here will worry overmuch one way or the other. Incidentally many of Hugh's assertions and claims are not answered or challenged by the regulars here because experience has shown that responding to Hugh is a waste of time. I suspect that most just ignore him because of his rants about Elizabeth Rather, and people on the Forth 20XX committee that are so frequent and repetitive that they have become boring. This is a pity as technically he has a lot to offer but anything good is buried in the noise. [1] This is ironic because the standard was written with the restrictions so that it could accommodate both small and large systems, but Forths on resource limited processors tend not to obey the standard anyway. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-09-30 10:58 -0400 |
| Message-ID | <mugtbj$n3e$1@speranza.aioe.org> |
| In reply to | #42269 |
On 30/09/2015 3:38 AM, Gerry Jackson wrote: > On 30/09/2015 01:15, 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 :). >> > > It is perfectly possible to write portable programs in ANS Forth and > Forth 2012. You just have to be aware of various aspects of standard > Forth that can trip you up such as the compiler leaving control > information on the data stack. Such things are usually a legacy of > the early days of Forth when machine resources were limited [1]. I > don't like many of the restrictions and my system doesn't have most > of them but I choose to take account of them as I'd rather my > programs are portable. I routinely run my programs on a number of > Forths (my system, GForth, VFX, SwiftForth, Win32 Forth, iForth) with > few problems. > > There are standard libraries available e.g. the Forth Foundation > Library, the Scientific library (I believe), Hugh's Novice package. > Many of the portability standards arguments are a strawman arguments. Standards are mostly designed to codify existing practice and serve as a review process for what is currently being done, this is often confused with language design which it is not. It isn't just forth other standards have the same problem with people often (correctly) stating that they have a better way to do something or that the definition should be changed. Experience writing standards has universally found that a good test for new ideas is acceptance by the user community. Acceptance then by standards committees is generally easy. If an idea has merit it will be used and will become part of the user standard. One final comment. Few who haven't served on a standards committee appreciate how much work it takes to produce a standard. w..
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-10-01 06:04 -0700 |
| Message-ID | <4ea0ed90-132f-47ec-95a4-37d1751e5645@googlegroups.com> |
| In reply to | #42204 |
So if ' always ABORTs, then why not just state that in the standard and be done with it? It would have caused me less confusion, and saved us all the last couple of days worth of bickering. Going forward, when perusing the standard, when I see "an ambiguous condition exists", should I take that to mean "expect it to ABORT"?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-01 09:46 -0400 |
| Message-ID | <mujdbb$7ad$1@dont-email.me> |
| In reply to | #42301 |
On 10/1/2015 9:04 AM, Chris Curl wrote: > So if ' always ABORTs, then why not just state that in the standard and be done with it? It would have caused me less confusion, and saved us all the last couple of days worth of bickering. Trust me, there is nothing anyone can do to prevent the bickering by the likes of Hugh and a few others here. So please don't blame that on the standard. BTW, the behavior is *not* to always abort. I thought that was made abundantly clear by the many posts on it. > Going forward, when perusing the standard, when I see "an ambiguous condition exists", should I take that to mean "expect it to ABORT"? Or maybe you could actually *read* the standard... 3.4.4 Possible actions on an ambiguous condition When an ambiguous condition exists, a system may take one or more of the following actions: – ignore and continue; – display a message; – execute a particular word; – set interpretation state and begin text interpretation; – take other implementation-defined actions; – take implementation-dependent actions. The response to a particular ambiguous condition need not be the same under all circumstances. You are welcome. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-08 06:07 +0000 |
| Message-ID | <2015Oct8.080721@mips.complang.tuwien.ac.at> |
| In reply to | #42301 |
Chris Curl <ccurl609@gmail.com> writes:
>So if ' always ABORTs, then why not just state that in the standard and be done with it?
It does not always abort. And ' IF does not always ABORT, either. On
Gforth it produces an exception; on SwiftForth it produces an xt that,
when EXECUTEd, performs the compilation semantics of IF; on VFX it
produces an xt that behaves differently.
> It would have caused me less confusion, and saved us all the last couple of days worth of bickering.
There is lots of bickering about things that are stated clearly in the
standard, including what can happen upon an ambiguous condition.
>Going forward, when perusing the standard, when I see "an ambiguous condition exists", should I take that to mean "expect it to ABORT"?
No. It just means that standard programs should not rely on any
particular behaviour in that case, and as a programmmer you should
therefore probably avoid it. If you want to write such programs,
sure, it would be nice if there was a system that told you whenever an
ambiguous condition occurs; I think Jonah Thomas wrote a system with
that goal, and Peter Knaggs' recent systems also seem to be in that
direction.
Gforth produces exceptions for ambiguous conditions that that we did
consider to be likely portability errors and that it can easily
detect; in case of doubt, we rather go for the exception (e.g., ' IF).
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-10-09 04:04 -0700 |
| Message-ID | <fe2b3eef-27b9-4c20-ac3b-a62bc4120acd@googlegroups.com> |
| In reply to | #42445 |
On Thursday, October 8, 2015 at 2:23:36 AM UTC-4, Anton Ertl wrote: > Chris Curl <ccurl609@gmail.com> writes: > >So if ' always ABORTs, then why not just state that in the standard and be done with it? > > It does not always abort. Does this mean I have to rewrite ' in my implementation? Right now it's: : ' abort ;
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-09 10:29 -0400 |
| Message-ID | <mv8it7$u0e$2@dont-email.me> |
| In reply to | #42489 |
On 10/9/2015 7:04 AM, Alfred Singlestone wrote: > On Thursday, October 8, 2015 at 2:23:36 AM UTC-4, Anton Ertl wrote: >> Chris Curl <ccurl609@gmail.com> writes: >>> So if ' always ABORTs, then why not just state that in the standard and be done with it? >> >> It does not always abort. > > Does this mean I have to rewrite ' in my implementation? Right now it's: > > : ' abort ; No, I think that is a good definition. Or you could be fancy and call it a "disambiguifier". -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-09 15:30 +0000 |
| Message-ID | <2015Oct9.173041@mips.complang.tuwien.ac.at> |
| In reply to | #42489 |
Alfred Singlestone <vitonis@gmail.com> writes:
>On Thursday, October 8, 2015 at 2:23:36 AM UTC-4, Anton Ertl wrote:
>> Chris Curl <ccurl609@gmail.com> writes:
>> >So if ' always ABORTs, then why not just state that in the standard and be done with it?
>>
>> It does not always abort.
>
>Does this mean I have to rewrite ' in my implementation? Right now it's:
>
>: ' abort ;
If you want your system to be standard, then yes, you have to rewrite it.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-10-03 00:19 -0700 |
| Message-ID | <dfba1750-e8c9-42ac-b619-983cfbe9b4ed@googlegroups.com> |
| In reply to | #42204 |
Den söndag 27 september 2015 kl. 00:18:01 UTC+2 skrev Chris Curl: > Hi ... I am new to the group, but not to programming. 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. Since then, pretty much all of my programming has been in C/C++. > > Anyway, I recently started thinking about robotics and AI and how FORTH is uniquely positioned to be able to learn new tasks and terms. So 30 years later ... I'm back! > > Being a programmer, I started by writing my own flavor of FORTH in C++ (using VS 2013) that gives me a starting point. It implements a very simple FORTH virtual machine with only 30 primitive instructions and a few C++ methods that implement the VM. Everything else bootstraps from that. > > Anyone interested in it is welcome to peruse the code, which is hosted on GitHub (http://github.com/CCurl/FORTH). I am actively working on it currently. I first learn about programming 1970 in a one week course about Algol and numerical methods. My first programming experience come from programmable HP Calculators and Basic on TI-99/4A. First programming was amazing but soon it become tiresome to find out what was possible and how to realize possibilities. A lot of time was spent in how to cheat the system to let me do what I wanted to do. And weeks of experiments could end in the conclusion that it simply wasn't possible. At least not for me! Then Forth came as a liberator. Old habits, though, made me explore the system to examine the cheating possibilities. I learned the very simple Fig-Forth rather quickly while making a "decompiler" and found out there was absolutely nothing there to cheat. I could do virtually anything that I could visualize in my mind. Wow! I just had to go forth and since then I have never been seriously interested in any other computer language. Forth programming is real fun. But then I become aware of a Forth-79, that "forbidden" me to do certain things for the benefit of compatibility... This "hughag...@gmail.com" certainly seems to be a grumpy waste of space, but I think he has a lot of good ideas. For example the idea that a forth standard should be a minimal kernel without structures and all the other things that easily can be added in each system. Then there might be a standard that doesn't change from year to year. Go Forth - but where to go? The simplicity and freedom of forth is like the power of nature: you can't force it into a certain form, it will grow up through the asphalt and widening all cracks in walls. Rather Forth will crystallize, and develop that way. My hope is that Forth will crystallize into a future operating system, stored in some kind of memory device to which you can attach things like computers, screens and modems...
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web