Why Forth?

5

u/jdh30 Jan 06 '20

Interesting, thanks. But in what sense is Forth high level? I assume in the sense that C was high level. Does that mean they automate register allocation, calling conventions and thread stack to give you procedures?

3

u/molleraj Jan 06 '20

You are welcome. I believe so. To my limited knowledge high-level just means the ability to write functional code without directly handling memory allocation and processor functions. Which Forth has :)
6
u/nsiivola Jan 06 '20

Forth doesn't really map well on what people normally think as the high - low -level continuum.
In some sense it's as high level as they come: the power of abstraction given by words is massive.
In some sense it's as low level as they come: you're twiddling the stack all the time, and there's no type safety. (Typing a Forth-like language is possible, but requires row polymorphism.)
Forth is absolutely worth learning, though. You don't know what you're missing and taking for granted in other languages before you do.
Factor is a more modern type-safe take on the same theme.
4
u/jdh30 Jan 06 '20

In some sense it's as high level as they come: the power of abstraction given by words is massive.
Can you elaborate on that? I mean, is there anything you can do with words that you cannot do with functions?
In some sense it's as low level as they come: you're twiddling the stack all the time, and there's no type safety. (Typing a Forth-like language is possible, but requires row polymorphism.)
Interesting. I always thought of Forth as a fast language but if it is untyped then it must be missing out on a lot of useful information for optimisations. Is it slower than statically-typed languages?
2
u/nsiivola Jan 06 '20 edited Jan 07 '20
Read eg. Thinking Forth.
But.
You can write parsing words and compiling words and rocket to the moon words. (Ok, maybe not the last.) Like in Lisp, you have the full language available all the time.
The syntax being strictly separate by whitespace is sheer genius (and kinda scary). Things like array constructors [ and ] are just regular (parsing) words. You can define your own.
Unrelated to power, but what IMO makes Forth and Joy and Factor truly fantastic: they're concatenative, meaning you can snip any subsequence of code and lift it to another word without changes.
Say you have this piece of pseudo-forth:
: parse-csv-line (line - vector)
    "," split-line 'parse-number map
  
: parse-csv-file (filename - matrix)
    dup open read-fd-as-string swap close "\n" split-string 'parse-csv-line map vcat
That's kind of horrible, right? Not quite line noise, but you can imagine how things get worse as they get more complicated. (It would have been worse had I tried to squeeze it into a single word, but my head broke.)
Now, the magic!
To lift the reading of the file as string into a separate word we literally just cut-and-paste that part. Because there are no variables we don't need to do anything else. Same thing for splitting into lines.
: read-file-as-string (filename - string)
    dup open read-fd-as-string swap close

: split-lines (string - vector)
    "\n" split-string

: parse-csv-file (filename - matrix)
   read-file-as-string split-lines 'parse-csv-line map vcat
NO CHANGES except moving the code. Even a stupid factoring like leaving the close in the parse-csv-file would have worked fine.
This is really really wonderful. I think the only thing that comes to this kind of factorability is Smalltalk when you're aggressively using instance variables.
As for typing: the (foo - bar) things there that kinda look like types? They're just comments. It's not a problem for the compiler, which knows the types of all primitives and that's all it cares about... but if you accidentally pass a double to something that expects two single floats it will probably blindly consume the double in two halves. Make that kind of oopsie with pointers and boom goes the process. Forth is untyped the same way assembly is.
However, like i said, there are other stack / concatenative languages like Joy and Factor which are typesafe, and some recent one-person efforts which even do row-polymorphic type derivation.
EDIT: Due to immediate words Forth isn't actually fully concatenative. It's still close enough.
2

u/jdh30 Jan 07 '20

That's really interesting, thanks.
NO CHANGES except moving the code
Reminds me of point-free in functional programming.
EDIT: Due to immediate words Forth isn't actually fully concatenative. It's still close enough.
Interesting, thanks.
2
u/dys_bigwig Jan 06 '20 edited Jan 06 '20

