What is Forth?

[dwight]

I find statements that Forth is not maintainable to be clearly without merit.
I once had to figure out some code by a person that wrote Forth code
and was obviously a Basic programmer.
Most variables were things like A1 and B2 and such. Still, even with some of
the worst coding I'd seen since looking at poorly written BASIC, I was able to
not only understand what the code did but make the needed modification
to solve the problem ( it was related to intertia and not code ).
I can imagine that a person that is used to seeing tight structure of syntax,
like C might not find looking at Forth as readable.
Well written code in any language is a pleasure to read.
Well written Forth is like reading a a well indexed book. I've never seen any language that compares.
Everything is clearly in sequence. Levels of complexity of task are well organized
so that one can quickly go to any depth to understand the intricateness needed
to solve a particular problem.
When done properly one can easily skip over parts that don't need such depth. Strings
like " 45 ms Delay " or " 45 Degrees CounterClockwise " are not hard to read.
What is missing is all the boiler plate noise found in languages like C.
I can except that there is a learning curve needed for all the ! @ SWAP DUP low level
words of Forth but I think people that see Forth that way are spending
too much time looking at the rebar, gravel, sand and Portland cement to see
the bridge that was built.
Dwight

[whartung]

dwight wrote:

I find statements that Forth is not maintainable to be clearly without merit.

Ok.

Quote:

I once had to figure out some code by a person that wrote Forth code
and was obviously a Basic programmer.
Most variables were things like A1 and B2 and such. Still, even with some of
the worst coding I'd seen since looking at poorly written BASIC, I was able to
not only understand what the code did but make the needed modification
to solve the problem ( it was related to intertia and not code ).

All depends on the size of the code base, and the scope of the change.

Quote:

Well written code in any language is a pleasure to read.

But this implies a high level of familiarity with the language. There are many languages that are unreadable to even a skilled computerist with little background in the language itself. The attraction of the Algol-ish languages is simply the familiarity: from Algol to Pascal to C to Java, C#, JavaScript and even Python. Structurally, at a higher level, all of these languages are identical. As evidence of both their longevity and popularity as a family of languages, they obviously did "something right". Meanwhile, Forth, Smalltalk, the Lisps, and modern functional languages remain niche, despite their benefits.

Quote:

Well written Forth is like reading a a well indexed book. I've never seen any language that compares.
Everything is clearly in sequence. Levels of complexity of task are well organized
so that one can quickly go to any depth to understand the intricateness needed
to solve a particular problem.

Well, most of the Forth I've looked has been Forth implementations. Perhaps, historically, they are not well written, although they are clearly sophisticated.

The example from the video posted above is very nice, I watched that, and it was easy to follow and easy to read. Of course, it's a very small program, and seeing it developed keeps the context of the individual words in mind. However, the presenter mentions how there's little need for a stack diagram. Not surprising in this case, since most of the work is done through global variables.

Consider, from the F83 source code.

Code: Select all

Block 63
\ Interactive Layer           Parsing                 02Apr84map
: /STRING   (S addr len n -- addr' len' )
   OVER MIN   ROT OVER +   -ROT -   ;
: PLACE     (S str-addr len to -- )
   3DUP  1+ SWAP MOVE  C! DROP  ;
: (SOURCE)    (S -- addr len )
   BLK @ ?DUP IF   BLOCK B/BUF   ELSE   TIB #TIB @   THEN  ;
DEFER SOURCE
: PARSE-WORD   (S char -- addr len )
   >R  SOURCE TUCK  >IN @ /STRING  R@ SKIP  OVER SWAP R> SCAN
   >R OVER -  ROT R>  DUP 0<> + - >IN !  ;
: PARSE   (S char -- addr len )
   >R   SOURCE >IN @ /STRING   OVER SWAP R> SCAN
   >R OVER -  DUP R>  0<> -  >IN +!  ;

Now perhaps to you, this is casually readable. It's certainly not to me. The mental gymnastics of tracking the stacks [plural], notably in PARSE-WORD and PARSE, makes my head spin.

Or:

Code: Select all

