New to the group

[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.

[menti...@gmail.com]

On Saturday, September 26, 2015 at 3:18:01 PM UTC-7, Chris Curl wrote:
> [...] I recently started thinking about robotics and AI [...]
> http://github.com/CCurl/FORTH [...]

Welcome to the premier Usenet AI & robotics group.

Bye for now.

Arthur T. Murray/Mentifex
--
http://www.amazon.com/dp/B007ZI66FS
http://www.nlg-wiki.org/systems/Mind.Forth
http://dl.acm.org/citation.cfm?doid=307824.307853
http://aihub.net/artificial-intelligence-lab-projects

[hughag...@gmail.com]

On Saturday, September 26, 2015 at 3:18:01 PM UTC-7, Chris Curl wrote:

If you are interested in application programming in Forth, then you can use my novice package: http://www.forth.org/novice.html

You seem to not be interested in application programming however, but are instead interested in writing a Forth interpreter in C --- these are mutually exclusive interests.

[Paul Rubin]

Chris Curl <ccur...@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).

[Chris Curl]

On Sunday, September 27, 2015 at 12:16:40 AM UTC-4, hughag...@gmail.com wrote:
> You seem to not be interested in application programming however, but are instead interested in writing a Forth interpreter in C --- these are mutually exclusive interests.

I have many interests :). My main interest is satisfying my intellectual curiosity.

Last night, I read about Charles Moore, his philosophy, and the evolution of Forth. For him, building the tool was part of building the application. I guess I'm sort of like him, at least in that way.

[Chris Curl]

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!

[Chris Curl]

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.

[rickman]

I have read some about Chuck, but I can't say I've ever found a clear
summary of his philosophy. What did you find?

The tools *are* part of the application. When I write VHDL code I have
to spend as much time with the test bench as I do the application code.
When I design a board I have to develop a way to test it, both in
debug and in production.

The thing being built needs an ecosystem.

--

Rick

[Chris Curl]

On Sunday, September 27, 2015 at 2:43:26 PM UTC-4, rickman wrote:
> I have read some about Chuck, but I can't say I've ever found a clear
> summary of his philosophy. What did you find?

What I read was here, on the right of the page.
http://www.forth.com/resources/evolution/index.html

[Elizabeth D. Rather]

This may help: The Evolution of Forth
http://www.forth.com/resources/evolution/index.html
Presented at the ACM SIGPLAN History of Programming Languages Conference
(HOPL II, April, 1993). Published in ACM SIGPLAN Notices, Volume 28, No.
3 March 1993.

As conceived, Forth *is* an ecosystem. For most of the first couple of
decades, Forth on a mini- or micro-computer provided everything as a
standalone environment: multitasking OS, editor, compiler, assembler,
and growing application.

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."
==================================================

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I have read some about Chuck, but I can't say I've ever found a clear
> summary of his philosophy. What did you find?

http://www.ultratechnology.com/1xforth.htm

is interesting. Talking of Forth cpus:

The goal was very simple: to minimize the complexity of the hardware
software combination. As far as I can see no-one else is doing
that. Some lip service perhaps, but no-one is trying to minimize the
complexity of anything and that is a great concern to me.
...
Forth doesn't need to be complicated. Classic Forth started out
simple, it gradually accreted layers of complexity. At Forth
Inc. that kind of became the company culture. We had this package
and we were selling it and we were exploiting it and we were stuck
with it. When I left Forth Inc. I had a chance to simplify and
cmForth was the result. Unfortunately cmForth didn't get used for a
lot of applications. So it is hard to tell how well it would have
worked out.
...
About a thousand instructions seems about right to me to do about
anything. To paraphrase the old legend that any program with a
thousand instructions can be written in one less. All programs
should be a thousand instructions long.

[hughag...@gmail.com]

On Sunday, September 27, 2015 at 5:00:27 PM UTC-7, Paul Rubin wrote:
> rickman <gnu...@gmail.com> writes:
> > I have read some about Chuck, but I can't say I've ever found a clear
> > summary of his philosophy. What did you find?
>
> http://www.ultratechnology.com/1xforth.htm
>
> is interesting. Talking of Forth cpus:
>
> The goal was very simple: to minimize the complexity of the hardware
> software combination. As far as I can see no-one else is doing
> that. Some lip service perhaps, but no-one is trying to minimize the
> complexity of anything and that is a great concern to me.

The MiniForth was built on a Lattice isp1048 PLD --- I've never heard of anybody else building any kind of processor on a PLD --- that was in 1994.

[rickman]

It has been done. You obviously don't run in the hardware circles.

BTW, you need to call them CPLDs. To most people PLDs are a generic
term for *all* programmable logic devices. The really small parts are
most commonly called PALs or GALs and the remaining group is called
FPGAs which I assume is what you intended to distinguish the isp1048 from.

Designing a useful processor in such a small device is an accomplishment
for sure. But it is one of those accomplishments that go in the books
next to cramming the most college sophomores into a telephone booth
really as it is only a useful accomplishment for a short time until much
more capable devices become quite affordable. These days you can get a
1024 LUT FPGA for under $3 which is likely much lower power than the
isp1048 and includes memory, etc.

--

Rick

[jf...@ms4.hinet.net]

> The MiniForth was built on a Lattice isp1048 PLD --- I've never heard of anybody else building any kind of processor on a PLD --- that was in 1994.

That's amazing! To squeeze a Forth CPU into a CPLD with only 48 GLBs is really something, not to mention this isp1000 series has limited routing resources. Cool!

--Jach

[hughag...@gmail.com]

Well, I didn't do it personally --- I don't actually know anything about electronic hardware --- all I did was write MFX (cross-compiler, assembler and simulator).

I remember that routing was a big problem. Small seemingly trivial changes in the design would cause it to not route anymore. Getting it to route was largely done by guess and by golly --- routing is an intractable problem --- there is no algorithmic solution.

The MiniForth actually fit on a isp1032, but when you did that there was no I/O at all. As a practical matter, the isp1048 was needed. It has been upgraded to an FPGA since then and the name changed to RACE, so it is several times faster and has several times less power-consumption. Testra no longer uses their own HDL that they wrote in Forth, but they have switched to VHDL instead.

It doesn't really matter very much. In 1995 when the MiniForth went into production, everybody was talking about the new ANS-Forth standard, and what they were saying was: "Goodbye!" After ANS-Forth came out, the Forth community collapsed --- everybody just switched to C (Open Boot switched to C in 1995, which was a huge blow to the Forth community) --- nobody was interested in Forth anymore.

If the MiniForth had come out just one year earlier, before ANS-Forth became the standard, the MiniForth could have saved the Forth language from extinction. People would have had a Forth processor that was competitive in the real world (the MiniForth was competitive against the MC68000 that the competition in the laser-etching field were using). As it was, ANS-Forth made incompetence the new "Standard" and everybody abandoned Forth --- my MFX was non-standard, so it was just an also-ran. C programmers could dismiss my work off-hand by saying: "If MFX is so wonderful, why isn't it the Standard with a capital 'S'? Your own Forth community has indicted you!"

