Forth uses a stack machine. In this way, since calls to functions are really simple and easy, higher performance can be achieved.
I love Lisp, but what you suggest is not really Forth and will also not give you the performance benefits and simplicity of implementation that Forth has.
Even at the most basic level, Forth and lisp are quite different. Lisp has grouping and evaluates using a tree. forth has no grouping* and evaluates completely linearly.
* well you can hack it to give it grouping, but usually it doesn't.
Lisp's abstract model doesn't use stacks to pass arguments. Arguments are just lexical variables and they live in environments like other lexical variables: completely foreign stuff to Forth. Environments often have to survive the termination of a lexical scope's execution; it is required when a closure has escaped. So things can't even be compiled to a stack-based machine, using a "pop everything when returning" strategy: only in some cases.
(ANSI) Lisp function calls are safe w.r.t. wrong number of arguments, and support optional and variadic arguments also. This is true of compiled code without source: when we load someone's compiled file and call a function in it with the wrong number of arguments, it is diagnosed.
Forth and Lisp are so miles apart, that I have to scratch my head why a comparison comes up in discussion from time to time.
(It is pretty much always from someone who uses Forth and doesn't know Lisp (or, worse, anything that isn't Forth). "Hey, I heard Lisp is also interactive and meta-programmable, so it must just be a Forth with postfix switched to prefix and parentheses added ...").
I had this dumb idea of actually evaluating LISP in a forth inspired way. It would be a stack of subroutine/accumulator pairs. so given
(+ 1 2 3)
"(" would pop an pair on a stack, + would set its subroutine, and 1 2 3 would be fed to the subroutine and accumulate a value. when ) is encountered, the data is fed into the subroutine/accumulator pair lower on the stack, so you could still have nesting.
Horribly inefficient, but I thought the idea was neat. I'm sure I'm not the first to think of it though.
some antique famous lisper (Henry .. forgot last name) did write a linear lisp that works by stack evaluation. From the few that I grasped, since everything is mostly duped, it's like a new value each time; free borrowing ?
Higher-level concatenative languages like Factor do feel somewhat Lisp-like because most code is structured with quotations and combinators. But typical Forth isn’t very much like typical Factor or Joy at all, even though they’re all nominally concatenative.
Or in other descriptive terms, Forth could be called "point-free" or "tacit". There is no structure given by the code's context, no named arguments to describe what is in scope - all you have is what is on the stack at the moment of execution, and global variables that the program might access by convention.
Point-free can be a very concise and flexible strategy but also error-prone since (in Forth) it allows the stack to leak and consume/return an unbalanced quantity of arguments. This class of error is eliminated within the syntax of Algol style languages languages but can be reproduced easily if you build your own stack machine.
