net!news.itvcorp.com!www.taygeta.com!jon
Subject: Forth Programming Language FAQ: Part 1 of 6, General Information
Date: 3 Mar 97 12:25:46 GMT

Posted-By: auto-faq 3.3 beta (Perl 5.001)
Archive-name: computer-lang/forth-faq/part1
Posting-Frequency: Monthly.  A how-to-find-the-FAQ article is posted weekly.

  comp.lang.forth Frequently Asked Questions (1/6): Gen-
  eral/Misc
  M. Anton Ertl, anton@mips.complang.tuwien.ac.at

  ____________________________________________________________

  Table of Contents:

  1.      Acknowledgements

  2.      comp.lang.forth FAQs

  3.      General Questions

  3.1.    What is Forth?

  3.2.    Why and where is Forth used?

  3.3.    Hang on, isn't Forth out of date now?

  3.4.    What language standards exist for Forth?

  3.5.    What is an RFI?

  3.6.    Are there Coding Standards for Forth?

  3.7.    I have trouble managing the stack. Should I use global
  VARIABLEs?

  3.8.    What is the Forth Interest Group?

  4.      Flame baits

  4.1.    Commercial vs. free Forth systems

  4.2.    Free Forth systems are bad for Forth.

  4.3.    Blocks vs. files

  4.4.    LOCALS|

  5.      Miscellaneous

  5.1.    Where can I find a C-to-Forth compiler?

  5.2.    Where can I find a Forth-to-C compiler?

  5.3.    RECORDS in Forth?

  5.4.    Why does THEN finish an IF structure?

  5.5.    What is threaded code? What are the differences between the
  different threading techniques?

  5.6.    Has anyone written a Forth which compiles to Java bytecode?

  5.7.    What about translating Java bytecode to Forth?
  ______________________________________________________________________

  1.  Acknowledgements

  This FAQ is based on previous work by Gregory Haverkamp, J. D. Verne,
  and Bradford J. Rodriguez.

  2.  comp.lang.forth FAQs

  The comp.lang.forth FAQ is published in six parts, corresponding to
  these six sections.  This part is the General/Misc FAQ, where the
  questions not covered in the other FAQs are answered. The six parts
  are:

  o  General questions <http://www.complang.tuwien.ac.at/forth/faq/faq-
     general.html>

  o  Online resources <http://www.complang.tuwien.ac.at/forth/forl.html>

  o  Forth vendors <ftp://forth.org/pub/Forth/FAQ/vendors>

  o  Forth systems <ftp://forth.org/pub/Forth/FAQ/systems>

  o  Books, periodicals, tutorials <ftp://forth.org/pub/Forth/FAQ/books>

  o  Forth groups & organizations <ftp://forth.org/pub/Forth/FAQ/groups>

  These FAQs are intended to be a brief overview of the tools and
  information available for the new FORTHer.  For a historical
  reference, programming paradigms, and deep technical information try
  some of the listed references.  For general questions on the internet,
  or the methods used to get this information, try these other Usenet
  groups:

  o  news.announce.newusers

  o  news.newusers.questions

  o  news.announce.important

  3.  General Questions

  3.1.  What is Forth?

  Forth is a stack-based, extensible language without type-checking.  It
  is probably best known for its "reverse Polish" (postfix) arithmetic
  notation, familiar to users of Hewlett-Packard calculators: to add two
  numbers in Forth, you would type  3 5 +  instead of 3+5.  The
  fundamental program unit in Forth is the "word": a named data item,
  subroutine, or operator. Programming in Forth consists of defining new
  words in terms of existing ones.  The Forth statement

  ______________________________________________________________________
  : SQUARED  DUP * ;
  ______________________________________________________________________

  defines a new word SQUARED whose function is to square a number (mul-
  tiply it by itself).  Since the entire language structure is embodied
  in words, the application programmer can "extend" Forth to add new
  operators, program constructs, or data types at will.  The Forth
  "core" includes operators for integers, addresses, characters, and
  Boolean values; string and floating-point operators may be optionally
  added.

  3.2.  Why and where is Forth used?

  Although invented in 1970, Forth became widely known with the advent
  of personal computers, where its high performance and economy of
  memory were attractive.  These advantages still make Forth popular in
  embedded microcontroller systems, in locations ranging from the Space
  Shuttle to the bar-code reader used by your Federal Express driver.
  Forth's interactive nature streamlines the test and development of new
  hardware. Incremental development, a fast program-debug cycle, full
  interactive access to any level of the program, and the ability to
  work at a high "level of abstraction," all contribute to Forth's
  reputation for very high programmer productivity.  These, plus the
  flexibility and malleability of the language, are the reasons most
  cited for choosing Forth for embedded systems.

  3.3.  Hang on, isn't Forth out of date now?

  One of the best answers came from Brad Rodriguez
  <mailto:bj@forth.org>. You can find the full version at
  <http://www.complang.tuwien.ac.at/forth/faq/why-forth>. In short,
  Forth's advantages are that it's comprehensible, small, interactive,
  fast, extensible, and makes it easy to work at a high level of
  abstraction.

  BTW, this question came from someone comparing a 10+year old Forth
  system with the latest version of Borland C++. His system was really
  out of date, but also with respect to current Forth systems.

  3.4.  What language standards exist for Forth?

  An American National Standard for Forth, ANSI X3.215-1994, is accepted
  worldwide as the definitive Forth standard.  ("ANS Forth")

  IEEE Standard 1275-1994, the "Open Firmware" standard, is a Forth
  derivative which has been adopted by Sun Microsystems, HP, Apple, IBM,
  and others as the official language for writing bootstrap and driver
  firmware.

  Prior Forth standards include the Forth-83 Standard and the Forth-79
  Standard issued by the Forth Standards Team.  The earlier FIG-Forth,
  while never formally offered as such, was a de facto "standard" for
  some years.

  "FORTH STANDARDS  Published standards since 1978 are Forth 79 and
  Forth 83 from the Forth Standard Team, and ANS Forth - document
  X3.215-1994 - by the X3J14 Technical Committee.  The most recent
  standard, ANS Forth, defines a set of core words and some optional
  extensions and takes care to allow great freedom in how these words
  are implemented.  The range of hardware which can support an ANS Forth
  Standard System is far wider than any previous Forth standard and
  probably wider than any programming language standard ever. See web
  page  <http://ftp.uu.net/vendor/minerva/uathena.htm> for latest
  details. Copies of the standard cost $193, but the final draft of ANS
  Forth is free and available (subject to copyright restrictions) via
  ftp..." --Chris Jakeman, apvpeter.demon.co.uk

  The (un)official ANS Forth document is available in various formats at
  <http://www.taygeta.com/forthlit.html> and at
  <ftp://ftp.uu.net/vendor/minerva/x3j14/>. The format I like best is
  the HTML version <http://www.taygeta.com/forth/dpans.html>.

  To get yourself on the ANS-Forth mailing list, consult the various
  README files at  <ftp://ftp.uu.net/vendor/minerva/x3j14/>.

  Two unofficial test suites are available for checking conformance to
  the ANS Standard Forth:

  o  John Hayes has written a test suite to test ANS Standard Systems
     (available through  <http://www.taygeta.com/forth.html>).

  o  JET Thomas has written a test suite to test ANS Standard Programs:
     <ftp://forth.org/pub/Forth/ANS/stand4th.zip>

  3.5.  What is an RFI?

  A Request For Interpretation. If you find something in the standard
  document ambiguous or unclear, you can make an RFI, and the TC
  (technical committee), that produced the standard, will work out a
  clarification. You can make an RFI by mailing it to greg@minerva.com
  and labeling it as RFI. The answers to earlier RFIs are available at
  ftp://ftp.uu.net/vendor/minerva/x3j14/queries/. They are also
  integrated in the HTML version of the standard
  <http://www.taygeta.com/forth/dpans.html>.

  3.6.  Are there Coding Standards for Forth?

  Leo Brodie's book Thinking Forth gives some advice. Forth shops have
  rules for their coding. Paul Bennet has published those of his
  company; you can find them on
  <http://www.complang.tuwien.ac.at/forth/coding-rules>.

  3.7.  I have trouble managing the stack. Should I use global VARI-
  ABLEs?

  No. There are better alternatives:

  o  Keep on trying to use the stack. Reorganize (refactor) your words.
     One day you will get the knack for it. Elizabeth Rather
     <mailto:erather@forth.com> writes:

       The basic skill required for comfortable, efficient Forth
       programming is good stack management.  It's hard for newcom-
       ers to learn, since it isn't a skill required in other lan-
       guages, which all require the use of variables for practi-
       cally everything.  Having taught literally hundreds of
       courses over the last 25 years, I've seen newcomers wrestle
       with this, and have developed exercises (similar to those in
       Starting Forth) to help.  It seems to be a skill rather like
       riding a bicycle: wobbly & scary at first, then suddenly a
       "switch is thrown" in the brain and it seems comfortable and
       natural ever after.

  o  Use the return stack.

  o  Use locals.

  o  Use data structures in memory, and pass pointers to it on the
     stack.

  o  One area that has been mentioned often as troublemaker is graphics
     programming. Take a look at how Postscript handles this: They do
     indeed have a global state to avoid stack management problems, but
     you can access this state only through certain words.

  3.8.  What is the Forth Interest Group?

  The Forth Interest Group "FIG" was formed in 1978 to disseminate
  information and popularize the Forth language, and it remains the
  premier organization for professional Forth programmers.  FIG
  maintains a Web page at  <http://www.forth.org/forth.html>, with a
  more complete introduction to the Forth language, and links to the Web
  pages of many Forth vendors.

  4.  Flame baits

  Some statements spawn long and heated discussions where the
  participants repeat their positions and ignore the arguments of the
  other side (flame wars). You may want to avoid such statements.

  Here, I present some regularly appearing flame baits and the positions
  you will read (so you don't have to start a flame war to learn them).

  4.1.  Commercial vs. free Forth systems

  "You get what you pay for. With a commercial Forth you get commercial
  documentation and support. We need commercial Forth systems or Forth
  will die."

  "I have had good experiences with free Forths. I cannot afford a
  commercial Forth system. I want source code (some commercial vendors
  don't provide it for the whole system). Examples of bad support from
  commercial software vendors. Without free Forth systems Forth will
  die."

  4.2.  Free Forth systems are bad for Forth.

  "Anyone can write a bad Forth and give it away without documentation
  or support; after trying such a system, nobody wants to work with
  Forth anymore. Free Forths give Forth a bad name. Free Forths take
  business away from the vendors."

  "Many people learned Forth with fig-Forth. There are good free Forths.
  Most successful languages started with (and still have) free
  implementations. Languages without free implementations (like Ada,
  Eiffel and Miranda) are not very popular."

  4.3.  Blocks vs. files

  The discussions on this topic are much cooler since Mike Haas has
  dropped from comp.lang.forth.

  "Everyone is using files and all third-party tools are designed for
  files. Files waste less space. Blocks lead to horizontal, unreadable
  code. Blocks make Forth ridiculous."

  "We are not always working under an operating system, so on some
  machines we don't have files. We have very nice block editors and
  other tools and coding standards for working with blocks (e.g., shadow
  screens)."

  4.4.  LOCALS|

  Everyone who mentions using LOCALS| gets the following flame from me:

  LOCALS| is bad because the locals are ordered contrary to the stack
  comment convention. I.e.:

  ______________________________________________________________________
  : foo ( you can read this -- ... )
   LOCALS| this read can you | ... ;
  ______________________________________________________________________

  The following locals syntax is better and widely used:

  ______________________________________________________________________
  : foo { you can read this -- ... }
   ... ;
  ______________________________________________________________________

  You can find an implementation of this syntax in ANS Forth at

  5.  Miscellaneous

  5.1.  Where can I find a C-to-Forth compiler?

  There have been roumors about such a compiler at Harris (for the RTX
  chip) and elsewhere. The most concrete answer to this question has
  come from Stephen Pelc (sfp@mpeltd.demon.co.uk):

  MPE has produced a C to stack-machine compiler. This generates tokens
  for a 2-stack virtual machine. The code quality is such that the token
  space used by compiled programs is better than that of the commercial
  C compilers we have tested against. This a consequence of the virtual
  machine design.  However, to achieve this the virtual machine design
  has local variable support.

  The tokens can then be back end interpreted, or translated to a Forth
  system. The translater can be written in high level Forth, and is
  largely portable, except for the target architecture sections.

  These are not shareware tools, and were written to support a portable
  binary system.

  5.2.  Where can I find a Forth-to-C compiler?

  An unsupported prototype Forth-to-C compiler is available at
  <http://www.complang.tuwien.ac.at/forth/forth2c.tar.gz>. It is
  described in the EuroForth'95 paper
  <http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz>.
  Another Forth-to-C compiler is supplied with Rob Chapman's
  <mailto:rob@idacom.hp.com> Timbre
  <http://www.taygeta.com/forthcomp.html> system.

  5.3.  RECORDS in Forth?

  Many packages for data structuring facilities like Pascal's RECORDs
  and C's structs have been posted. E.g., the structures of the Forth
  Scientific Library ( <http://www.taygeta.com/fsl/fsl_structs.html>) or
  the structures supplied with Gforth
  <http://www.complang.tuwien.ac.at/forth/struct.fs>.

  5.4.  Why does THEN finish an IF structure?

  Some people find the way THEN is used in Forth unnatural, others do
  not.

  According to Webster's New Encyclopedic Dictionary, then" (adv.) has
  the following meanings:

       2b: following next after in order ... 3d: as a necessary
       consequence (if you were there, then you saw them).

  Forth's THEN has the meaning 2b, whereas THEN in Pascal and other pro-
  gramming languages has the meaning 3d.

  If you don't like to use THEN in this way, you can easily define ENDIF
  as a replacement:

  ______________________________________________________________________
  : ENDIF  POSTPONE THEN ; IMMEDIATE
  ______________________________________________________________________

  5.5.  What is threaded code? What are the differences between the dif-
  ferent threading techniques?

  Threaded code is a way of implementing virtual machine interpreters.
  You can find a more in-depth explanation at
  <http://www.complang.tuwien.ac.at/forth/threaded-code.html>.

  5.6.  Has anyone written a Forth which compiles to Java bytecode?

  Paul Curtis <mailto:paul.curtis@ra-ltd.demon.co.uk> writes:

  The JVM, although a stack machine, can't really be used to compile
  Forth efficiently.  Why?  Well, there are a number of reasons:

  o  The maximum stack depth of a called method must be known in
     advance. JVM Spec, p. 111

  o  JVM methods can only return a single object to the caller.  Thus, a
     stack effect ( n1 n2 -- n3 n4 ) just isn't possible.

  o  There is no direct support for unsigned quantities.

  o  CATCH and THROW can't be resolved easily; you need to catch
     exceptions using exception tables.  This doesn't match Forth's
     model too well.  JVM Spec, p. 112

  o  You'd need to extend Forth to generate the attributes required for
     Java methods.

  o  There is no such thing as pointer arithmetic.

  o  You can't take one thing on the stack and recast it to another
     type.

  o  You can't manufacture objects out of raw bytes.  This is a security
     issue.

  o  There is no support for the return stack.

  That said, it is possible to write something Forth-like using JVM
  bytecodes, but you can't use the JVM stack to implement the Forth
  stack.  ...

  If you're serious, try getting Jasmin and programming directly on the
  JVM.

  5.7.  What about translating Java bytecode to Forth?

  Some of the non-trivial pieces in translating JavaVM to Forth, that we
  have identified, are:

  o  garbage collection

  o  threads

  o  control structures (branches->ANS Forth's seven universal control
     structure words)

  o  exceptions

  o  subroutines (JavaVM does not specify that a subroutine returns to
     its caller)

  o  JavaVM makes the same mistake as Forth standards up to Forth-83: It
     specifies type sizes (e.g., a JavaVM int is always 32-bit). A few
     operators have to be added to support this.

  o  The native libraries (without them JavaVM can do nothing).

