Adam Warner wrote:

The documentation goes back almost twenty years. If you have been
following it you have seen the explanations of the conceptional
foundation for each of the changes introduced. Because much of
it is ancient history now probably the only place you will find it is
in the old pages at my site that document that fifteen year period
where Dr. Ting and I wrote the only documentation.

Take the removal of ELSE for instance.

This clearly had nothing to do with hardware in that an ELSE is
just a jump and the machines all have had jump instructions.

Like dozens of other things Chuck explained his reasoning.

People had experimented with factoring Forth code many different
ways and there were many debates about favoring using ; or
facoring using IF ELSE THEN or IF THEN or nested IFs and
BEGINs and FORs and DOs and CASE and RECURSE etc.

He concluded that he wanted to enforce a higher degree of
factoring than he saw in other people's code where their
definitions didn't use ; factoring very much. I can think of
many people who have posted Forth defintions in c.l.f that
had 100 lines between semicolons and deeply nested
IF BEGIN DO constructs between the : and ;

This looked very much like the C code from which it was
copied, but it never looked like good Forth to Chuck who
felt that more factoring into Forth words was better.

And the idea of Forth chips was to make things that are
good to Forth, less of a penalty to encouage their use.
So calls and returns were emphasized as were all the
other Forth primitives. The idea was that people were
writing unreadable page long Forth words perhaps
because they were afraid of the overhead of using : ;
on some architecture, or because they were copying C,
or because it was their habit to only nest IFs 7
levels deep and DOs 7 levels deep inside of a single
definition

So instead of using ELSE, Chuck wanted to use ; instead.

This would keep words short and simple as in:

: DEMO blah if this ; then that ;

Chuck said, for those interested in the conceptual foundation
for why he removede ELSE, that this would enforce factoring
into smaller definitions and make the code easer to write,
to read, and to maintain.

He said, if you make your code that simple that most of the errors
that happen to people in the page long definitions, that are so
popular in c.l.f, would not happen. He said if you use that kind
of simple one liner definitions and test them that most of the
errors that other people see will be impossible.

And for those interested in the conceptual foundation we followed
through reporting that this had indeed had the effect that Chuck
had hoped. Forth code with short defintions is easier to read,
easier to write, and easier to maintain.

And pretty much everyone in Forth seems to agree with that
last sentance. The problem is that there is no hard definition
for short. I hear people say, I write short words in Forth
they use usually less than one page. I see a lot of 100
line Forth words in c.l.f along with people saying that short
definitions are good things.

This is why I added that in measurements I made over a year
words averaged 1.2 40 character lines in Lenght, and the
typical word was the size of DEMO above or smaller.

There are about 20 things like that that explain the reasoning
why things were done the way they were done in the last
twenty years by the inventor of Forth to try to improve the
language and make Forth more Forth-like. And the 20
things over 20 years are all documented and explained.

But when people skip over the hows and whys and
look at what appears to be more or less the same old
Forth instruction set, and they don't appreciate how the
instructions work with one another, how one puts them together,
how the compiler works, how the code is intended to be
written to make Forth work better they are easily confused.

And if they read c.l.f where 90%% of what is written about
this is confusion and guesses they are likely to be very
confused.

We say, we did this particular thing to de-emphasis
JUMPs and emphasis proper Forth factoring yet
people ask why we 'emphasise jumps.'

We say that we emphasise the use of the stack but
people ask why we de-emphasis the use of the stack.

We say that we want to encourage the use of Forth by
showing how the code can be made smaller, faster,
easier to read and write and maintain, and at the same
time the hardware can be made smaller and faster
and cheaper if both work together nicely in a Forth way.
And we say, if you want C hardware and C software
then this doesn't apply to you. We are talking Forth.

And I like to remind people that the opinion of most of
the programmers who have done the 100 man years of work
using this stuff have said that Chuck was right in his
conceptual foundataion and that the optimizations did
increase their productivity. But of the people with that
100 man years of experience I am about the only one
who posts in c.l.f. And for the most part those who
do post about things like the MISC instruction set
have at most a few hours or a few days exposure
and have been exposed to 90%% wrong guesses anyway
and that is mostly what they remember.

Forth is about words, and words need a stack so most of Forth
words manipulate the stack.

I am at a complete loss to understand how you can't see that
Forth needs stacks.

P21 only had 4 levels on the return stack. My old fashioned style
Forth didn't fit well. And I wrote an ANS Forth. In fact I wrote
about 30
to compare.

And I learned more about what Chuck thought was 'good' Forth and
realized that one of the big differences was that because my code
was not well thought out or well factored it was wasteful and easily
used up resources without doing much. But I learned what
Chuck had meant when he said that he had put in about all that
was really needed for good Forth code.