ANS-Forth was like that meteor that killed off the dinosaurs, except that instead of a big rock, it was a gigantic turd that landed on our heads --- now we have Forth-200x that is mandated to be 100% compatible with ANS-Forth --- more of the same!

[Chris Curl]

On Sunday, September 27, 2015 at 10:37:26 PM UTC-4, hughag...@gmail.com wrote:
> ANS-Forth was like that meteor that killed off the dinosaurs, except that instead of a big rock, it was a gigantic turd that landed on our heads --- now we have Forth-200x that is mandated to be 100% compatible with ANS-Forth --- more of the same!

Great insight. Here we had a truly unique thing that could morph into anything, and change the trajectory of programming. And they killed it because they wanted to control it. What a shame.

Suffice to say that my implementation will be what I want it to be, not what some committee decrees.

[Elizabeth D. Rather]

The reports of Forth's death are wildly exaggerated, especially by Hugh.

[hughag...@gmail.com]

On Sunday, September 27, 2015 at 10:02:21 PM UTC-7, Elizabeth D. Rather wrote:
> On 9/27/15 5:53 PM, Chris Curl wrote:
> > On Sunday, September 27, 2015 at 10:37:26 PM UTC-4, hughag...@gmail.com wrote:
> >> ANS-Forth was like that meteor that killed off the dinosaurs, except that instead of a big rock, it was a gigantic turd that landed on our heads --- now we have Forth-200x that is mandated to be 100% compatible with ANS-Forth --- more of the same!
> > Great insight. Here we had a truly unique thing that could morph into anything, and change the trajectory of programming. And they killed it because they wanted to control it. What a shame.
> >
> > Suffice to say that my implementation will be what I want it to be, not what some committee decrees.
> >
>
> The reports of Forth's death are wildly exaggerated, especially by Hugh.
>
> Cheers,
> Elizabeth

Well, Testra has spent the last 20 years selling motion-control boards based on the RACE processor. AFAIK however, MFX has never been used outside of Testra and the only program that was ever written in it was the motion-control program.

Nobody wants to touch Forth because ANS-Forth is the Standard (with a capital 'S') and ANS-Forth is really no good for anything.

Actually, the ANS-Forth document could be good as the lyrics in a song. Consider section 3.2.3.2:

"The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed."

If you put words like this to music, you might have something salable! Do you play the banjo?

ANS-Forth was just a marketing gimmick intended to convince the world that Forth Inc. sets the standard for the entire Forth community. ANS-Forth was pushed through to ANSI in 1994 without ever being tested. It couldn't be tested in 1994, because there was no ANS-Forth compiler available until 1997. This was SwiftForth, and it was too bug-ridden to be usable. Up through version-2, SwiftForth would crash every time that (LOCAL) was used --- this bug didn't get fixed until version-3 --- but Elizabeth Rather refuses to provide version-3 to the poor fools (me, for example) who paid over $400 for version-2. For Elizabeth Rather, it is all about the money, and scamming customers is just something that she does every day.

In the 1980s Forth was a big pond. There were a lot of Forth programmers, and Forth was considered to be more promising than C as the language of personal-computers. In those days, C was associated entirely with Unix($$$), but there were already several versions of Forth available for every personal-computer. Elizabeth Rather couldn't accept being a small fish in a big pond though --- she wanted Forth Inc. to be a big fish in a small pond --- all that she cared about was pushing ANS-Forth through ANSI so that Forth Inc. would appear to be the leader of the Forth community, but when she was done there was no Forth community remaining.

She has spent the last 20 years presenting herself as the "leading expert" on Forth. On the Forth Inc. website she describes herself like this:

"Elizabeth Rather is the co-founder of FORTH, Inc. and is a leading expert in the Forth programming language. Elizabeth was a colleague of Chuck Moore back when he worked at NRAO in the early 1970s. During his development of Forth, she became the second ever Forth programmer. Since then, she has become a leading expert in the language and one of its main proponents. Elizabeth was the chair of the ANSI Technical Committee that produced the ANSI Standard for Forth (1994). She is an author of several books on Forth and gives regular training seminars on its usage."

Recently she said this:

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 + ;

Well, Chris, if you have at least one week of experience programming in Forth, you should be able to point out most of the problems with Elizabeth Rather's code. The point that I'm making, is that Elizabeth Rather is not a Forth programmer --- she has never written a Forth program in her life --- she knows as much about technology as any salesperson does, which is nothing.

You should be able to easily write a better array definer than Elizabeth Rather is capable of writing. But it is a waste of time anyway! As a newbie, you should be focusing your mind on writing application programs. Writing low-level code such as an array definer is boring --- if you are going to succeed as a Forth programmer, you have to succeed at writing application programs (even getting a simple program to work is a huge confidence builder for a newbie) --- too many newbies get bogged down with implementing data-structures and they quit Forth before having ever written even one simple application program.

[Chris Curl]

On Monday, September 28, 2015 at 2:33:48 AM UTC-4, hughag...@gmail.com wrote:
> Well, Chris, if you have at least one week of experience programming in Forth, you should be able to point out most of the problems with Elizabeth Rather's code. The point that I'm making, is that Elizabeth Rather is not a Forth programmer --- she has never written a Forth program in her life --- she knows as much about technology as any salesperson does, which is nothing.

My purpose was to introduce myself to the group, not cause friction.

> ... Writing low-level code such as an array definer is boring --- if you are going to succeed as a Forth programmer, you have to succeed at writing application programs (even getting a simple program to work is a huge confidence builder for a newbie) --- too many newbies get bogged down with implementing data-structures and they quit Forth before having ever written even one simple application program.

My goal is not to 'succeed as a Forth programmer'. and I doubt if this little foray will turn into anything worth using or not. My goal is simply to satisfy my intellectual curiosity. Developing my very own Forth, one that I have complete control over and that I can take wherever I choose part of the journey for me. Don't worry, I'm NEVER bored.

[Roelf Toxopeus]

On 28/09/15 05:53, Chris Curl wrote:
> On Sunday, September 27, 2015 at 10:37:26 PM UTC-4, hughag...@gmail.com wrote:
>> ANS-Forth was like that meteor that killed off the dinosaurs, except that instead of a big rock, it was a gigantic turd that landed on our heads --- now we have Forth-200x that is mandated to be 100% compatible with ANS-Forth --- more of the same!
> Great insight. Here we had a truly unique thing that could morph into anything, and change the trajectory of programming. And they killed it because they wanted to control it. What a shame.
>

Right enough is enough!

This is a damned lie and by repeating it ad infinite, it still won't
become the truth!

I've got this scalding hot cup of coffee here, would love to throw it ...

ANS allowed(!) all different kind of implementations. That's what it was
set up for, separating implementation from the application making words.
Quite a liberation from the straight jackets, for sure! The notion of
all the emerging new developments in the 1980's was inspiration.
Do some home work!

Behind the ANS facade, there's an ANS acknowledged very dynamic world of
Forth(ish) implementations. An unheard of plethora of systems emerged.
Take your pick or add one, ANS compliant or not, who cares. You can't
even say there's a 2d spectrum of extremes. It's a real living
multidimensional world in all directions. Totally different from 30
years ago.