Block 55
\ Devices                     BLOCK I/O               01Apr84map
: UPDATE   (S -- )   >UPDATE ON   ;
: DISCARD  (S -- )   1 >UPDATE ! ( 1 BUFFER# ON ) ;
: MISSING   (S -- )
   >END 2- @ 0< IF  >END 2- OFF  >END 8 - WRITE-BLOCK  THEN
   >END 4 - @  >BUFFERS 4 + ! ( buffer )  1 >BUFFERS 6 + !
   >BUFFERS DUP 8 + #BUFFERS 8* CMOVE>   ;
: (BUFFER)   (S n fcb -- a )   PAUSE  ABSENT?
   IF  MISSING  1 BUFFER#   4 + @  THEN  ;
: BUFFER   (S n -- a )   FILE @ (BUFFER)  ;
: (BLOCK)    (S n fcb -- a )
   (BUFFER)  >UPDATE @ 0>
   IF  1 BUFFER#  DUP READ-BLOCK  6 + OFF  THEN  ;
: BLOCK     (S n -- a )   FILE @ (BLOCK)  ;
: IN-BLOCK  (S n -- a )   IN-FILE @ (BLOCK)  ;

This code is GORGED with Magic Numbers. In most anything else, those would be named structure elements. Could it have been written with better constants, or could they have loaded a whole Structure package to make this easier to consume? Of course they could. But, the point, as practicing, expert Forth developers, they didn't. Not back then.

I'll finally leave this:

Code: Select all

Block 76
\ Extensible Layer            Defining Words          08Apr84map
: ,VIEW  (S -- )   BLK @ DUP IF  VIEW# @ 4096 * +  THEN ,  ;
: "CREATE   (S str -- )   COUNT HERE EVEN 4 + PLACE
   ALIGN ,VIEW  HERE 0 , ( reserve link )
   HERE LAST ! ( remember nfa )   HERE  ( lfa nfa )   WARNING @
   IF  FIND
     IF  HERE COUNT TYPE ."  isn't unique " THEN  DROP HERE
   THEN  ( lfa nfa )  CURRENT @ HASH DUP @ ( lfa tha prev )
   HERE 2- ROT !  ( lfa prev )   SWAP !   ( Resolve link field)
   HERE  DUP  C@  WIDTH  @    MIN  1+  ALLOT   ALIGN
   128 SWAP CSET   128 HERE 1- CSET   ( delimiter Bits )
   COMPILE [ [FORTH] ASSEMBLER DOCREATE , META ]   ;
: CREATE   (S -- )
   BL WORD  ?UPPERCASE  "CREATE  ;

See, this is "representative" Forth to me, this is the code *I* see, code from "expert" Forth developers. I've shown examples before from Chuck Moore. If there's any notoriety for Forth code, it stems from stuff like this.

Now perhaps it's much different with modern Forth on modern systems, beyond the constraints of 1K blocks.

But then, maybe not. This is from eForth, and comes from a simple text file with no block constraints:

Code: Select all

: parse ( b u c -- b u delta \ <string> )
  temp !  OVER >R  DUP \ b u u
  IF 1 -  temp @ BL =
    IF \ b u' \ 'skip'
      FOR COUNT temp @  SWAP - 0< INVERT  WHILE
      NEXT ( b) R> DROP 0 DUP EXIT \ all delim
        THEN  1 -  R>
    THEN OVER SWAP \ b' b' u' \ 'scan'
    FOR COUNT temp @ SWAP -  temp @ BL =
      IF 0< THEN WHILE
    NEXT DUP >R  ELSE R> DROP DUP >R 1 -
                 THEN OVER -  R>  R> - EXIT
  THEN ( b u) OVER R> - ;

Again, dominated by stack operations, clouding (IMHO) the logic.

As a consumer of source code, the invisible stack shenanigans raises the cognitive load, at least for me. When the code is jumping in and out of named variables, the variables convey information germane to the context. Obviously, with badly named variables (a, b, x, q1, q2), you're just a step above the invisible stack. But at least the data flow is first class in the code, and not hidden.

Quote:

When done properly one can easily skip over parts that don't need such depth. Strings
like " 45 ms Delay " or " 45 Degrees CounterClockwise " are not hard to read.
What is missing is all the boiler plate noise found in languages like C.
I can except that there is a learning curve needed for all the ! @ SWAP DUP low level
words of Forth but I think people that see Forth that way are spending
too much time looking at the rebar, gravel, sand and Portland cement to see
the bridge that was built.

All of the Forth I've seen is pretty much nothing but sand and gravel, and it's apparent that the developers were comfortable at this level.

All of that "boiler plate noise", like the parentheses of the Lisps, vanish during reading, at least for me. Assuming the code is properly indented. Its still a reality as a developer, you have maintain all of that "noise", but from as a consumer of source code, that stuff all goes away. I don't even see it.

[dwight]

Please look at the source code for C or BASIC.
Again, you are looking at the wrong things.
Dwight

[GARTHWILSON]

A current Forth, Inc. employee posted about these modern applications that were done just in the last few years in Forth:
https://selinc.com/products/ICON/ used by power companies in security and managing communications at substations
http://www.gegridsolutions.com/Communic ... gleMUX.asp also used in electric power substations
https://www.radeuslabs.com/satcom/model-8200-acu/ antenna controller for deep space communications ground stations
http://minimusspine.com/ medical ozone-injection control for spine treatment used in Europe
http://logix-controls.com/engineered-solutions-archive/ controllers for industrial refrigeration systems and data analysis
https://web.archive.org/web/20200607042 ... ansmitter/ medical wearable devices
http://www.merj.com/solutions/ used in financial trading and currency exchange markets, risk analysis (or https://web.archive.org/web/20161023025 ... solutions/ )

[jazz]

I must be honest - I find most such claims to be questionable.
Especially when I see the manufacturers claiming 9001 standard development.
(as the first one listed does)
This suggests a documentary tool-chain I've never seen in any forth system.
In fact I was just reading some old usenet posts where people are complaining
there ARE no tool chains for forth.

Whilst that isn't strictly true you do have to pay a very large sum of money
to 1 of 2 companies in the world to get anything even remotely usable in a
business environment.

and as for maintainable - would you ever see a C programmer creating a
function simply called "parse" ? Not anywhere I've been you wouldn't.

I think you'd need better examples to convince me of maintainability of forth
for anything other than minority hobby use.
and what about reverse engineering? I can reverse engineer C programs all the
way back into flow charts if I want to - what tools does forth offer for code maintenance?
Admittedly its expensive to buy a decompiler for executables but they do at least exist
and the flowchart stuff is not overly expensive if you have the C source.

Is there even a flowchart tool targeted at forth development never mind any form of project
control? I've never seen anything to support Forth development. Not even a half decent IDE.

[BigEd]

Perhaps I could respectfully suggest that if you don't see the merit in Forth, you either try to see it, or leave Forth alone. Being outspokenly negative about it isn't conducive to a useful exchange of ideas.

[dwight]

jazz wrote:

and as for maintainable - would you ever see a C programmer creating a
function simply called "parse" ? Not anywhere I've been you wouldn't.

Actually, he may have hit the nail on the head. Forth is transformer language.
You don't really write programs in Forth, you transform Forth into the desired
application.
You are probably right, no C programmer would even have thought to do this.
"parse" is a end purpose word. The thought to have created such a word to
make the interpreter/compiler process input streams is the essence of the
use of the Forth language.
I can see quite clearly that a C programmer would never have considered such
a function.
Dwight

[GARTHWILSON]

The links I provided came from a current Forth, Inc. employee, a programmer who worked on some of these. I think it's a pretty reliable source. The page https://www.forth.com/swiftforth/ addresses your other criticisms. You get a great tool chain, and all the source code. Even at its beginning decades ago, Forth provided its own IDE, integrating the editor, compiler, disc operations, command-line interpreter, etc., although these have improved greatly over the decades. A former boss took a look at the simple Forth system I have on the workbench and admitted that the $8000 C development system his company just bought could not compete with mine in interactiveness. SwiftForth is not used by hobbyists though. BTW, I've never had a problem with code maintenance on things I wrote in Forth many years ago.

Here's another one: Software to estimate and control costs for large industrial construction. It's 1.2 million lines of Forth. http://constructioncomputersoftware.com/

And another, not quite as new: http://www.carinasoft.com/voyager.html
The first paragraph of the web page says,

• View the heavens on your computer from any place on the Earth, in the Solar System, or beyond. Witness celestial events thousands of years in the past or future. Voyager includes millions of stars, clusters, nebulae, and galaxies visible only through powerful telescopes. This professional version of our software is designed for the advanced user with a serious interest in astronomy. Voyager can be used to control computer-driven telescopes to show you what is actually being simulated on your computer screen. Voyager 4.5 includes a powerful set of features and capabilities.

[dwight]

One other point to consider. High level Forth written with the proper
use of white space is often indistinguishable from a proper
flow diagram. That is the hole purpose of using Forth in the
first place.
A guess that is a good reason to make a business of writing
C so that the code can extracted in a flow chart.
Dwight

[BigDumbDinosaur]

jazz wrote:

This suggests a documentary tool-chain I've never seen in any forth system. In fact I was just reading some old usenet posts where people are complaining there ARE no tool chains for forth.

I'm not a Forth user and in fact, cannot even understand why anyone would want to use Forth. However, in Forth's defense, I will point out that Forth is its own toolchain, much as timesharing versions of BASIC such as BBx and Thoroughbred are self-contained development environments. If you are looking for an editor/compiler/linker type of environment in Forth, they are not distinct entities as they are in most development situations. In Forth it's all rolled into one.

[whartung]

BigDumbDinosaur wrote:

jazz wrote:

This suggests a documentary tool-chain I've never seen in any forth system. In fact I was just reading some old usenet posts where people are complaining there ARE no tool chains for forth.

I'm not a Forth user and in fact, cannot even understand why anyone would want to use Forth. However, in Forth's defense, I will point out that Forth is its own toolchain, much as timesharing versions of BASIC such as BBx and Thoroughbred are self-contained development environments. If you are looking for an editor/compiler/linker type of environment in Forth, they are not distinct entities as they are in most development situations. In Forth it's all rolled into one.

To that point, many Forth are (can be) self hosting as well. In that not only is the tool chain present, but the entire source tree of the entire kit. Forth can be used to change and rebuild itself if the developer is so motivated. Especially with the Forth meta compilers. Want to change your Forth from a Indirect style to a Direct style, you can do that, and since much of the code is already in high level Forth, even for a change as significant as that, you probably wouldn't have to change that much. The basic inner interpreter and the compiler, plus any words dependent on the internal layout of the compiled code.

I do, however, have to comment on this:

Quote:

Here's another one: Software to estimate and control costs for large industrial construction. It's 1.2 million lines of Forth.

I only point it out not because I question it (that's a large system, in any language), but in contrast to the style promulgated by Chuck Moore and Jeff Fox. Moore has done some significant software in very small space. He's rumored to have started development on one system basically with DOS DEBUG, and typing in binary code to get a Forth started and going from there. All living on a single floppy. If you've ever seen his talks, he talks about doing stuff in "1% of the code" as other systems.

I don't think that 1.2M lines of Forth is the Forth world that Chuck lives in.

[GARTHWILSON]

whartung wrote:

I don't think that 1.2M lines of Forth is the Forth world that Chuck lives in.

That goes with a quote of his that says something like, "If a program has millions of lines of code, someone has not understood the problem."  Regardless, that software package is big-league stuff, not hobbyist stuff.

[nyef]

whartung wrote:

To that point, many Forth are (can be) self hosting as well. In that not only is the tool chain present, but the entire source tree of the entire kit. Forth can be used to change and rebuild itself if the developer is so motivated. Especially with the Forth meta compilers. Want to change your Forth from a Indirect style to a Direct style, you can do that, and since much of the code is already in high level Forth, even for a change as significant as that, you probably wouldn't have to change that much. The basic inner interpreter and the compiler, plus any words dependent on the internal layout of the compiled code.

As a data point here, my own (32-bit x86 Linux) Forth system builds both DTC and ITC versions from the same source base. The difference between the two is that each loads a different metacompiler target specification file as part of the build process, which in turn specifies a different "kernel" source file. Total size of both control files together is 1520 bytes. The "kernel" files define the "address interpreter" and parts of variables, constants and DOES>. Total size of both kernel files together is 1200 bytes. The rest of the system weighs in at less than 12K for the metacompiler, less than 8K for the assembler, and about 38K for the rest of the target system. About 4K in build scripts and shared target configuration, about 13K in making Jonesforth a usable bootstrap host, and a bit over half a K in making gforth a usable bootstrap host. And a 1.5K Makefile. And this is not a particularly featureful implementation at this point. The built system is less than 14K total (and the x86-32-DTC target is 100 bytes smaller than the x86-32-ITC target). So, 2720 bytes (2.5K?) for the DTC and ITC specific parts (ITC source is smaller by 6 bytes), vs. about 57K for the entire rest of the system, not counting toplevel build scripts and host environment fixups. Somewhere between 2 and 3 percent of the overall source built for a particular target is threading-model-specific.

Admittedly, the control files contain such egregious hackery as

Code: Select all

: target-set-:-CFA
  S" colon @ LITERAL,A ] CALL, [" EVALUATE
 ;

which is invoked with

Code: Select all

: : HEAD [ target-set-:-CFA ] ] ;

Yes, that's the metacompiler compiling the target system's compiler. The first colon invokes the compiler, the second colon is the name of the (target) word being defined. HEAD sets up the new dictionary header, the left-bracket leaves metacompilation state for interpretation state, the egregious hack is run to compile the code to set up a DTC (or ITC) CFA, the first right bracket re-enters the metacompiler, the second right bracket is to enter the compiler (on the target), and the semicolon ends the definition. As far as target-set-:-CFA itself goes, it's defined before colon (a variable created by the metacompiler and used to store the address of part of the "kernel"), LITERAL,A (which compiles a literal that has some displacement to account for a lack of sophistication in my approach to metacompilation), and CALL, (which assembles a literal x86 call instruction), hence the use of INTERPRET.

There's probably an opening here for a discussion of metacompilation approaches and techniques, but that should probably be a separate thread if anyone is interested... Or do we have such a thread already?

[BigEd]

Sounds like an excellent idea for a thread!

[larsbrinkhoff]

nyef wrote:

There's probably an opening here for a discussion of metacompilation approaches and techniques, but that should probably be a separate thread if anyone is interested.

I'm very interested.