What is Forth?

[Brad R]

gforth is intended to be a "fat" Forth with all standard extensions, plus many extensions of its own. So yes, it's a bit large as Forths go. CamelForth is an ANS "core" implementation, and usually fits in less than 8K.

As it happens, I got my start with STOIC (STack Oriented Interactive Compiler), which was developed at MIT in the '70s. I migrated to Forth because it was more widely used and more generally available...but STOIC did have some nice features. By both Garth's list and mine, I think STOIC counts as "a Forth".

[chitselb]

Brad,

I think I'd like nothing better than to be able to claim ANS standard compliance for the Forth I'm working on. I notice there is a "standard subset" type of compliance. I am *this close* [pinches fingers together] to asking your permission to grab large chunks of camel secondaries for that purpose. Have I stepped out of bounds already? Is a 16-bit data stack a problem? I'm woefully ignorant about the ANS standard.

[GARTHWILSON]

This is a little off the topic of "What is Forth?", so some may wish to skip this post

However, as long as ANS has come up, as I've posted here before, although ANS Forth has some good things, there are also various things I don't like about it, so I'm glad I don't have to be locked entirely into one standard or another.

There are of course many words in common usage that are not part of any official standard; so when I found that various words I wrote were in common usage but had different names, I changed my names to match common usage.  One example is RANGE , which tells if n1 is in the range of n2 to n3, which of course I used a lot in the automated production test equipment, to see if a test result was within acceptable limits.  I found that others did the same thing and called it BETWEEN , and that it almost made it into ANS Forth under that name; so I changed the name of mine to match.  So in a way, common usage itself becomes a standard.

There are some parts of ANS Forth that present extra overhead in order to make it more portable across a wide range of processors.  My personal opinion is that they may have taken this too far.  At some point, we need to acknowledge that no language that lets you get so close to the heart of the computer will be 100% portable.  We must consider the programmer(s) and platform(s) involved, and decide on a good balance between portability and optimization.  I personally prefer more optimization at the expense of portability.  Greater optimization means a particular processor can be used for a wider range of jobs anyway, which would in itself reduce the need for portability.

Jack Woehr of Vesta Technology who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered."  He admits that optimum portability and optimum efficiency don't come at the same point.  Fortunately he also says it's not the committee's intention to force anyone to comply with the standard.  What I have is basically Forth-83 with a lot of extensions from my own experience, the books "Starting Forth" and "Thinking Forth," Forth Dimensions magazine, ANS, and common usage.

Edit: Jeff Fox has a great article entitled "ANSI Forth is ANTI Forth" at http://www.ultratechnology.com/antiansi.htm, and Chuck Moore, the inventor of Forth agrees. See why.

[Brad R]

A bit of history about ANS Forth -- and a disclaimer: I only attended one of the committee meetings. (The one that was held within driving distance.) The ANS Forth group started from Forth-83, which was the then-current standard, and set out to (a) fix problems, and (b) codify common usage for extensions. This is why there is a "core" word set, which is very close to Forth-83, and lots of extension word sets. The idea is this: you're not required to provide the extension word sets, but if you do, you are expected to follow the ANS definition of the words. (Also, technically you're not required to provide all of the core words in executable form -- you can provide them as source code, as long as they can be loaded onto your core system.)

Many of the problems that were fixed were machine or implementation dependencies. Previous standards had pretty much assumed an indirect- or direct-threaded model. The ANS group was very careful to avoid that -- which is why there is "xt", execution token, instead of "cfa", code field address, to name one example. Previous standards had also specified 16-bit stack, and assumed character-addressible memory. ANS fixed that. (They did defer the tricky problem of cross-compilation to a future committee.)

I have not read the estimable Jack Woehr's book, but I wonder if he was talking about ANS Programs rather than ANS Systems. The ANS Standard defines both. For a Forth to be a Standard Forth System, it must provide the ANS-defined functions (words, stacks, etc.) in the ANS-defined way. This may be not very different from Forth-83, and doesn't add much overhead. The kicker is a Standard Forth Program, which is a program that will compile correctly on any Standard Forth System -- i.e., a program with no machine or implementation dependencies. These are damned hard to write! I have programs, for example, which assume that you can discard one layer of subroutine return by doing R> DROP; that's a no-no in a Standard Forth Program. So yes, in the application program, "a certain light-footedness and grace will be surrendered." No assumption that -1 is the same as 0 INVERT. No CODE words. I could go on.

