FORTH is a programming language based on Reverse Polish Notation, the notation best-known from its use in HP calculators:
1 2 + 3 * 4 / ( comments start with open paren and extend to close paren)
Compare to Tcl
expr {(1+2)*3)/4} ;# commentsor, if math operation commands are imported:
/ [* [+ 1 2] 3] 4
Forth consists of words (commands) that exchange parameters on a stack. This simple concept implies postfix notation, and RPN in mathematical expressions.
Chuck Moore created FORTH in 1970. An interesting article about FORTH ,Threads of a FORTH Tapestry , appeared in the August 1980 issue of Byte magazine.
Related to this is 1% the code, a shocking paper by Chuck Moore.
Often over the years, FORTH and Tcl have been compared because of the mindset in both to write lots of procs/words to do one's work.
Leo Brodie's "Starting Forth" as a starkit for Microsoft Windows/Linux/Solaris can be found here [L1 ], based on the web version of the book at [L2 ]. (AMG: Or see [L3 ] for another version of the same book.)
AK: This starkit seems to need a package 'scripdoc', which is not in the starkit.
LV: That package was a part of the original tclkits. It still is in my tclkit of tcl 8.4.9 for sparc solaris. Perhaps it isn't in the tclkit lite?
Several Forths have bound to Tk for their GUI toolkit needs. V6 [L4 ] is a commercial Forth based on Gforth available for Linuxes (and *BSD? and MacOS X?).
Zarutian 2006-09-24: Does an Tcl interpreter in Forth exists?
Zarutian 2006-09-27: Or do I have to write one?
wdb Please yes!
Zarutian 2007-06-20: Hmm... that would require Forth words for:
and something more probably.
tb 2007-07-17: @wdb, Do you think of a string stack? How much of a FORTH system would be appropriate for emulation? A true 2stack machine with a "Dictionary space", an "Inner interpreter", an "Outer interpreter", compilers and defining words, complete with its own command loop? -- wdb Not a string stack, but some creations with <builds ... does>. All strings shall be unique, identified by their memory address, and be immutable. Depending on operations, values internally implemented with multi-pointer (one for string-processing, one for list-processing, one for float-processing), where not-used or outdated pointers are reset to null. -- I'm just dreaming of a very high-performant Tcl ...
wdb: I'm working on a string object in gforth where uniqueness of char sequences ist granted. Instead of garbage collect, memory recycling triggered automatically on forgetting. Built as "black box" where you can use a few words provided to handle the data without knowledge about internals. Should be a solid base for a Tcl interpreter. If anybody is interested, I'm happy to hand it out.
escargo: It might be interesting to have a PostScript system instead. PostScript is both a stack-based VM and has strings and dictionaries.
LEG 2007-09-19: just implemented f4t. Why would you want to do string processing on stacks in Tcl? Why would you want to implement just another graphics language in Tcl. Both things are handled fine in Tcl/Tk. IMO Forth in Tcl should enhance, complement Tcl in an area where Tcl needs it or where Forth functionality is nice to have.
wej 2008-04-29: If you want to write Tcl programs in Forth: HolonTForth compiles Forth to Tcl source files and uses Tcl as the Forth machine.
ZB 2008-07-06: Every description of Forth focuses on using stack, RPN and so on - but I'm interested in such trivial things, like f.e.: is it possible to write Forth-programs with nice user interface (at least curses-based, if not Tk/GTK-like GUIs)? Any examples?
Is event-based programming possible using Forth? A google-search for "event-based programming in forth" revealed nothing.
tb 2008-07-07 - Yes, it should be possible by creating an event stack, holding addresses of handlers (as a first approach), but you'd have to program and enter your own event loop, because a classical FORTH inpterpreters loop only recognizes ONE input stream, which must be ASCII characters.
escargo 2008-07-07: One of the original FORTH systems was a time-share system that supported 30 users on a 32K 16-bit word Honeywell H316 system. Every user got an input buffer and a private dictionary. A context switch between users required changing the value of 3 pointers (if I remember correctly). So if FORTH could do that, then using FORTH to create an event loop with "do one event" would seem to be possible.
ZB: I was digging for more information meanwhile, and I've found, that Forth is something like "OS and set of tools for creation of one's own language" rather - and not "just another programming language". Looks very interesting. One can f.e. implement interrupts handlers.
tb: Yes, this is called metaprogramming and in this aspect of creating your own problem-related language, FORTH is quite similar to Tcl. Instead of namespaces you have "vocabluaries" and instead of procedures you have "words". But, with the lack of a seamless integrated widget kit, like Tk in Tcl/Tk, FORTH will always only be a better assembler, heading for device drivers, document processors (Postscript) or other non-interactive tasks.
PS: I remember a nice implementation of FORTH, running on Atari-ST under GEM. It managed windows, menus and events and fitted nicely into the Ataris OS. It was called "Volksforth" and followed the Forth'83 path. Perhaps that'd be a starting point for some X-Forth or WIN-Forth?
ZB: Although I've found meanwhile something called "TkForth" (seems to be discontinued), but it can be seen as kind of exercise rather, because Forth isn't any "TCL-replacement" (neither competitor); it's quite different tool. Although most probably one could build, using Forth, ones own "Tk" from the ground up - there is a question: "do I need to?". It seems to me - from that few docs I've read until now - that proper (target) use of Forth is "standalone" rather than on top of any OS. We're losing some (or even many) of its advantages otherwise. Someone described Forth as "Lego among the programming languages" (as TCL is among the scriptic ones).
tb They seem to have found a way to call routines from the Tk library. Then it creates some defining words (compilers) for widget creation. So they compile widgets as words into the dictionary space. A very FORTHish approach. :)
Running FORTH in standalone mode isn't really a prefered way, but leads to a small footprint ready to be burnt to EPROM. Most modern FORTHs like GForth, BigForth et.al. use the underlying OS for screen output and disk access. They can be extended to call foreign library functions including those from the Tk library as shown with TkForth.