In article <·····················@informatik.tu-muenchen.de>,
Bernd Paysan <······@Informatik.TU-Muenchen.DE> wrote:
>
>As Julian V. Noble noted, FORTH is not described by syntax, but by
>semantics (and the syntax is described by the semantics of the scanner/
>parser process). FORTH uses ad-hoc scanners (WORD and PARSE, despite
>the second is named PARSE, it is a scanner!) which walks through the
>input stream. [ ... ]
> [ ... ] so the whole sytax of FORTH is extensible.
> [ ... ]
>It is not possible to explain FORTH's "syntax" with BNF, since BNF is
>restricted to stack automats. The interpreter of FORTH is however equal
>to a turing machine, so you can't express it with BNF.
>
Compare to another language that is defined by it's virtual machine
semantics: Lisp. Lisp has a very minimal syntax - Expressions are
Atoms or S-Expr's. Programs are a sequence of Expressions. Define
Atoms and S-Expr's and you're finished! You could try do go on and
write the syntax for all of the standard functions, but they and
their syntax can all be redefined. Still - enough of the core language
is usually defined to explain the semantics of the read-eval-print
loop of the virtual machine.
Forth has an even less fixed syntax than Lisp. The language is really
defined by the semantics of the virtual machine.
Re: "What is Forth not good for?"
Since Forth and Lisp are both extensible, they both lend themselves to
the technique of implementing a new "higher level" domain oriented
language on top of the base language, and that is in fact the best
way to approach programming in both those languages.
However the virtual machine abstraction of Forth is much more low-level
that the Lisp virtual machine. This makes Forth much better for
low-level tasks, and is one reason for it's popularity in embedded
control tasks. What it most lacks is things like type-checking,
bounds-checking, etc.
I have heard of several instances where software was prototyped in
Lisp, to take advantage of it's safety and development features,
and then the debugged product was translated and implemented in Forth
to take advantage of it's effecient implementation.
[ Memory being so much cheaper and available, and Lisp implementation
having gotten much better, I don't know if this is still common. ]
Since all Forth words are verbs ( even "1" is the command to push the
value 1 on the stack. ), it especially lends itself well to control
tasks. ( In my experience, controlling an electron-microscope, where
LINE, FRAME, COLLECT, etc. become the base words for a microscope
control "language" . )
Another similarity of Forth and Lisp: they both grew up largely but
not entirely on dedicated Lisp or Forth machines, so they tend to
be awkward to interface to the native OS or other languages in a
standard way. This is somewhat implementation dependent, and Forth,
because of it's low level nature and the fact that it usually contains
an assembler, can almost always be glued, if awkwardly, to external
functions. ( And if you use a c-forth implementation, this is probably
not going to be a problem. )
[ "Forth only" replies to comp.lang.forth,
Other Forth vs. Lisp comparisons or language wars directed to
comp.lang.misc ]
- Steve Majewski (804-982-0831) <·····@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
In article <··········@murdoch.acc.Virginia.EDU>,
·····@elvis.med.Virginia.EDU (Steven D. Majewski) writes:
> Re: "What is Forth not good for?"
> Since Forth and Lisp are both extensible, they both lend themselves to
> the technique of implementing a new "higher level" domain oriented
> language on top of the base language, and that is in fact the best
> way to approach programming in both those languages.
This is why Forth and Lisp are my favourite languages. Forth
came first, out of an interest in minumal grammers. I was
actually thinking of prefix notation, but not having read
*any* compiler theory, I know nothing. Most of my early
prectical compiler experience came from using and then
implementing Forth.
Lisp came a few years later, at just time when I was becoming
frustrated at some of the limits of Forth. I could have just
built something higher level on top, as some have done, but
I'm not a language designer. Lisp came preformed and ready
to play with, but to do this, I had to write my own. I now
use CLISP, a PD Common Lisp, and Scheme.
I've no idea what's next, but it'll probably be built on
top of Lisp, and some Forth could find it's way into the
stand-alone runtime part.
Martin Rodgers
--- Cyber Surfing on CIX ---
In article <··········@cix.compulink.co.uk>,
Cyber Surfer <············@cix.compulink.co.uk> wrote:
[...]
>I've no idea what's next, but it'll probably be built on
>top of Lisp, and some Forth could find it's way into the
>stand-alone runtime part.
>
>Martin Rodgers
>
>--- Cyber Surfing on CIX ---
GNU Emacs Lisp "compiles" it's code down to RPN bytecodes very much like
Forth. I see no reason why one could not write a Forth frontend to this
bytecode interpreter as easy (if not easier) than the lisp one that
currently exists.
Also, anyone out there given any thought to writing a Forth backend to
any of the GNU compilers (i.e. GCC, etc...)? This would yeild, for
instance, (K&R, Ansi, etc...) C and C++ in, ANS Forth out. With such a
setup one could port, say, a Un*x variant to a stack engine such as the
SC32 or future versions of the MuPnn series. Eventually, time critical
elements of the software could be written in Forth.
Perhaps a mailing list could be setup to discuss any interest in these
projects?
-Kevin
····@cscihp.ecst.csuchico.edu
-------
There are no complex problems; only complex solutions!
-------
Bureaucracy: The process of turning energy into solid waste.
-------
"A politician is a person who can make waves and then make you think
he's the only one who can save the ship." --- Ivern Ball