Even though I had some differences of opinion with the ANS Forth committee -- hence the joke in the name "CamelForth" -- I have, over the ensuing years, decided that they were right and I was wrong about several things. And the other differences are largely a matter of taste. So I think it's worth the small added effort to make Forth systems ANS-compliant. Since I code for embedded systems, I don't have to write Standard Forth Programs, but the few desktop applications I have coded make me appreciate the value of writing portable code.

[Brad R]

chitselb wrote:

I think I'd like nothing better than to be able to claim ANS standard compliance for the Forth I'm working on. I notice there is a "standard subset" type of compliance. I am *this close* [pinches fingers together] to asking your permission to grab large chunks of camel secondaries for that purpose. Have I stepped out of bounds already? Is a 16-bit data stack a problem? I'm woefully ignorant about the ANS standard.

Important disclaimer: while I believe that CamelForth is ANS-compliant, I don't know that it is. Actually, in one respect I know it's not -- I haven't yet written the ANS-required documentation.

Is your Forth going to be a commercial product, or published for anyone to use? If the latter, the CamelForth source code is published under GPL v3, so you're free to adapt it, or use it as is, for another open-source project. And no, you're not stepping out of bounds to ask. (Incidentally, it's best to adapt the MSP430 source, as it has the latest fixes.)

A 16-bit data stack is no problem. That's what most of the CamelForths use.

[barrym95838]

Brad R wrote:

... (Incidentally, it's best to adapt the MSP430 source, as it has the latest fixes.) ...

I've discarded the idea of bringing a full 65m32 fig-FORTH implementation to life, and have instead switched to Camel Forth, namely the '430 Camel Forth, because it's "more modern" and it's easy for me to follow the source (a big plus when translating). Even though the '430 is a two-address device and the 'm32 is a one-address device, the machine instruction count seems to be about even so far (~50 primitives and counting). I'm choosing code density over speed at every opportunity, however (it seems that the '430 version doesn't have a particular obsession with either). If I run into any snags, I'll start a new thread like "Porting Camel Forth" or something ... cool? (or is this anycpu.org material)?

Mike

[BigEd]

New thread, on this site, sounds good to me.
Cheers
Ed

[Brad R]

barrym95838 wrote:

I'm choosing code density over speed at every opportunity, however (it seems that the '430 version doesn't have a particular obsession with either). If I run into any snags, I'll start a new thread like "Porting Camel Forth" or something ... cool? (or is this anycpu.org material)?

If you're asking me, I'm cool with that, here (in a new thread) or at anycpu.org. CamelForth was always an educational project.

I'd say I didn't favor code density or speed. I was striving for (a) ease of porting -- hence using TI library routines for multiply and divide, instead of writing my own; and (b) educational value -- hence an ITC Forth for the MSP430, instead of the faster DTC. I didn't opt for the smallest possible set of primitives; instead I tried to find the smallest set that would make a useful Forth. But you will see words like : > SWAP < ; written in high-level, even when that's not hard to write in machine code.

[BigEd]

Scot Stevenson (scotws here) just posted this orientation piece on his blog:

Quote:

The Dragon-Free Internals of Forth
In which our protagonist is amazed that the core structure of Forth is so simple even he can understand it.

Forth was not invented by a bunch of eggheads at a university, but by a guy who needed to get real work done...
[snip]
Keeping stuff simple not only was a philosophy, but a necessity.

So while the internals of boffin languages can be so complex and scary they make people think of dragons, the core of Forth is so simple it seems almost snarky:

[cr1901]

GARTHWILSON wrote:

Jeff Fox has a great article entitled "ANSI Forth is ANTI Forth" at http://www.ultratechnology.com/antiansi.htm, and Chuck Moore, the inventor of Forth agrees. See why.

I've been looking into Forth. It seems that the currently available code by and large is written in either ANS Forth or gforth. Based on this article, Chuck Moore and Jeff Fox suggest I implement Machine Forth, and there is also an F83 standard.

I would like to spend my time testing other people's code in addition to writing my own Forth programs. If I were to implement/use a Machine Forth/F83 implementation, how much of ANS Forth programs would I have to rewrite to use on my machine (say, a text editor, for instance- I don't have much desire to write my own)?

[Brad R]

I'm not familiar with Machine Forth, so I can't say for sure how much rewriting of ANS Forth programs you'd have to do. But from what I've seen of Chuck Moore's work, I'd imagine it's quite a lot. Chuck is a rabid minimalist (that's a compliment) and quite willing to throw away old work if he comes up with a new way to solve a problem. So Machine Forth may diverge quite a lot from other, more "mainstream" Forths.