Sadly there was one group of Forth users who could not get to grips with
this (even now): the ones who want every nut and bolt of the
implementation prescribed. Kind of similar to the preANS standards
(Forth 2012 committee don't fall in to this trap!)

Still those standards did not stop people from doing it differently. If
needed to avoid tiring unproductive discussions with obedient standard
followers, you could say you were using an interactive macro assembler
and be done with it. And thanks to ANS it's now recognized as Forth and
you can have fruitful conversations with other Forth(ish) users. Great,
progress.

Remember the "FORTH can't do 32bits" said by the eye blinker wearers.
Poor sods.

Hugh Aguilar, I'm amazed, he's sure lucky no one dragged him in court
for slander (yet)! Pretty obnoxious this guy!
You're new here apparently...

> Suffice to say that my implementation will be what I want it to be,
not what some committee decrees.
>

Good for you, keep up the good work. No one will stop you, why do you
think that? '1000's' have preceded you, including the major vendors.
There's nothing very special about it, sorry.
Neither worry about a Nacht und Nebel encounter with the Forth police,
stupid conspiracy theories withstanding.

Experienced active genuine Forth users wasting too much time trying to
do some damage control on CLF. And all for nothing, the shite won't stop
of course. CLF is more damaging to Forth than any Forth standard
published to date. Too many good people left, your loss.

... meanwhile the coffee is cold, my loss.

In utter anger and armed to the teeth, -r

[Chris Curl]

OK then.

I am building my own little interactive macro assembler that is similar to Forth in spirit and behavior. As I am not interested in familiarizing myself the standard, or making it play nicely with offerings from others, it is very unlikely that this little tool I am building for myself will be ANS Forth compliant.

Given that reality, is this group a good place for me? Or am I too far out on the fringes for you folks?

[foxaudio...@gmail.com]

Given the fact that the inventor of "Forth" re-wrote his language numerous times for his purpose at hand I believe you are in the right place.

The ANS/ISO standard, IMHO, simply allowed us to agree on some word names and
word behaviours and call that a standard system. The standard was tasked with
trying to standardize something that by design was a challenge to standardize
so they did a reasonable job. It is not legislation.

My favourite Chuck Moore quote is "Standards are great, everybody should have
one" :)

So I think you will find the group here open to your personal permutations of
these Forth concepts into tools that allow YOU to be productive. That's how
Forth started and the standard does not change that. If it helps you to
be standard great. If not, nobody has a right to critique you. You simply might
have to provide a little more explanation if you post code here.

That's my 2 cents Canadian, which is only 1p Sterling so take it for what it's worth.

BF

[Roelf Toxopeus]

On 28/09/15 16:18, Chris Curl wrote:
> OK then.

> I am building my own little interactive macro assembler that is similar to Forth in spirit and behavior.

Call it Forth if you think it's Forth. Hardly anyone anno 2015 will
dispute that, this is not preANS times.

> As I am not interested in familiarizing myself the standard,

and why should you

> or making it play nicely with offerings from others,

again why should you

it is very unlikely that this little tool I am building for myself will
be ANS Forth compliant.

Great to hear from one _using_ his/her tool.

> Given that reality, is this group a good place for me?

I don't know.

> Or am I too far out on the fringes for you folks?

Certainly not for me or many others IMHO, like I said there are a
gazillion number of different implementations (again ANS killed
nothing), ANS compliant or not. Amazing some of them. Personally I think
that's Forth strength. I love the diversity! Doesn't mean I'm interested
in using all of them or liking them, but that's irrelevant for their
existence.

I'm not criticizing what you do. It's going along with a profound lie
about ANS on which you reacted with:

" Here we had a truly unique thing that could morph into anything, and
change the trajectory of programming. And they killed it because they
wanted to control it. What a shame."

Look at the often selectively overlooked "E.6 Summary" from the ANS
document. FYI a very crude interpretation/summary: do what ever you feel
you should do. If you want portability, we're there to help you.

How in heavens sake could Forth be killed by that?

[Alfred Singlestone]

On Monday, September 28, 2015 at 10:18:43 AM UTC-4, Chris Curl wrote:

It sounds as if your spirit is similar to mine in this regard. I too have my own version of Forth, bootstrapped from assembly language. It is definitely not compliant with ANS Forth, I don't intend for it to be used by anyone but me, and at this point it's generally just to satisfy my own intellectual curiosity.

That said, I think it may be useful for further study. For example, it might come in handy for creating other languages. I've always wanted to give that a try.

As for this group: I'm brand-new to it too, so I don't have a lot to say about it in general. I can say that I find it interesting and provocative. Don't worry too much about the folks who seem to use it as a platform to pose on. :)

[rickman]

Welcome to the group.

If you have used newsgroups much you probably know that each group has
its problems. This group has a fair share of those who it is better to
just ignore. If you read back even just a bit you will see who has
tendencies to argue rather than discuss. Some are even a bit off and
can post some very irrational things.

Just trying to help. Feel free to reply to anyone you find interesting.
But it can raise the noise level without purpose.

--

Rick

[Chris Curl]

On Monday, September 28, 2015 at 11:23:43 AM UTC-4, Roelf Toxopeus wrote:
> Look at the often selectively overlooked "E.6 Summary" from the ANS
> document. FYI a very crude interpretation/summary: do what ever you feel
> you should do. If you want portability, we're there to help you.
>
> How in heavens sake could Forth be killed by that?

I hear you ... I think might have gotten a little carried away by an earlier post.

Now on to the fun stuff ... :)

[rickman]

Just to add my 2 cents worth, ANS also allows for exceptions to the
standard as long as those exceptions are documented. This might not
apply to every aspect of the system, but there is lots of wiggle room.

--

Rick

[Roelf Toxopeus]

Yes by all means!

May I say how great it is to see the documentation in your C++ source
code. Excellent, really, a first for me. A good example to follow.

Cheers, -r

[Chris Curl]

On Monday, September 28, 2015 at 2:32:07 PM UTC-4, Roelf Toxopeus wrote:
>
> Yes by all means!
>
> May I say how great it is to see the documentation in your C++ source
> code. Excellent, really, a first for me. A good example to follow.
>
> Cheers, -r

Documentation in my C++? You're a funny guy!

Seriously though .. maybe I've been doing this too long, but to me, my code is "intuitively obvious upon casual inspection", so it doesn't need to be explained with additional comments. I do put in notes about stuff that is likely to be not obvious 6 months from now.

[Roelf Toxopeus]

Sorry, I meant those notes. Together with your "intuitively obvious upon
casual inspection" makes it easier for a non native C++ speaker to
follow. Had to wrestle thru C++ code recently. The code was the only
documentation on the subject. Only non code text was the copyright
stuff. Gave me a splitting headache trying to follow the sprawling all
over the place code. Hence I was pleasant surprised to see your code.
I like that style ;-)

[Elizabeth D. Rather]

Compliance to a standard may not be relevant for your purposes, but you
can still learn a lot by spending a little time using a well-documented
existing Forth before diving in to your project. There are free
evaluation systems available from both FORTH, Inc. and MPE (the major
commercial system suppliers), as well as gForth.