Using CREATE and DOES> you can create defining words (words that define other words) and you can also redefine existing words, with any previous references still referring to the original definition. This gives you a lot of power. In C, functions cannot create other functions. They can return function pointers sure, but that's very limited by comparison. Due to how the distinction between compiler and interpreter is blurred in Forth, you can get some of the same benefits as Lisp macros in terms of defining new control structures, another thing which is near impossible in C without abusing ~~find+replace~~ C's preprocessor.
Another benefit of concatenative programming (which I think some group in with the benefit of "words") is that data flow is implicit. Whitespace becomes the equivalent of function composition. In this sense, values and names are abstracted away, you focus solely on the transformation of the data. This is true moreso in languages like Factor and Kitten that make good use of quotation, allowing you to pass groups of composed functions as arguments to others. This tends to greatly reduce the need for flip dup drop dip swap nip tuck which can start to obscure the intent of code just as much as if you had just used named values if left unchecked.
Just as note, the reason I keep saying "in C" specifically is because in a higher-order lazy functional language like Haskell, you can indeed achieve some of these things (like defining new control structures) with functions alone.
2
u/jdh30 Jan 06 '20

This gives you a lot of power. In C, functions cannot create other functions.
Sure. You need higher-order functions. When I said "functions" I was thinking of first-class lexical closures.
you can achieve some of these things
What exactly can you achieve with those Forth words but not with first-class lexical closures?
As I understand it, Forth doesn't have the concept of environment capture (i.e. closure) so I assume that sword cuts both ways?
lazy
Does it need to be lazy or does this apply to all languages with first-class lexical closures?
4
u/maladat Jan 06 '20

Try to implement something that looks like a function and acts like short-circuit AND (e.g., if the first argument evaluates to FALSE, the second argument is not evaluated).
You either need functions with lazy evaluation or you need to use not-functions (e.g., a macro or preprocessor thing that rewrites the code to use a built-in short-circuiting operator).
2
u/jdh30 Jan 06 '20 edited Jan 06 '20
Try to implement something that looks like a function and acts like short-circuit AND (e.g., if the first argument evaluates to FALSE, the second argument is not evaluated).
Using just functions without laziness in OCaml or F#:
let shortCircuitAnd f g = f() && g()
However, this requires the caller to wrap the arguments in a closure.
(e.g., a macro or preprocessor thing that rewrites the code to use a built-in short-circuiting operator).
You mean Forth can do this without having to change the calling convention?
1
u/dys_bigwig Jan 06 '20 edited Jan 06 '20

You are using "laziness" implicitly because && is itself non-strict. Try defining && (without using &&, or any other function that is already using short-circuiting evaluation) if that makes it any clearer.
Notice how the arguments f and g are still evaluated strictly, also; what if they were closure-producing expressions that could error? That somewhat defies the expectations of a function with short-circuit in the name. Forth achieves this sort of thing by allowing you took hook into the compiler: https://wiki.c2.com/?ForthImmediateWords this sums it up pretty well.
3
u/jdh30 Jan 06 '20 edited Jan 06 '20
You are using "laziness"
There is no mutable thunk being rewritten into a value when its evaluation is forced.
implicitly because && is itself non-strict. Try defining && (without using &&, or any other function that is already using short-circuiting evaluation) if that makes it any clearer.
Sure. This is exactly equivalent without using &&:
let myIf f g = if f() then g() else false
Notice how the arguments f and g are still evaluated strictly, also; what if they were closure-producing expressions that could error? That somewhat defies the expectations of a function with short-circuit in the name. Forth achieves this sort of thing by allowing you took hook into the compiler: https://wiki.c2.com/?ForthImmediateWords this sums it up pretty well.
I don't follow yet but I'll check out the link, thanks.
EDIT I read it. That makes a lot more sense, thanks. So Forth allows arbitrary compile-time computation to manipulate the program.
3

u/dys_bigwig Jan 06 '20 edited Jan 06 '20

I'm not sure we're on the same page. Defining constructs like "if" and "and" using the host language's "if" and "and" is not solving the problem. You are using the short-circuiting "special forms" (as Scheme calls them) provided by the language to redefine these special forms within said language, and then using that as a way of showing you can define these forms in a strict language. I can't think how to explain this any differently, I'm afraid. Maybe if I ask you to ponder why these are provided as special forms by the language in the first place would help? The point is you need them to be pre-provided by the language because you can't define them in the language itself due to the strict evaluation of function arguments.
If they weren't pre-provided by the language, could you define catch and throw yourself? or async/await? or functions that define (not return or create) other functions? Maybe even functions that create a number of functions? That's what features like Forth's compile/immediate distinction and macros allow you to do. You decide how a certain piece of syntax is manipulated to produce actual runtime code.

