>Python is Lisp with syntactic sugar and Lisp is Forth with syntactic sugar.
Those languages have nothing in common other than being pleasant to work with because there isn't too much boiler plate.
Python is dictionary based, lisp is list based and forth is stack based. And that's just the base languages without the fancy stuff like macros and continuations in lisp, all the new syntactic sugar in python (:=, etc) and the bit tricks in forth (-1 = true, 0 = false).
> Those languages have nothing in common other than being pleasant to work with..
That's where the author had an insight, that they (could) have everything in common - except for the syntax on a surface level.
Underneath, languages are just different ways to produce and operate on the same "stuff", data and algorithms - values, function, list, dictionary, stack.
So, to me it makes sense that there can be a Lisp-y flavor of Python, Pythonic flavor of Lisp, Forthy Python, and so on. It's a matter of parsing/compiling them into a common format, targeting the same interpreter or virtual machine.
That said, this Forth-Lisp-Python Continuum verges on mad genius, to have all these different syntaxes in one language.
It was interesting to see this project, since I've been working on a hobby language, whose syntax is infix-oriented like C (but everything is an expression). It gets parsed into a prefix-oriented Lisp-like syntax tree.
The interpreter is a "machine" based on Lisp's eval, with lambda, macro, tail-call optimization, etc. So, basically, the language is just syntactic sugar that compiles down to whatever the machine expects. I plan to implement another (much simpler) parser for a Lisp-flavor of the same language.
In the case of FLPContinuum, I see that the interpreter is a stack-based loop (https://github.com/asrp/flpc/blob/f47de76fcab6d2d2b1840e5376...). The actual implementation of the "machine" almost doesn't matter for the language(s) though, as long as the interface stays the same.
Forth and Lisp are distorted reflections of each other: Forth intends to make it easy to write programs with minimal abstractions, whereas Lisp intends to make it easy to write programs with any abstraction you want. They both, therefore, converged on the notion of having minimal syntax for opposite reasons: Forth eschews most syntax because syntax is an abstraction, Lisp because it isn't necessarily that specific programmer's abstraction.
Python, OTOH, is a single, "frozen" M-synax for a Scheme-like Lisp descendant; if Lisp is a pantry of ingredients and a kitchen, Python is fast food, or a microwave dinner, albeit a relatively good example of such.
> is a single, "frozen" M-syntax for a Scheme-like Lisp descendant
Sounds very close to what Dylan is/was. Well, it still is, in the sense that there's a working, open source implementation (over at https://opendylan.org/), but it basically lacks the last 20 years of optimizations, which makes it, unfortunately, really slow. The ecosystem is also non-existent and very far from ergonomic. Still, it's a very interesting language - basically Scheme + CLOS in M-syntax (though it does have syntax-rules-like macros, so maybe not as "frozen" as Python here.)
Those languages have nothing in common other than being pleasant to work with because there isn't too much boiler plate.
Python is dictionary based, lisp is list based and forth is stack based. And that's just the base languages without the fancy stuff like macros and continuations in lisp, all the new syntactic sugar in python (:=, etc) and the bit tricks in forth (-1 = true, 0 = false).