[Chris Curl]

Thanks!

[jf...@ms4.hinet.net]

Roelf Toxopeus 2015/9/28 8:29:48 wrote：
> Hugh Aguilar, I'm amazed, he's sure lucky no one dragged him in court
> for slander (yet)! Pretty obnoxious this guy!

No one? Why? Why others have to do it for you?

It's sad that this world is full of people who always "hope" someone(maybe God?) will do something for them. They are physiological crippled people. Take a look at Bernd Paysan's motto: "If you want it done right, you have to do it yourself", it might cure you.

--Jach

[hughag...@gmail.com]

This is what the standard says (section 3.2.3.2 again):

"The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack. The format of the control-flow stack is implementation defined. Since the control-flow stack may be implemented using the data stack, items placed on the data stack are unavailable to a program after items are placed on the control-flow stack and remain unavailable until the control-flow stack items are removed."

This is what Elizabeth Rather says:

On Monday, September 28, 2015 at 2:41:38 PM UTC-7, Elizabeth D. Rather wrote:
> ...you

> can still learn a lot by spending a little time using a well-documented
> existing Forth

I find it remarkable that sales-people can deliver such preposterous lines seriously, as if they expect people to believe them --- I also find it remarkable that they always find people to believe them --- this is a sad commentary on human intelligence.

The ANS-Forth document is full of ambiguity. All of these ambiguous statements are the result of political concessions. That section 3.2.3.2 above tells me that some people contributing to ANS-Forth knew that the control-flow stack should be separate from the data-stack and they refused to lend their names to the ANS-Forth document if their Forth systems were made non-standard. So E.R. said something to the effect of: "Okay, fine, that is standard." But Forth Inc. has the control-flow stack the same as the data-stack, so that had to be standard too. But this is contradictory! Any code written to assume that the control-flow stack is separate from the data-stack will crash and burn when compiled on a system (SwiftForth) that has the control-flow stack the same as the data-stack. Similarly, we have section 6.1.1550 (the entry for FIND) that says:

"For a given string, the values returned by FIND while compiling may differ from those returned while not compiling."

This was a concession to allow cmForth to be ANS-Forth compliant. Most likely, the FIND in cmForth provided a different value inside of colon words rather than outside, because the search-order (the CONTEXT vocabulary) was different. This doesn't require an exception in the ANS-Forth document as shown above, because search-order is already documented elsewhere. Also, most likely, Charles Moore (author of cmForth) had not requested that cmForth be made ANS-Forth standard, as he has never shown any interest in ANS-Forth. Now we have this bizarre statement in the ANS-Forth document. Anton Ertl takes advantage of this to make FIND in gForth provide different values depending upon what STATE is at the time that FIND executes, providing a WTF??? moment for every Forth programmer in the world --- this is totally incompatible with every other ANS-Forth compliant Forth.

All of these ANS-Forth compliant Forth systems are incompatible with each other in myriad ways, because they interpret these ambiguous conditions differently, but they are all ANS-Forth compliant anyway. So, what what did the ANS-Forth standard accomplish, as compared to the situation if we didn't have any standard and everybody just did what they felt like doing?

Ultimately, being ANS-Forth compliant depends entirely upon Elizabeth Rather saying that you are ANS-Forth compliant, and it has nothing to do with compliance in the technical sense. If Chris Curl wants his home-brew Forth system to be ANS-Forth compliant, all he has to do is make big speeches on comp.lang.forth saying that Elizabeth Rather is the "leading expert" on Forth, and she will grant him ANS-Forth compliance quid-pro-bro --- he doesn't have to actually read the ANS-Forth document to be ANS-Forth compliant --- I recommend that he not read the ANS-Forth document because it will just turn his brain into mush (I know it has that effect on me, and I've been programming in Forth since 1984, so I can only imagine what it would do to somebody new to Forth). Intellectual curiosity is a good thing, but it is also true that curiosity killed the cat --- you have to be careful not taste any poison spewed by an idiot sales-person as it may turn your brain into mush.

All in all, ANS-Forth is a purely negative contribution to Forth programming --- I don't recommend ANS-Forth for anybody, neither novice nor expert.

[rickman]

I think you misunderstood what Roelf was saying. I will chalk it up to
the language barrier.

--

Rick

[hughag...@gmail.com]

On Monday, September 28, 2015 at 5:29:48 AM UTC-7, Roelf Toxopeus wrote:
> In utter anger and armed to the teeth, -r

I think that what mostly ruins standards is that the people involved get to be too full of themselves. They feel powerful because everything they do is Standard (with a capital 'S') and everybody must bow before them else be damned to non-standard hell.

The result is a lot of pseudo-intellectual nonsense. For example, consider this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/AcqnHxflT58%5B226-250%5D
Here we had this:

On Friday, September 25, 2015 at 3:59:09 AM UTC-7, Roelf Toxopeus wrote:
> On Jef Raskin's request I wrote PIXPUTTER in OF. Tell me if this is not
> Forth.
>
> <code>
> decimal
>
> 0 value myscreen
> " screen" open-dev to myscreen
>
> create saved-color 0 ,
>
> \ using color# 0 in table for our colored pixel
> : save-color ( -- )
> saved-color 0 1 s" get-colors" myscreen $call-method ;
>
> : restore-color ( -- )
> saved-color 0 1 s" set-colors" myscreen $call-method ;
>
> : !color ( r g b -- ) 0 s" color!" myscreen $call-method ;
>
> : pixel ( x y -- addr ) screen-width * + frame-buffer-adr + ;
>
> : (pixputter) ( x y r g b -- ) !color pixel 0 swap c! ;
>
> : PIXPUTTER ( x y r g b -- ) save-color (pixputter) restore-color ;
> </code>

Here we have the gratuitous use of OOP (common during the 1990s, not just in Open Forth). The $CALL-METHOD function is passed a string which is the name of a function. $CALL-METHOD has to look this string up in some kind of data-structure (most likely the dictionary itself, which is typically either a hash-table or a linked-list). It is doing this dictionary-lookup at run-time though! This is grossly inefficient! Especially mind-blowing about this code, is that there is only one instance of the SCREEN class, stored in the MYSCREEN global variable --- this is because there is only one physical screen attached to the computer --- all of this grossly inefficient OOP nonsense is totally pointless from a technical perspective.

