Could you use the Crafting Interpreters book as a guide to build a Forth interpreter?
Implementing a Forth
31–40 of 70 posts
Re: Implementing a Forth
#32I went down the "make your own Forth" rabbit hole about 45 years ago. In January 1979, Byte Magazine's Language Forum contained the article, "IPS, An Unorthodox High Level Language."[1] The article described IPS, a language based on Forth, but with the word names translated to German. Thus, Forth's SWAP became VERT, short for vertauschen. The intriguing article concluded with a reference to Charles Moore's 1974 paper…
What kind of programs would one naturally reach for Forth as the optimal solution? It has always struck me as a very low level language but I rarely hear this caveat from its advocates.
It's used in a number of EFI implementations. Its good when you have no environment at all, hence bootloaders. Factor is a more general purpose forth-like language.
Re: Implementing a Forth
#33I went down the "make your own Forth" rabbit hole about 45 years ago. In January 1979, Byte Magazine's Language Forum contained the article, "IPS, An Unorthodox High Level Language."[1] The article described IPS, a language based on Forth, but with the word names translated to German. Thus, Forth's SWAP became VERT, short for vertauschen. The intriguing article concluded with a reference to Charles Moore's 1974 paper…
What kind of programs would one naturally reach for Forth as the optimal solution? It has always struck me as a very low level language but I rarely hear this caveat from its advocates.
I would put it into these three categories:
1. Assembly coding within a REPL. Forth supports "load-and-store" without the additional bookkeeping steps of assembly. Once the program works, it can be incrementally rewritten into the assembly if needed, or used to bootstrap something else. Historically this is probably the single biggest usage, because the language works as a blunt instrument for that within the standard wordsets. Lots of programs on the early micros shipped with code that was developed with Forth, but with the Forth interpreter discarded at the last step; and where there is novel hardware and novel applications, Forth tends to come up as the bootstrap.
2. Minimal-dependencies coding. For the same reason that it's a good bootstrapping tool, Forth ends up being portable by assuming nothing. While different Forth systems are all subtly incompatible, the runtime model is small enough to wrangle into doing what you want. Stack machine VMs basically are "Forth with more sandbox and less human-readability".
3. "Big ideas" coding. The "human-readable stack machine" aspect means it's a useful substrate for language design - being programmable, you can shift the imperative interpreter model in the direction of new syntax and new general-purpose data structures, while still retaining a way to drop all the way down to assembly - the biggest downside is that this doesn't let you easily introduce existing library code, so bootstrapping from within Forth would take a long time and you would most likely get stuck on trivial string processing. But Forth as the second of a two-step process where you "compile to Forth" using something more batteries-included is actually pretty reasonable as an alternative to generating a binary or designing an original VM.
Re: Implementing a Forth
#34Could you use the Crafting Interpreters book as a guide to build a Forth interpreter? https://craftinginterpreters.com/
Sure, but all you really need is the Forth spec and some basic programming skills in any language, even Bash[0] will work. Get a working Forth up and running with the core words and then start improving it and expanding it, develop that basic core into a higher level interpreted language. You will learn far more than you would following a guide.
[0] One of my odder Forths was fs4th, FileSystemForth. It was implemented with Bash aliases and variables, the stacks were just paths, there was a directory called stack and in it there were numbered directories to represent the stack and what you pushed and popped onto the stack were files. It was a weird way to work with files but I could see it having niche uses. I also made a more normal Forth in Bash as a quick project to refresh my Bash skills.
Re: Implementing a Forth
#35I am under impression that more people implement Forth than use it for programming...
It is educational thing to do. Like Lisp as well.
With Lisp you have beasts like Guile and Guix with Scheme and with Common Lisp, Maxima, Nyxt and even weird stuff like K3D or whatever was called where you could build 3D scenes while programming. A la PovRay, but with Common Lisp and in-place editing instead of batch rendering.
Re: Implementing a Forth
#36Could you use the Crafting Interpreters book as a guide to build a Forth interpreter? https://craftinginterpreters.com/
Sure, but all you really need is the Forth spec and some basic programming skills in any language, even Bash[0] will work. Get a working Forth up and running with the core words and then start improving it and expanding it, develop that basic core into a higher level interpreted language. You will learn far more than you would following a guide. [0] One of my odder Forths was fs4th, FileSystemForth. It was implemente…
With AWK an RPN calculator it's dumb easy; and from that, a Forth it's just a matter of time.
Re: Implementing a Forth
#37Earlier quoted context omitted.
Why is it not useful for large programs (if you keep your words small)? What about Factor?
Large programs mean lots of word definitions and essentially writing a DSL, most are not going to document that DSL well enough to make the code readable to anyone else and how many people want to learn a weird adhoc language myopically designed for building one program? I love Forth but it mostly died for good reason. Once you learn its workflow and develop your dictionary it is incredibly quick and easy to use but…
So if it is documented well, then it would be suitable for large-enough programs? Or do you have any tips?
Re: Implementing a Forth
#38I went down the "make your own Forth" rabbit hole about 45 years ago. In January 1979, Byte Magazine's Language Forum contained the article, "IPS, An Unorthodox High Level Language."[1] The article described IPS, a language based on Forth, but with the word names translated to German. Thus, Forth's SWAP became VERT, short for vertauschen. The intriguing article concluded with a reference to Charles Moore's 1974 paper…
What kind of programs would one naturally reach for Forth as the optimal solution? It has always struck me as a very low level language but I rarely hear this caveat from its advocates.
It's useful for programming with functions to return many elements at once.
I program in forth for a living, and that has been one of my favourite advantage, multiple returns without unecessary re-bindings.
Re: Implementing a Forth
#39Earlier quoted context omitted.
Large programs mean lots of word definitions and essentially writing a DSL, most are not going to document that DSL well enough to make the code readable to anyone else and how many people want to learn a weird adhoc language myopically designed for building one program? I love Forth but it mostly died for good reason. Once you learn its workflow and develop your dictionary it is incredibly quick and easy to use but…
So if it is documented well, then it would be suitable for large-enough programs? Or do you have any tips?
I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massive changes to the DSL you designed which also means changes to the program you are using it to write.
DSL is probably not quite the right word, it could be but generally I think it is still going to be fairly Forth like, but you need to think of it that way. You layout what your program does and then reduce it to a few dozen words which work as a description language for the program, then maybe a 100 more words which those words require along with any glue and together all constitute a reasonably sane language. Then you start from the bottom up and implement all those words. The big trick is having the foresight required to pick the function of each of those hundred odd words well enough that no one will ever have to dig into the the 1000 odd words below that it took to implement them. It really forces you to think about how your program may evolve and the bugs which may crop up, you can't change one of those low level words without affecting all that are built on it and if you do the easy work around things start to get messy.
Not sure how well I explained that, I am no Forth expert but I am getting better.
Re: Implementing a Forth
#40Earlier quoted context omitted.
What kind of programs would one naturally reach for Forth as the optimal solution? It has always struck me as a very low level language but I rarely hear this caveat from its advocates.
It's useful for programming with functions to return many elements at once. I program in forth for a living, and that has been one of my favourite advantage, multiple returns without unecessary re-bindings.
I thought you fixed a sailboat for a living :)