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

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

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.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

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

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

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.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

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

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

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.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

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.

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.

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)

> Threaded Interpretive Languages by R. G. Loeliger

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