So, what was the point of the OOP? Mostly, the point of the OOP is so the programmers can present themselves as being big computer-scientists. I can imagine myself going to a job interview in 1995 for an Open Forth job (in an alternate reality in which Open Forth didn't catastrophically fail in 1995). I would say: "I wrote MFX the development system for the MiniForth. The MiniForth was used in laser-etchers; it was both faster and less expensive than the MC68000 that the competition was using." Then Roelf Toxopeus the interviewer would say: "Did you use OOP?" I say: "Nope." Roelf then tells me that I'm not qualified to program in Open Forth, and out the door I go, and eventually Roelf hires somebody who is just as incompetent as he is and hence does not threaten Roelf's lofty position as big OOP priest. The point of OOP is that it is a club to beat people over the head with --- like any weapon, it is an "equalizer" --- the incompetent programmer armed with OOP can beat up the competent programmer (just as a weakling armed with a bat can beat up a strong man who is unarmed, especially if he catches him by surprise).

My reaction to Reolf's OOP usage in Open Forth reminds me of that Police song with these lyrics:
"Their eloquence escapes me,
Their logic ties me up and rapes me"

I feel the same way toward Forth-200x --- it has a lot of gratuitous complication that is pointless from a technical perspective --- the Forth-200x committee are a circle jerk, telling each other that they are mighty smart and pretending that the entire Forth community bows down before them.

This is not to say that I'm totally opposed to OOP --- it can be useful in some circumstances --- my novice package relies heavily on inheritance in the LIST.4TH and ASSOCIATION.4TH data-structures.

[Anton Ertl]

rickman <gnu...@gmail.com> writes:
>Just to add my 2 cents worth, ANS also allows for exceptions to the
>standard as long as those exceptions are documented. This might not
>apply to every aspect of the system, but there is lots of wiggle room.

And there are complaints about that, just as there are complaints
about it being too restrictive and not allowing, say, changing the
values of constants. I think there have been cases where the same guy
complained about the standard being too lax and too restrictive.

- 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/

[Chris Curl]

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.

[Mark Wills]

All true. Except that forth people done collaborate. They invent the same wheels over and over again independently. And odd course, they're all best :-;

[Chris Curl]

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.

[WJ]

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

[hughag...@gmail.com]

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.

[hughag...@gmail.com]

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!

[rickman]

LOL! If only we could all wish away those whose words offend us!

--

Rick

[WJ]

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

[Chris Curl]

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 :).

[jf...@ms4.hinet.net]

rickman 2015/09/29 12:51:22PM wrote：
> I think you misunderstood what Roelf was saying. I will chalk it up to
> the language barrier.

No, the language barrier is not that big to make me misunderstand.

This is what he said:
On 28/09/28, Roelf Toxopeus wrote:
> This is a damned lie and by repeating it ad infinite, it still won't
> become the truth!

You can't accuse someone of lying just because you don't agree with his opinion.
You can only accuse someone of lying by providing facts as the evidence, not by your opinion.

and here:

> I've got this scalding hot cup of coffee here, would love to throw it ...

This is a totally low-EQ reaction.

--Jach

[rickman]

On 9/29/2015 9:26 PM, jf...@ms4.hinet.net wrote:
> rickman 2015/09/29 12:51:22PM wrote：

>> I think you misunderstood what Roelf was saying. I will chalk it up to
>> the language barrier.
>

> No, the language barrier is not that big to make me misunderstand.
>

> On 28/09/15 05:53, Chris Curl wrote:
>> This is a damned lie and by repeating it ad infinite, it still won't
>> become the truth!
>

> You can't accuse someone of lying just bacause you don't agree with his opinion.

> You can only accuse someone of lying by providing facts as the evidence, not by your opinion.
>

>> I've got this scalding hot cup of coffee here, would love to throw it ...
>
> This is a totally low-EQ reaction.

And none of that has anything to do with your post I replied to which
you snipped.

The group is full of those who enjoy drama more than the technical
discussions. I'm not one so I'm not going to continue this discussion.

--

Rick

[rickman]

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

[Chris Curl]

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.

[Jan Coombs <Jan-54 >]

On Tue, 29 Sep 2015 18:26:43 -0700 (PDT)

jf...@ms4.hinet.net wrote:

> rickman 2015/09/29 12:51:22PM wrote：

> > I think you misunderstood what Roelf was saying. I will
> > chalk it up to the language barrier.
>

> No, the language barrier is not that big to make me
> misunderstand.
>
> On 28/09/15 05:53, Chris Curl wrote:
> > This is a damned lie and by repeating it ad infinite, it
> > still won't become the truth!

Misleading quote, Roelf wrote that. The problem is bigger than
a language barrier. Chris might be a bit upset as well.

However, I tend to agree with Roelf. My forth cannot comply with
the standard, but I still appreciate that most of the functions
in any forth can have an agreed name.

I don't think that standardisation has in any way been
detrimental to forth, as hughag...@gmail repeatedly claims.

Even if the standard had as many ambiguous or difficult name
choices as Chuck uses, I would still not accuse the standard
maintainers of dumping excrement on my head.

Allowing for a little difference in language I agree with
Roelf's stated posiion, but probably would want to avoid wasting
my coffee over it in either way.

Jan Coombs.
--
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[Elizabeth D. Rather]

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.

[Gerry Jackson]

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

[Gerry Jackson]

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

[Walter Banks]

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..

[Elizabeth D. Rather]

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.

[Rod Pemberton]

On Wed, 30 Sep 2015 01:03:32 -0400, Chris Curl <ccur...@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?

[hughag...@gmail.com]

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.

[hughag...@gmail.com]

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."

[Coos Haak]

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

[Rod Pemberton]

On Wed, 30 Sep 2015 20:00:34 -0400, <hughag...@gmail.com> wrote:

> [blah]

We're still waiting for Hugh-Forth ...


RP

[Rod Pemberton]

On Wed, 30 Sep 2015 19:21:04 -0400, <hughag...@gmail.com> wrote:

> 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.

Exactly.

Such situations are potentially exploitable by hackers depending on
what occurs for a specific Forth the "ambiguous" situation. The
result is that to ensure safety _all_ such situations should be
blocked, which most likely will cause Forth programs using established
historical Forth behaviors to crash, halt, hang, or function incorrectly.

Didn't you learn this already with your ANS experience?

> 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."

Yes, you almost need a STATE-aware Forth with another word like
IMMEDIATE or SMUDGE just to mark the "over 50" words with undefined
execution semantics. How else can you selectively enable and disable
execution semantics for these words? ... Anton is bound to respond
to this by stating that a STATE-aware Forth is not required.

> 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.

So, you disagree with Ms. Rather on Forth-83 being a bad standard?
It eliminated "ambiguous" situations by specifically defining the
integer sizes, etc.

> 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.

With "over 50" such words with "ambiguous" conditions, you'd really
have to wonder what the point of having a mandatory CORE and CORE EXT
set of words is, wouldn't you? ...

With roughly 133 CORE and 46 CORE EXT words, that would mean only
62% of CORE words and only 72% of CORE and CORE EXT are useable
interactively.

It would almost seem like they don't want you to use Forth
interactively anymore Hugh ...

I'm just waiting for you to stop ranting about Forth and
embrace C. Supposedly, you already programmed in C before.
So, I don't know why the delay in your conversion remains.


Rod Pemberton

[Elizabeth D. Rather]

On 9/30/15 3:03 PM, Rod Pemberton wrote:
> On Wed, 30 Sep 2015 19:21:04 -0400, <hughag...@gmail.com> wrote:
>
>> 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.
>
> Exactly.

Not so obvious. "Ambiguous conditions" generally fall into two categories:

1. Things that are basically errors but the correct response depends on
the application or the situation.

Example: attempt to divide by zero. In some circumstances, the correct
response might be to abort with an error message for the user; in others
(e.g., an embedded system with no user interface) it might be some other
recovery option altogether. Most systems use THROW codes for these, but
since CATCH/THROW is optional, it's not required.

