Some other stack languages (not all of these concatenative languages use a single stack but most of them do):<p><a href="https://concatenative.org/wiki/view/Concatenative%20language" rel="nofollow">https://concatenative.org/wiki/view/Concatenative%20language</a>
A similar language that’s been worked on for a while now is [Min](<a href="https://min-lang.org/" rel="nofollow">https://min-lang.org/</a>). Interestingly it is written in Nim.<p>I was interested in the C interface part but it never got there. :(
I've never really understood stack based languages. Getting rid of variables only seems make things harder, and you always inevitably need some kind of control flow that isn't stack based (for instance the pair "[" and "]"). In this case, I suppose the advantage is that the stack is shared with C so it's easier to interact over FFI.<p>From what I've seen of other forths, I much prefer how this one does things. Using quoting as a sort of lambda is much nicer and more consistent than the weird compilation semantics you see in stuff like GForth.
Are there any practical and somewhat popular stack-based/concatenative languages? 'Popular' here doesn't need to mean that popular, something on a similar usage level to some Lisp dialects, or functional languages like Haskell.
I think it’s cute/ironic that the first word the document introduces you to is “.” Which in normal English is something we used to separate runs of words.
I have no comments on the project itself, which I’m sure is very nice.
If you’re taking suggestions, the mobile web view unfortunately captures 75% of the viewport on the side menu, it’d be nice if it were collapsible or flexible.<p>Keep on keeping on!
Is there a language which is not stack-based? I imagine "concatenative" would be mildly more precise of a description.<p>Coroutines (which often carry their own stacks) can sort-of dodge stacks—effectively utilizing a sort of bespoke linear typing to avoid this—but I don't know of a language which doesn't have c-like, stack-based procedures or subroutines, which places arguments on the stack and registers and operates mostly with respect to that stack and foreign API calls.<p>A stack is certainly the most intuitive data-structure with which to implement a lambda calculus.<p>Really, what Forth and descendent languages seem to emphasize is a sort of a data-oriented execution rather than a symbol-oriented execution—C very much encourages you to name types, function signatures, etc, and the result if you don't is extremely difficult to parse and interpret manually, even if you can implement forth as a subset of C.<p>Forth emphasizes reasoning about the stack directly as data, seemingly forgoing any assistance outside of syntax. Arguably it forgoes the utility of syntax, too.