Fortran.CodeCompared.To/Forth

🚨 The format "(a)" is deliberate — list-directed print *, emits a leading space before the text, which is why every Fortran column on this page names its format explicitly.

🚨 print *, 42 would right-align the number in a ten-column field, padding it with nine spaces. Forth's . has the opposite habit — one trailing space, always — which is why a number with anything after it has to be built with pictured output instead.

The two columns print the same text by completely different means: one describes the line and then supplies values, the other emits values and lets the spacing fall out. Note that . prints the top first, so the 4 is printed before the 3 unless they were pushed in this order.

The Fortran column is a batch program: write it, compile it, run it, read the output. The Forth column is a set of words you can call one at a time from a prompt on the instrument, which is the whole reason the language exists. Everything else on this page follows from that one difference in purpose.

A Fortran program is finished before it runs — that is what made it wrong for a telescope being commissioned, where the next thing to try was decided by what the last thing did. Being able to type a new word at the instrument is the capability Moore was buying.

The intent(in) that tells the Fortran compiler this argument will not be modified has no counterpart at all: a Forth word may consume, replace, or leave extra cells, and only the comment says which. What you get back is a definition that fits on one line.

The saving is real and so is the loss: the Fortran caller names each result at the call site, and the compiler checks the count and the types. Here the comment says -- remainder quotient because /MOD leaves the quotient on top, and nothing verifies that claim.

The result(answer) clause exists because a recursive Fortran function cannot use its own name as the result variable. Forth has the mirror-image problem and the mirror-image answer — writing FACTORIAL inside the body would find an earlier word of that name, which is occasionally exactly what you want.

This is one of the few places Forth is the safer of the two by default. It comes from the same property that makes everything else risky — there is one flat dictionary and a name is either in it or it is not, so there is no declaration to have been skipped.

Fortran knows the shape, so sum works on the whole array and the compiler can check conformance. Here the loop is written out and #READINGS is a promise: change the initialiser without changing the constant and nothing complains.

Both columns print the same two numbers, and the indices that produced them are 1, 2 on one side and 0, 1 on the other — which is the whole row. Nothing checks the Forth index, so 3 READING quietly reads whatever was defined next.

Array sections are the thing Fortran is best at and the thing Forth has least of — no shape, no conformance checking, and no elemental operations. A numerical program that leans on them has no idiomatic translation here at all.

🚨 The layout here is row-major because that is what row * COLUMNS + column means, while Fortran stores columns first. That difference is invisible until a program walks memory in order and gets the slow traversal, which is the classic Fortran performance trap in reverse.

Every Forth definition is effectively in one common block: the dictionary is flat, there are no modules, and a name is visible to everything compiled after it. The old Fortran hazard of two units describing a common block differently has no counterpart, because there is only one description.

Naming conventions carry the whole weight on a large Forth program, and systems that outgrow them add vocabularies — a mechanism this implementation does not have. It is the clearest scaling limitation on the page.

A program that needs 16-bit storage packs two values into a cell by hand, and one that needs 64 keeps two cells and does the carries itself. The width is a property of the system, so the same source prints 64 on a desktop Forth.

The <# … #> sequence is pictured numeric output, building the text right to left one digit per #. For a reader whose working life is numerical, this is the single biggest thing missing — and it is missing from this implementation, not from Forth generally, which has an optional floating-point word set.

🚨 /MOD's rounding is implementation-defined: this Forth truncates and prints -3 -1, while gforth floors and prints -4 1 for the same line. Code that cares must say SM/REM or FM/MOD and supply the double-cell dividend that S>D makes.

🚨 The limit is also pushed first in Forth — 5 0 DO, not 0 5 DO — which is the reverse of how the range reads aloud. Between the two differences this is the likeliest place for a Fortran reader to produce an off-by-one that still runs.

?DO is the version that tests before the first iteration, and it is what you want whenever the count comes from a variable. A Fortran reader has not had to think about this since 1977, which is exactly why it catches people.

The DROP before LEAVE is required because the reading is still on the stack and nothing else will take it. Fortran's exit needs no such care, because the value was in a declared variable that simply stops being read.

That is the jump table a select case on small integers usually compiles into, built by hand and visible. There is no case default and no bounds check: an index of 3 reads the cell after the table and executes it.

🚨 Fortran's blank padding is the trap in the other direction: assigning a shorter string leaves trailing spaces, which is why trim appears everywhere in real code. Forth has no padding and no trim, because there is no declared width to pad to.

Defining a missing word is ordinary Forth practice rather than a workaround, and it is one line because the operation really is just "add to the address, subtract from the length". No copy is made in either column; Fortran's substring is also a reference into the original.

Doing it by hand makes the cost visible — one buffer, one copy per piece — and makes the buffer's size your problem. The 32 ALLOT is a promise nothing checks, where Fortran would have rejected an over-long assignment at compile time.

Twenty lines against five, and the twenty buy a compile-time guarantee that the procedure takes one integer and returns one. A token that was never a token executes anyway and does something undefined.

Fortran's nearest equivalent is a procedure pointer, which needs a declared interface and an explicit type. This is how a Forth driver is retargeted on a running instrument — the capability the telescope job was really about.

There is no allocator to fail, fragment, or need a heap size chosen up front — memory use is decided when the program is loaded. That is a real property for an instrument that must not stop, and a real limitation for anything whose size depends on the data.

The two symbols read as "store" and "fetch", and getting their argument order backwards writes to the value instead of the address. Fortran's pointer is checked — it knows what it may point at and whether it is associated — while an address here is a number like any other.

Nothing records that these two words address one object, and nothing stops another word from writing something unrelated through >Y. What Fortran calls a component reference is here an addition that has been given a name.

Both are the same design — report failure in a value the caller must look at. The difference is that Fortran's read without iostat halts the program, while >NUMBER has no halting mode at all and always returns.

CHECKED is defined to show the shape but is not run, because 30 CHECKED would end the program and nothing after it would print. This Forth has no CATCH, so there is no way for a caller to survive an abort — which is why a Forth library returns a flag instead.

Because the value is computed by ordinary Forth, the expression can be anything a word can do, including reading a file if one were available. There is no separate constant-expression language with its own rules, because the same interpreter is running either way.

Fortran's metaprogramming is cpp, a text substitution pass that knows nothing about the language it is preprocessing. A Forth macro is a word, running on the same stack, able to read ahead in the source and add control structures to the compiler — the same material as everything else.

This is the difference most likely to stop a Fortran reader on their first line. Your own definitions keep whatever case you gave them, so : Greet does not define GREET — and most desktop Forths fold case, so an example copied from a book may work there and fail here.

That is why - subtracts the top of the stack from the cell beneath it — it is the spelling that makes 10 3 - mean what a reader expects. Getting the order wrong produces a perfectly valid program that computes the wrong thing, with no keyword arguments to fall back on.

🚨 The second line prints 999 — the next cell laid down, which belongs to nothing at all. Nothing is corrupted and nothing is reported; the program simply reads something that was never an element, which is the failure mode a bounds check exists to prevent. A bare 999 , is used rather than a second CREATE because CREATE would lay a dictionary header in between, and index 3 would land in the middle of it.

It answers 104 without complaint. Checking the stack with .S after any word you are unsure of is the habit this produces, because a wrong answer is the only symptom — and on a program of any size that is a very long way from the mistake.

APPLY-SCALE was compiled earlier and still calls the first SCALE, so the two columns print the same numbers by quite different means. It also means fixing a bug in a low-level word does not fix its callers until they are recompiled.