2. Things that aren't normally allowed but which some implementations
might want to support in some fashion.

Example: using a compiler directive (such as IF) interactively. Most of
the time, IF compiles a forward branch and leaves the address of the
cell reserved for its destination on the stack to be filled by ELSE or
THEN. That makes no sense when you're just typing, so systems might wish
to issue an error message. But some systems, such as Open Firmware, let
you use structures (IF ... THEN, DO ... LOOP, etc.) either at the
keyboard or in program source, in which case they compile something
which is executed once at the end of the line and then thrown away. In
other words, it's an optional feature.

Generally, one shouldn't get fussed when reading that a certain
condition is "ambiguous." Just take the message as, "don't do that" and
(if you care) look at the documentation for the system in question to
see what it does.

[hughag...@gmail.com]

On Wednesday, September 30, 2015 at 10:34:27 PM UTC-7, Elizabeth D. Rather wrote:
> Generally, one shouldn't get fussed when reading that a certain
> condition is "ambiguous." Just take the message as, "don't do that" and
> (if you care) look at the documentation for the system in question to
> see what it does.

So, this explains why ticking IF causes gForth to abort --- I should have known: "don't do that!"

Perhaps you are explaining why IF does have an xt in VFX, but the xt will abort when executed (no matter what STATE is at the time) --- it is a non-executable execution-token.

Maybe you are explaining why FIND in gForth returns different xt values for IF depending upon what STATE is at the time that FIND executes.

All of this is allowed by the ANS-Forth document --- the bad thing about ambiguity is that anything can happen, but whatever happens is legal ANS-Forth.

Anyway, my disambiguifiers fix the problem.

[Mark Wills]

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!

[Elizabeth D. Rather]

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.

[rickman]

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

[rickman]

I'm sure I'm not the only one who is tired of Hugh's rantings on this
issue. IF does not have defined execution semantics. So why would
anyone expect IF to have an XT and if a value were returned by tick, why
would they expect it to do anything useful when executed?

--

Rick

[Chris Curl]

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"?

[rickman]

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

[hughag...@gmail.com]

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.

[Rod Pemberton]

I only like Hugh's rants when I can make fun of him ...
Of course, I also bring up important points which he ignores also.

But, all of that still doesn't mean his point was unimportant.

ISTM that older Forth standards would return the XT or equivalent
(PFA) for ' (tick) if the word was found in the dictionary and/or
vocabulary regardless of any execution semantics or immediacy etc.
Therefore, *NOT* returning an XT for a word that's in the dictionary
because it doesn't have any execution or interpration semantics would
seem to be a departure from the prior Forth standards and/or historical
Forth behavior. As Hugh noted, code which expects historical behaviors
may break with ANS since ANS apparently made little to no effort to
preserve such behaviors. I.e., his apparent claim that ANS code is
non-portable would seem to be valid in the sense that the code would
break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS
Forths anywhere in his claims.

[Elizabeth D. Rather]

In the first place, any standard can only offer portability across
conforming systems. Although the ANS Forth process tried to avoid
"breaking" Forth83 programs (and went to some lengths to document
changes so anyone would know), the fact that it can't guarantee
portability for pre-ANS programs shouldn't be unexpected or a source of
valid criticism.

Forth79's ' was state-smart; it performed the function of ['] if it
appeared in compilation mode. Forth83 fixed that. Neither addresses the
awkward question of what one can actually do with the "compilation
address" of a compiler directive such as IF. Odds are, if you type:

' IF EXECUTE

...you might get a branch compiled at the next available location in the
dictionary. If you aren't in the middle of a definition and in
compilation mode, that will be useless, and a source of great confusion.
On some systems, in fact, you might get an abort. On still others, you
might crash. In other words, it's hard to say what the "historical
behavior" in this case would even be.

The ANS Forth TC actually received quite a number of complaints about
difficulties caused by misunderstandings about what one can do with the
results of ' or ['] used on compiler directives, and spent a lot of time
discussing an appropriate solution, before finally concluding that it
was, in fact, an inappropriate thing to do in most systems, and
therefore the best solution was to define "compilation semantics"
(behavior during compilation) and "interpretation semantics" (behavior
during interpretation) and declare that compiler directives did not have
standard, defined interpretation semantics. Therefore, the standard
can't guarantee what will happen if you just type IF at the command
line. This is not, in fact, a change from prior standards, because what
would happen in that case was never clearly specified. It was *always*
ambiguous. What ANS Forth actually did was *warn* users of this situation.

[hughag...@gmail.com]

This is a total straw-man argument --- your typical strategy.

I wasn't trying to execute the xt of IF in interpretation mode, I was trying to execute the xt of IF in compilation mode, which has always worked prior to ANS-Forth.

This is the thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ

This is what I said:

