Forth Interpreter in Java

Question

Here I found a Simple Forth Interpreter implemented in Java.
However I don't understand the significance of it if I want to use it?

What could be the advantage of the Forth Interpreter:

• If the final compiled code to be executed by the JVM is still "Byte code" what would we the Forth Interpreter be doing?
• Will it help in writing efficient/tight programs?
• Will I be writing my code in Forth and the interpreter will convert it to Java?

Your thoughts...

Answer 1

Will it help in writing efficient/tight programs?

That's debatable.

I'm sure that FORTH folks will tell you that it is fast. But I doubt that the execution speed of a FORTH program running on a FORTH interpreter implemented in Java will line up against the speed of an equivalent program implemented directly in Java. For a start, the JIT compiler won't be able to do as a good job of optimizing the FORTH interpreter as it can for the plain Java version.

If by "tight" you mean "using less memory", I think that the difference will be marginal. Remember that in both the "FORTH in Java" and "plain Java" cases you have all of the memory overheads of a Java JVM. This is likely to swamp any comparison of FORTH code density versus equivalent compiled Java code density.

Answer 2

The author on the page describes at as implementing a subset of FORTH and being suitable for incorporationg in other applications; presumably it is intended to provide a scripting capability for an application. It's fairly unlikely that the system works by spitting out java or JVM byte codes; it almostly certainly uses an interpreter written in Java.

Traditionally, a FORTH interpreter can be implemented in a very small memory footprint. I know someone that implemented one on a COSMAC and the core interpreter was 30 bytes long. The stack oriented byte code was also very compact as it did not need to specify the location of operands - it just read from the stack and deposited the result on the top of the stack. This made it popular in embedded systems circles where the small overhead of the interpreter was more than offset by the compact representation of the program logic.

These days it's less important as machines tend to be much larger, although digitalross makes a good point about other situations where FORTH is still used.

Answer 3

Not a bytecode translator

The answers to your questions are: "see below, sort of, and no".

It's just a program that takes some input and produces some output. The input is a Forth script. Except for some very major systems, it's rare to actually produce bytecode. jRuby, Clojure, Scala .. big systems like that do produce bytecode.

However your Forth interpreter is probably just that: a script interpreter that happens to be written in java. The input it accepts is a program of sorts, so you do end up with a nice double-indirect execution. Forth executing via bytecode interpreter executing via jvm running on the CPU.

Now, if you ran that on a CPU emulator, or wrote an interpreter in Forth, you could make it triple-indirect. (And in a sense it is already, because your Intel CPU is translating most x86 opcodes into micro-ops before executing them. :-)

Anyway, the point is that a program written in a rather static language like java might want to take some complex user input and execute it, or perhaps the author of the program has things that are more easily done in forth, and this allows him to write in both java and forth.

You should think about all of this until you understand it.

Answer 4

It does allow you to write efficient/tight programs. Partly because the ability to define defining words (words executing at compile time) can have the effect of effectively defining a Domain Specific Language (DSL). Forth also encourage refactoring (otherwise the stack stuff simply becomes incomprehensible ...) and thus the code will be tight.

Answer 5

7th is IMHO closer to the original design of forth than any other RPN language on the JVM. There is an editor with line-numbering and code beautyfier. There is a matching implementation of the "interpiler" and the dictionary with vocabulary/current/context. Conditionally most of the hardware dependent words – to store to or fetch from a specific memory address – are missing. Any words for memory calculating on the JVM would be quite senseless anyway. Some useful additions over the forth syntax has been made in 7th:

• the word help
• 7th is object oriented
• there is a perl like pattern matching
• complex numbers and arrays are part of the language
• a redirectable/nopeable mechanismus to optionally send output to stack or console and prevent execution of file-io words eg. while testing

Answer 6

There are several Forth systems that implement an Forth interpreter in Java. There are two that I know of that actually compile the forth source into a JVM class and allow you to execute the Forth code directly without the need for the interpreter.

• HolonJ by Wolf Wejgaard
• Misty Beach Forth

Answer 7

The main advantage of a FORTH alike interpreter is its interactivity – means I enter a word and get a response immediately. If it needs an intermediate step first, to generate a file or something, this advantage is gone. The second thing is the POL (Problem Oriented Language) aspect: the language must be expandable seamlessly. So, if a FORTH alike language is unable to compile new words, its worthless.