You have to understand the conceptual foundatation about how
Forth code should be constructed and factored. And people do
get confused about how code can have short words and lots
of : and ; and also use a minimal amount of the stacks!
It is no different than people having trouble understanding how
someone can balance on a bicycle, once they learn to do it
they do it by reflex and it is easy. If you have never done it
it might look hard. And some people try it, fall off, and decide it
is hard and never try again. So we see page long Forth words.

pushing and poping is what you do at the top of a stack
that use is what defines them as stacks
stacks are not infinte, they are finite
what goes on at the bottom is optional, wrap or error throwing hardware

ok, more conceptual foundation review:

P21 had 3 and 6 and F21 had 18 and others have had different stack
depths and it has not been a problem.

Stack depths are configurable in most Forths and it is not a big deal.
it is called an environmental dependency in ANS language.

ok, more conceptual foundation review:

Yes. We have created a Forth that is also assembler.

This eliminates the need for an assembler vocabular and separate
function that makes Forth a lot simpler and easier.

This makes the operation of the optimziing compiler straighforward
so we have the isomorphic properties of old fashion threaded
Forth that are what still have some people using those 35 year
old Forths. They don't have the complications imposed by
optimzing compilers that produce code that doesn't directly
match up against the source code, which are not easily
manipulated in a mechanical fashion, and which may
complicate debugging problems introduced by hidden
optimizations.

So we get the added benefit that the compiler is also made
simpler and smaller and faster.

I find it interesting to read things Chuck wrote about Forth
ten years before I met him. He was explaining this stuff 30
years ago and I sure didn't get it then. I felt that I began to
get it fifteen years ago and began trying to document it.
Chuck said that he thought I got it and that I did a better
job of documenting it than he. And he encouraged me to
document it.

Some people have hated that I documented it. But I still
try to answer people's questions when they ask.

Forth. Classic Forth with some enhancements in the last twenty years
called machineForth and some in the last ten years called colorforth.
And we have had variants for parallel programming as well that are
other variants of Forth. Forth.

ok, more conceptual foundation review:

The compiler is simpler, smaller and easier to understand.
The generated code is simpler, smaller, and easier to understand.
There is no extra assembler languge.
There is no underlying foriegn architecture to understand or map to
Forth.
The mapping is direct and simple.
The generated code is easy to debug.
The generated code is easy to manipulate.
Those are the advatages of classic threaded Forth, combined with
the advantages of assembler, combined with the advantages of
optimizing compilers, and yet when combines still simpler than
any single one of them in a conventional system.

We usually have the shortest source.
We usually have the least object code.
We sometimes lose on speed on things we want to do to
chips that cost hundreds of times more.
We sometimes beat those chips by a huge margin on things
we want to do.
We don't try to compete for Windows or FP apps.
But we have clearly demonstrated shorter, simpler, and faster
code, au nausium for many years. And I often repeat the
explantations for those who have somehow missed the
megabytes of explanations of the conceptual foundation
in the past and want it again in c.l.f.

ok, review:

I can when you don't care about the bottom of the stack. But if you
are using the whole stack then you can't optimize it away, because
it is an optimization already.

What is a slot spill?

We have four slots for opcodes in an instruction word.

Every item written to any stack overwrites something. period.
There is no system in which that doesn't happen.

I realize that many people try to understand Forth in the context of
compilers for register machines. You really can't understand what
we are doing however that way as it is completely different than
that. That is the whole point. It is completely different than that.

The inventor of Forth said that he has been making improvements to
the language and to the underlying virtual machine since he invented
the language. He has provided a conceptual foundation and
explaination for each of the improvements.

Some people heard about his Forth 35 years ago and made copies.
And people made copies of the copies. And 40,000 people joined
FIG and made a standard of the copies of the copies. And people
followed those standards and modified them for standards from
the late 70s, early 80s, and staring in the mid 80s.

And many quit paying attention to the step by step improvements
the the inventor of Forth was explaining for thrity years and then
said, "I have been doing Forth for 30 years and know all about it,
and I don't know what this guy is doing, but it isn't Forth!" ;-)

I think it is funny that so many people in c.l.f say that they
know so much about Forth that they know that the inventor
of Forth isn't doing Forth, doesn't understand Forth, doesn't
know what Forth word is, doesn't know what a stack is,
and simply doesn't understand programming or computers.
;-)

Sure he "may" be able to "make the case" for some
"new programming model" based on a "different abstract
data type" and a "virtual machine", that isn't the Forth
virtual machine, and then conceivably "argue" with you,
that it is "somehow" (since you doubt it) superior to Forth
but to do that they would have to accept your expert
opinion that it isn't Forth in the first place. That's very
gracious of you. ;-)

Perhaps you should write to Mr. Moore and tell him about his
Forth langauage that he should consider instead of "whatever
thing he is chasing down at the moment" instead of your
language, Forth. ;-)

Maybe he hasn't heard about this langauge that you invented
called Forth. ;-)