On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote:
> : my-if [ ' if ] literal execute ; immediate ok
> : ttt ( flag -- ) my-if ." true " else ." false " then ;
> Err# -14 ERR: Attempt to interpret a compile only definition.
> -> : ttt ( flag -- ) my-if ." true " else ." false " then ;
> ^
> see my-if
> MY-IF (is IMMEDIATE)
> ( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
> ( 004C7A85 C3 ) NEXT,
> ( 6 bytes, 2 instructions )
> ok

My disambiguifiers fix this problem:

: if state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate

: my-if [ ' if ] literal execute ; immediate
: ttt ( flag -- ) my-if ." true" else ." false" then ;
1 ttt true
0 ttt false

You are twisting my words 180 degrees when you claim that I was trying to execute the xt of IF in interpretation mode --- you are a liar!

[Mark Wills]

On Friday, 2 October 2015 05:30:24 UTC+1, Rod Pemberton wrote:
I.e., his apparent claim that ANS code is
> non-portable would seem to be valid in the sense that the code would
> break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS
> Forths anywhere in his claims.
>

I think it's worse than that. We're in a situation where "ANS Compliant"
code runs differently on different *ANS compliant* systems. That's
untenable in my view. Though, in defence of the people that have worked
on the standards process over the years, it should be pointed out that
the situation is no better in the C or C++ worlds, and I'm sure there
are issues with other standardised languages too. One exception seems
to ADA as far as I can see. The specification for ADA is very tight.

[Elizabeth D. Rather]

Can you give some examples? Bear in mind that there are several
documented options (documented in Section 4.1) that the system must
describe, and an application must observe; the concept is that large or
complex applications that have environmental dependencies may need a
prologue to adapt to systems with environmental constraints or
documented choices.

Aside from ADA (which, according to the last figures I saw is
significantly lower in usage than Forth), most language standards have a
list of environmental options. I don't think it's reasonable to expect
that an application of any complexity can be free of some dependencies
(on processor, host OS, other things). If there are issues other than
those documented in Section 4.1, they should be called to the attention
of the Forth 200x group.

[Walter Banks]

On 30/09/2015 8:00 PM, hughag...@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..

[rickman]

On 10/2/2015 4:52 AM, Mark Wills wrote:
> On Friday, 2 October 2015 05:30:24 UTC+1, Rod Pemberton wrote:
> I.e., his apparent claim that ANS code is
>> non-portable would seem to be valid in the sense that the code would
>> break on pre-ANS Forths. Although, I don't think he mentioned pre-ANS
>> Forths anywhere in his claims.
>>
>
> I think it's worse than that. We're in a situation where "ANS Compliant"
> code runs differently on different *ANS compliant* systems. That's
> untenable in my view.

No, "ANS Uncompliant" code runs differently on different systems. If
you are doing an operation that the spec says produces "ambiguous"
conditions, by definition this code is not compliant.

> Though, in defence of the people that have worked
> on the standards process over the years, it should be pointed out that
> the situation is no better in the C or C++ worlds, and I'm sure there
> are issues with other standardised languages too. One exception seems
> to ADA as far as I can see. The specification for ADA is very tight.

Yea for ADA!

--

Rick

[rickman]

Yes, he who makes the suggestion gets to bell the cat.

--

Rick

[Chris Curl]

On Friday, October 2, 2015 at 5:00:32 PM UTC-4, rickman wrote:
> On 10/2/2015 4:52 AM, Mark Wills wrote:
> > I think it's worse than that. We're in a situation where "ANS Compliant"
> > code runs differently on different *ANS compliant* systems. That's
> > untenable in my view.
>
> No, "ANS Uncompliant" code runs differently on different systems. If
> you are doing an operation that the spec says produces "ambiguous"
> conditions, by definition this code is not compliant.

> --
>
> Rick

If a spec says the resulting condition in a use case is ambiguous, to me, that means that it is not known what the resulting condition will be.

Are you saying that if my implementation of that use case results in a condition I can predict, then my implementation is not compliant? If so, then I'm not sure I WANT my implementation to be compliant.

In order for an implementation to be non-compliant, the spec has to be clear about the resulting condition, so it can be tested against implementations to see if they produce that condition or not. How can you test for ambiguity? Therefore, if a spec says a condition is ambiguous, then every implementation complies.

On the other hand, if it is merely saying that, should 3rd party use of that feature encounter such a situation, it cannot depend on a specific resulting condition, then I understand the intent. Of course, that makes it hard on 3rd party developers, because then they need to ensure that use case doesn't ever happen, which increases the likelihood of a decision to not use that feature at all.

[rickman]

On 10/2/2015 5:46 PM, Chris Curl wrote:
> On Friday, October 2, 2015 at 5:00:32 PM UTC-4, rickman wrote:
>> On 10/2/2015 4:52 AM, Mark Wills wrote:
>>> I think it's worse than that. We're in a situation where "ANS Compliant"
>>> code runs differently on different *ANS compliant* systems. That's
>>> untenable in my view.
>>
>> No, "ANS Uncompliant" code runs differently on different systems. If
>> you are doing an operation that the spec says produces "ambiguous"
>> conditions, by definition this code is not compliant.
>> --
>>
>> Rick
>
> If a spec says the resulting condition in a use case is ambiguous, to me, that means that it is not known what the resulting condition will be.

Not "not known"... not specified. Any given system may produce a known
and repeatable result, but that result may be different from other
systems or the same system under other conditions.

> Are you saying that if my implementation of that use case results in a condition I can predict, then my implementation is not compliant? If so, then I'm not sure I WANT my implementation to be compliant.

No one in their right mind is saying that.

> In order for an implementation to be non-compliant, the spec has to be clear about the resulting condition, so it can be tested against implementations to see if they produce that condition or not. How can you test for ambiguity? Therefore, if a spec says a condition is ambiguous, then every implementation complies.

You have crossed the boarder into loony land. When the spec says a
usage produces an "ambiguous condition" it gives a long list of
potential responses by the system including, "take
implementation-dependent actions". Obviously this does not need to be
tested. That is the point of an "ambiguous condition", it is outside of
what is specified by the spec.

> On the other hand, if it is merely saying that, should 3rd party use of that feature encounter such a situation, it cannot depend on a specific resulting condition, then I understand the intent. Of course, that makes it hard on 3rd party developers, because then they need to ensure that use case doesn't ever happen, which increases the likelihood of a decision to not use that feature at all.

Wow, I can't tell if you really don't get it or if you are being
intentionally difficult.

Yes, if the spec says a "use case" results in an ambiguous condition
that means it is *not* specified in the spec and *may* differ between
systems. For a program to be compliant to the spec and produce
consistent results across platforms, it should not use "features" that
create ambiguous conditions.

Everything about different systems can't be specified to always be the
same. If it were, they would not be able to work on different platforms
or support different capabilities. Other things are considered to be
"ambiguous conditions" because doing them doesn't make a lot of sense
and is not worth the effort of making them work one particular way.

--

Rick

[Paul Rubin]

Chris Curl <ccur...@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.

> Therefore, if a spec says a condition is ambiguous, then every
> implementation complies.

Correct.

> On the other hand, if it is merely saying that, should 3rd party use
> of that feature encounter such a situation, it cannot depend on a
> specific resulting condition,

Yes. Think of a subscript error in a C program. The C standard says
what happens when a subscript is in range, but says nothing about what's
supposed to happen when it's out of range. Traditionally in C, that's
an unsafe operation and anything can happen. By contrast, in (say)
Python, or with the .at() operation in a C++ STL container, subscript
errors are supposed to raise an exception. Ambiguous condition is an
error which the standard doesn't tell you how (or whether) to handle.

One thing to keep in mind about Forth is that many aspects of its design
and standard are aimed at very memory-constrained or deep-embedded
processors, where the implementations are simply not willing to spend
any resources on niceties like aborting on FIND failing (or stack
underflow etc). You can use those systems interactively but it's pretty
easy to hang the interpreter on some of them, at which point you hit
reset. Systems on PC's usually have more amenities such as better error
signalling.

[Rod Pemberton]

On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin <no.e...@nospam.invalid> wrote:

> Yes. Think of a subscript error in a C program. The C standard says
> what happens when a subscript is in range, but says nothing about what's
> supposed to happen when it's out of range. Traditionally in C, that's
> an unsafe operation and anything can happen.

(nitpick ...)

It defines access one past the end of certain arrays as valid,
e.g., to detect nul '\0' at the end of string. But, yes, in
general, access outside the scope of valid C objects is
undefined or implementation defined.

[Elizabeth D. Rather]

On 10/2/15 1:08 PM, Paul Rubin wrote:
> Chris Curl <ccur...@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.

>> Therefore, if a spec says a condition is ambiguous, then every
>> implementation complies.
>
> Correct.

...providing the response is documented. Of course, it's possible to
document that the response consists of a particular THROW if the
Exception Word Set is being used. That's an opportunity for your
application to do a CATCH and control the response yourself. If you
don't do that, you'll get whatever action the system provides at the top
level where otherwise un-handled exceptions are handled (e.g., with an
abort), and that handling should also be documented. A set of THROW
codes for each of the ambiguous conditions listed in the standard is
included in the Standard's section on the Exception Word Set.

[Paul Rubin]

"Elizabeth D. Rather" <era...@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.

[Elizabeth D. Rather]

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.

[rickman]

On 10/2/2015 9:16 PM, Elizabeth D. Rather wrote:
> On 10/2/15 1:08 PM, Paul Rubin wrote:
>> Chris Curl <ccur...@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

[hughag...@gmail.com]

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.

[lehs]

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...

[Chris Curl]

: smooth.ruffled.feathers ." Yes, it was loony. Believe it or not,
that was how I interpreted what you wrote. If you can't see how I
could have possibly interpreted those words the way I did,
then I'm sorry. " ;

: i.am.not.a.troll ." Even though it may seem that way at times,
I promise that I am not trolling this group." ;

: restate.thread.topic ." For the record, it was not my
intention to reopen a topic that people are clearly very
passionate about and has been hotly debated in the past.
I was just saying, 'hi' and introducing my self to the group." ;

: reset.thread
smooth.ruffled.feathers
i.am.not.a.troll
restate.thread.topic ;

: go.do.other.stuff ( this word is implementation defined and its
behavior is ambiguous ) ;

: check.back.later ( this word is implementation defined and its
behavior is ambiguous ) ;

reset.thread go.do.other.stuff check.back.later

[Elizabeth D. Rather]

Welcome to comp.lang.forth! :-)

[Gerry Jackson]

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

[rickman]

Of course, if there weren't any typos to catch we wouldn't be reading
this version. lol

--

Rick

[visua...@rocketmail.com]

On Saturday, October 3, 2015 at 3:19:36 AM UTC-4, lehs wrote:
> Den söndag 27 september 2015 kl. 00:18:01 UTC+2 skrev Chris Curl:

...

> 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...

I am using Forth since 1984 and to quote you, since then I have never been seriously interested in any other computer language. Forth programming is real fun.

I started with RSC-Forth which is a derivative of FIG-FORTH and I am working now with Win32Forth which is ANS Forth standard compatible.

I am glad I never had problem with different standards, I only had to change the usage of <BUILD DOES>.

But I am wondering ...
Forth is extensible. So each new standard should have a package of words which may be loaded to make it compatible with the previous standard, to let old Forth programs be compiled and run without problems even with a new standard.

Win32Forth has a folder 'COMPAT' with some compatibility files.

[Anton Ertl]

Chris Curl <ccur...@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/

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>For example the idea that a forth st=
>andard should be a minimal kernel without structures and all the other thin=
>gs that easily can be added in each system. Then there might be a standard =

>that doesn't change from year to year.

1979 1983 1994 2012

The standard updates are not that frequent. Structures were only
added in the 2012 standard, but it does not seem that we are going to
update the standard every year now. Indeed there was a suggestion that
we should do more frequent updates at the standards meeting last year,
but there were strong voices against this.

Concerning the idea of a minimal system and that all users then add
their own structures and other things that can be added easily: That's
an idea that comes up regularly (e.g., at this year's EuroForth), and
there have been at least two occasions when people wanted to start a
standard based on that idea. So it is certainly an attractive idea.

But apparently not attractive enough to actually lead to any concrete
outcome. This year we at least got a list of words that were to be in
the minimal set in the opinion of its author, and we played around
with it (defined a number of them in terms of an even smaller set).

I think one problem here is that there are different concepts of
minimalism, and this includes the effort of this year's EuroForth: It
was intended to be a small set of words for education purposes, but
there was also the idea of implementation minimalism (don't provide
what you can easily define from the other provided words) in it.

Myself, I really don't want to define structures in every program, and
I don't want to read through other people's structures definitions
(and note the differences between them) every time I look at a
program, and I also much prefer if people use field names instead of,
e.g., CELL+ or nothing, which they often do if no structures are
present.

[Elizabeth D. Rather]

On 10/7/15 8:38 PM, Anton Ertl wrote:
> lehs <skydda...@gmail.com> writes:
>> For example the idea that a forth st=
>> andard should be a minimal kernel without structures and all the other thin=
>> gs that easily can be added in each system. Then there might be a standard =
>> that doesn't change from year to year.
>
> 1979 1983 1994 2012
>
> The standard updates are not that frequent. Structures were only
> added in the 2012 standard, but it does not seem that we are going to
> update the standard every year now. Indeed there was a suggestion that
> we should do more frequent updates at the standards meeting last year,
> but there were strong voices against this.
>
> Concerning the idea of a minimal system and that all users then add
> their own structures and other things that can be added easily: That's
> an idea that comes up regularly (e.g., at this year's EuroForth), and
> there have been at least two occasions when people wanted to start a
> standard based on that idea. So it is certainly an attractive idea.

"A minimal kernel without structures and all the other things that
easily can be added in each system" is roughly what Forth94 (ANS Forth)
constructed with its CORE wordset (whose words do not, actually, have to
be in a precompiled kernel, but must be available somehow in the system,
if only in paper documentation) and optional "Extension" wordsets.

As Anton correctly notes, standards have changed relatively
infrequently, and only with much publication for discussion of possible
changes.

[lehs]

To Anton Ertl and Elizabeth Rather:

I guess the question is far more complicated than I realize. I understood FIG-Forth well but I haven't dived under the hood since then. But my vision is that sort of kernel that works like a condense particle on which surface code grows downwards to the different processors and upwards to an OS for all kind of equipment and to increasingly more sophisticated userinterfaces and other applications.

I think it will happen if computers are used in the future.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:

>On 10/7/15 8:38 PM, Anton Ertl wrote:
>> lehs <skydda...@gmail.com> writes:
>>> For example the idea that a forth st=
>>> andard should be a minimal kernel without structures and all the other thin=
>>> gs that easily can be added in each system. Then there might be a standard =
>>> that doesn't change from year to year.

...

>> Concerning the idea of a minimal system and that all users then add
>> their own structures and other things that can be added easily: That's
>> an idea that comes up regularly (e.g., at this year's EuroForth), and
>> there have been at least two occasions when people wanted to start a
>> standard based on that idea. So it is certainly an attractive idea.
>
>"A minimal kernel without structures and all the other things that
>easily can be added in each system" is roughly what Forth94 (ANS Forth)
>constructed with its CORE wordset (whose words do not, actually, have to
>be in a precompiled kernel, but must be available somehow in the system,
>if only in paper documentation) and optional "Extension" wordsets.

If you mean that the Core wordset is the minimal one and that the
extension wordsets are the things that can be added easily, that's not
true:

There are words from the extension wordsets that cannot be defined
based on core words, e.g., words from the file wordset.

Moreover, the Core wordset is not perceived as minimal; e.g., at this
year's EuroForth Peter Knaggs started out by saying that the number of
words in Core is too large (130 words), and he produced a somewhat
smaller list (I think, 80-90 words), and Ulrich Hoffmann then defined
about half of that list through other words from that list. And at an
earlier occasion someone asked why a specific word was in core, when
it could have been defined through other CORE words, and IIRC you
explained that this kind of minimalism is not the idea behind the Core
wordset.

I think the idea of a standard minimal set of words never really took
off is, that, even more than the rest of Forth, everyone has different
ideas about minimality (and different goals), and if you are after
minimality, compromise is even less attractive than it is otherwise.