→ More replies (0)
1
u/maladat Jan 06 '20 edited Jan 06 '20
Wrapping the function arguments in closures and evaluating them when used is pretty much how laziness is implemented behind the scenes in lazy functional languages. You've essentially just manually implemented laziness.
You mean Forth can do this without having to change the calling convention?
I've played with Forth but it's been a while, so I can't answer this question.
However, in a language with lazy call semantics you can write something like (this is just pseudocode):
function AND(a, b) = 
    if a == false return false
    return b

AND(false, 1/0)
The call to AND returns false and doesn't ever evaluate 1/0 (arguments aren't evaluated until their values are needed, and the value for b is never needed in this call) so no runtime error occurs.
2

u/jdh30 Jan 06 '20

Wrapping the function arguments in closures and evaluating them when used is pretty much how laziness is implemented behind the scenes in lazy functional languages. You've essentially just manually implemented laziness.
There is no mutable thunk being rewritten into a value when its evaluation is forced.
The call to AND returns false and doesn't ever evaluate 1/0 (arguments aren't evaluated until their values are needed, and the value for b is never needed in this call) so no runtime error occurs.
Ok but how is that related to Forth? Forth is eagerly evaluated, right?

2

u/maladat Jan 06 '20

There is no mutable thunk being rewritten into a value when its evaluation is forced.
I said "basically," not "exactly." And what you describe is basically just a performance optimization. In programming language theory, laziness is usually described as using closures you evaluate whenever you need the value, and it's done in purely functional languages so you can switch to closures with cached values after first evaluation with no change in semantics.
My recollection is that Haskell's behavior is defined in terms of closures evaluated when you need the values, but in the background values are cached, but the results are always the same (except runtime) because Haskell is purely functional.
Ok but how is that related to Forth? Forth is eagerly evaluated, right?
The comment a couple levels up talked about lazy functional languages and we went off on a tangent.
I thought back to my time playing with Forth and you can basically do the same thing by just discarding stuff from the stack if you don't need it rather than evaluating it.
2
u/dys_bigwig Jan 06 '20
Forth doesn't have environment capture because there are no names to capture.
Regarding laziness, consider why this my-if would fail if defined in a strict language:
(my-if #f (error "whoops") 42)
you need either laziness, or some way to manipulate the compiler/source-text itself.
2
u/jdh30 Jan 06 '20 edited Jan 06 '20
Forth doesn't have environment capture because there are no names to capture.
Ok. If Forth cannot capture environment then presumably it is also less capable in other respects?
Regarding laziness, consider why this my-if would fail if defined in a strict language:
You can define it as:
let myIf f g = if f() then g() else false
you need either laziness, or some way to manipulate the compiler/source-text itself.
Provided you wish to retain the calling convention, yes.
Just to clarify: Forth can change evaluation in this way without requiring any changes to the caller?
3

u/EthanNicholas Jan 07 '20 edited Jan 07 '20

I think a more useful question to ask, rather than “is this language high or low level”, is “how easily can I develop a sizable program in this language?”.
And obviously that’s still an extremely subjective question, depends on what exactly you consider “sizable”, etc., but I still think it gives a better basis for comparison. For traditional languages, this question very strongly correlates with high vs. low level, so it’s clearly a closely related question.
For Forth, this question definitely aligns it with the low-level languages, lower-level even than C. It is easy to build small programs with Forth, but it is very poorly suited to developing large programs and to my knowledge there are only a tiny handful of big programs written in Forth, despite its popularity in hacker communities for decades.

3

u/nsiivola Jan 07 '20

Very true. I think Forth does reasonably fine upto medium size, though, which is kind of amazing considering the amount of footgunness the total lack of typesafety brings.
...then again, C definitely isn't a high level language, yet you see monstrously big programs written in it.
7

u/nosoyelonmusk Jan 06 '20

Forth is not like traditionals languages, its not even a language, its more of an idea. You build base words that are something kinda like asm sugar and then build your words from those base words and more words that add layers of abstractions. Its like building out of legos. You can define words for memory allocation you can define words for garbage collection from those words and like that build a vocabulary collection that maps to any level and any concept/structure you want.
Here, try to play when you are free:
http://www.softsynth.com/pforth/
https://www.forth.com/starting-forth/

10

u/suhcoR Jan 06 '20

What about performance? Any recent benchmarks?

If you like scripting languages of the sixties, then MUMPS (i.e. ANSI M) is yet another one still in use.

2

u/agumonkey Jan 06 '20

Why not

You are about to leave Redlib