A wonderful thing about Forth-style languages is that they are amenable to many implementation strategies, and if you are looking for a quick-and-dirty DSL you

A wonderful thing about Forth-style languages is that they are amenable to many implementation strategies, and if you are looking for a quick-and-dirty DSL you can usually do it as a Forth. Something I did recently is a source-to-source compiler as a series of function calls, e.g.: 1 2 + may translate to stack.push(1); stack.push(2); add(); in an Algol-type language. You don't get niceties like a "real" namespace or interactivity with this approach, but if the function calls are inlined, the only performance overhead comes from usage of the data stack - making it a good candidate for "glue code" that doesn't need to be dynamic. It's basically "Forth-like macro-assembler" at this level. For things like runtime mutability, interrupt-and-continue behavior, and interactivity, another strategy is to build an interpreter loop where each word is a list or array of data containing two types - values and function calls. Lots of features become possible - even easy - once you do that. Since I started experimenting with stack languages I've been trending towards this approach: build a Forth-type API on top of whatever language is best for the task. Then build the app in the Forth. On the one hand you can say "ah, but that's not necessary," but on the other, it focuses your energies around setting up the plumbing well, so that the final solution is small and easy to extend. And that's always a good outcome.