This is an imperfect answer but in the absence of anything else here are a couple of resources.
I'm not sure if this is what you are looking for but there is a 2013 research paper "SVFORTH - A Forth for Security Analysis and Visualization" (Wes Brown). It discusses a Forth language environment written in JavaScript with primitives and functions that make it useful for security visualization and analysis work.
On the influence of Forth on Bitcoin Script, Andrew Poelstra discussed this during his talk on Miniscript at London Bitcoin Devs in February 2020.
Q - Last question on script. It is very hard to judge Satoshi ten
years on. There’s a lot of subtle complexity here. Do you honestly
think back in Satoshi’s time, 2009 that you’d have had the perspective
to design a better language?
A - The question is in 2009 could I have done better? Or could we have
expected Satoshi to have done better? Essentially no. There are a
couple of minor things that I think could’ve have been done better
with a bit of forethought. For some historical context the original
Bitcoin script was never used. It was this idea for this smart
contracting system and smart contracting was something in blog posts
by Wei Dai, Nick Szabo and Hal and a few other people. It was this
vague idea that you could have programmable money. Script was created
with the intention that you be able to do that. Basically it was a
copy of Forth, it actually had way more of the Forth language than we
have today. We had all the mathematical opcodes and we had a bunch of
other weird stuff. There was also this half baked idea for delegation
where the idea was that your script is a script you execute but also
the witness is a script that you execute. The way that you verify is
you run both scripts in a row and if the final result is true you’re
good, if the final result is false…. The idea is that your
scriptPubKey which is committed to the coins should check that the
earlier script didn’t do anything bad. There were a couple of serious
issues with these, two that I will highlight. One was there was an
opcode called OP_VER, OP version. I can see some grimaces. It would
push the client version onto the stack. This meant that when you
upgraded Bitcoin say from 0.1 to 0.2, that’s a hard fork. Now script
will execute OP_VER and push 0.1 onto the stack for some people and
0.2 onto the stack for other people. You’ve forked your chain. Fortunately nobody ever used this opcode which is good. Another issue
was the original OP_RETURN. Rather than failing the script like it
does now it would pass the script. Because we had this two script
execution model you could stick an OP_RETURN in what’s called your
script signature. It would run and you wouldn’t even get to the
scriptPubKey. It would just immediately pass. You could take any coins
whatsoever just by sticking an OP_RETURN into your scriptSig. Bitcoin
was launched in the beginning of 2009. This was reported privately to
Satoshi and Gavin in the summer of 2010. This was 18 months of you
being able to take every single coin from Bitcoin. In a sketchy commit
that was labelled as being like a Makefile cleanup or something,
Satoshi completely overhauled the script system. He did a couple of
interesting things here. One was he fixed the OP_RETURN bug. I think
he got rid of OP_VER a little bit earlier than that. Another was he
added all the NO_OP opcodes. Around this time if you guys are
BitcoinTalk archivists you’ll notice that talk of soft forks and hard
forks first appeared around this time. It would appear forensically
that around this script update, the one that fixed OP_RETURN was the
first time that people really thought in terms of what changes would
cause the network to fork. Before that nobody was really thinking
about this as an attack vector, the idea that different client
versions might fork off each other. Either explicitly or because there
is different script behavior. And so the NOP opcodes or the NO_OPs
were added as a way to add updates later in the form of a soft fork.
The fact that this happened at the same time as the OP_RETURN fix is I
think historically very interesting. I think it reflects a big leap
forward in our understanding of how to develop consensus systems.
Knowing that historic context the original question was in 2009 could
we have done better? The answer is no basically. Our ideas about what
script systems should look like and what blockchains should look like
and the difficulty of consensus systems, nobody had any comprehension
of this whatsoever. The fact that there were bugs that let you steal
all the coins for over a year tells you that no one was even using
this, no one was even experimenting. It was just weird, obscure thing
that Satoshi put in there based on some Nick Szabo blog posts and
nobody had really tried to see if it would fulfill that vision or not.
Q - Did he literally copy something from Forth or did he reproduce it
selectively or precisely from a manual?
A - The question is did he literally copy from Forth. Or did he use a
manual? I don’t believe there is any actual code copying from any
Forth compiler or something like that. The reason I say that
everything is copied from Forth is a couple of specific things. The
specific things are the stack manipulation opcodes like the SWAP and
OP_ROTATE which rotates in a specific direction that isn’t useful for
Bitcoin but is probably useful in Forth. All of the stack manipulation
semantics seem to have come from Forth. These are just Forth opcodes
just reinterpreted in a Bitcoin context. Beyond that I don’t know
Forth well enough to say. There are a couple of specific things that
are really coincidental that suggest that he was using the Forth
language as a blueprint.
Q - He either copied something or he made something up. In the latter
case he must have thought about it?
A - The statement is either he copied something or made something up.
If he made something up he must have thought about it. I don’t think
that’s true. I think he made up a lot of stuff without thinking about
it.
Q - It accidentally worked?
A - That’s a very good point. Someone said it accidentally worked.
There are a lot of things in Bitcoin that accidentally work. There’s
pretty strong evidence that some amount of thought went into all of
this weird stuff. There are a lot of accidentally works here. There
are a lot of subtle bugs that turned out not to be serious but by all
rights they should’ve been. I don’t know what evidence to draw from
that. One idea is that Bitcoin was designed by a number of people
bouncing ideas off each other but the code has a pretty consistent
style or lack of style. It is all lost to time now.