Re. Forth-83, that was used as the starting point for the ANSI Standard, so there'd probably be a lot less rewriting of ANS applications required. (Incidentally, the standard is "Forth-83"; "F83" is one specific implementation of that standard.)

But if you're going to use ANS Forth applications, why not just implement an ANS Forth system? It's not significantly more difficult than implementing an 83-Standard system.

[theGSman]

My take on Forth? I would have to say that coding in BASIC, Pascal or C is much easier because algebraic notation seems more natural than Reverse Polish Notation. (BASIC is actually quite liberating. No need to worry about planning or structures - just start wherever you feel like and glue the bits of code together with GOTOs and GOSUBs. Of course I would never do that with any large project but for code that is less than a few hundred lines - such as on the commodore 64 - this worked out great for me).

Also, since most Forth words only operate on the top number on the stack, you can find yourself doing quite a bit of "stackrobatics" to get at the numbers you want to. Keeping the stack manipulations down to a minimum can be quite a challenge and at times,when your code stubbornly refuses to do what you think it should do (the bugs can be quite elusive), you may find yourself wishing that you could just key in an algebraic expression and be done with it! For these reasons, I tend to take it with a grain of salt claims that Forth necessarily results in developments that take a small fraction of the time that you would take with other languages. After all, it's all in the planning.

For all that, I like Forth. It is a simple language - simple enough that any programmer with moderate skills can write his own version. Forth is powerful - more powerful even than C. Forth is flexible. Any feature you want it to have you can usually write a word that implements it with a minimum of fuss. Forth encourages (almost forces) structured programming and a modular approach to programming. Once you have a word working the way you want it to, you can forget about it. And if you decide to modify the word, you can be sure that you won't ruin it for the rest of the program.

Finally, in spite of my above comments, I like "stackrobatics". I still get a great sense of satisfaction when I can get a complicated set of stack operations working just right.

[scotws]

I experienced two "level ups" with Forth in the past year:

First was when I realized that you don't program in Forth, you use Forth as the foundation of your own programming language based on Forth. This happened while I was looking around for a CLI code example in Forth like the Python module Cmd for my trivial text adventure. Their isn't one, because - blinding flash of insight! - you use Forth's interpreter directly. One reason why Forth hasn't taken off is because this makes it harder to isolate the class of "dumb users" from the dangerous internals without sacrificing the power of the language.

The second came when I finally understood CREATE/DOES> and how to define your own defining words. Compare it to what you will -- a "primitive form of OOP" seems to be all the rage at the moment -- but being able to do that kind of stuff with such minimal resources is amazing.

I'm sure I'm still missing some levels. But I've already gotten to the point where other languages like Python feel constricting (pun intended): They give you a set of standard tools and standardized building blocks, and then you use the former on the later to make something. Now I've become used to designing my own custom-fit tools to work on blocks that I have defined myself.

[chitselb]

Found this page, a roll-your-own Forth book from 1981. The book says it isn't Forth, but it is

http://sinclairql.speccy.org/archivo/do ... guages.pdf

http://mirrors.acm.jhu.edu/textfiles/bi ... rpLang.pdf (cleaner)

[BigEd]

> Threaded Interpretive Languages by R. G. Loeliger

There's a very positive review here:
http://www.retroprogramming.com/2010/03 ... y-r-g.html