Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
ActorForth
A strongly typed Forth-like language ultimately intended to target cryptoledgers and support an Actor concurrency model. Initially implemented in Python, now switched to modern C++.
-
While not quite a Forth, Kitten is a stack language:
https://kittenlang.org/
> I would love a Forth with a type system. I don't know if that is heretical [...].
Mitch Bradley (of Open Firmware fame) thinks it’s old hat[1], so guess not. (He also thinks it won’t work though.) In general, people have tried a lot of times; there’s a number of postfix Lisps with type systems—Kitten mentioned elsethread, ActorForth[2], etc.; a low-level Forth, as in untyped cells on stack and no automatic memory management, I don’t think has been done to completeness (IIRC either Forth, Inc. or MPE have a standing offer for any that’s able to process their legacy code), but then C wouldn’t be complete by that standard either (and Rust far too limiting).
Honestly I’m not sure how well it would work—in C, you get a great deal of utility out of compound types, and classic cell-oriented Forth kind of sucks at even mildly complex datastructures—they are certainly possible, but being unable to manipulate them as values on the stack makes things quite unnatural. (And that’s where I draw the line of “postfix Lisps” like PostScript rather than Forths, as such manipulation doesn’t seem feasible without some sort of automatic memory management.)
[1] https://github.com/ForthHub/discussion/issues/79
[2] https://github.com/ActorForth/ActorForth
> I would love a Forth with a type system. I don't know if that is heretical [...].
Mitch Bradley (of Open Firmware fame) thinks it’s old hat[1], so guess not. (He also thinks it won’t work though.) In general, people have tried a lot of times; there’s a number of postfix Lisps with type systems—Kitten mentioned elsethread, ActorForth[2], etc.; a low-level Forth, as in untyped cells on stack and no automatic memory management, I don’t think has been done to completeness (IIRC either Forth, Inc. or MPE have a standing offer for any that’s able to process their legacy code), but then C wouldn’t be complete by that standard either (and Rust far too limiting).
Honestly I’m not sure how well it would work—in C, you get a great deal of utility out of compound types, and classic cell-oriented Forth kind of sucks at even mildly complex datastructures—they are certainly possible, but being unable to manipulate them as values on the stack makes things quite unnatural. (And that’s where I draw the line of “postfix Lisps” like PostScript rather than Forths, as such manipulation doesn’t seem feasible without some sort of automatic memory management.)
[1] https://github.com/ForthHub/discussion/issues/79
[2] https://github.com/ActorForth/ActorForth
I'm slowly working on one. The repo is a mess and the examples don't actually run (they're sketches of where I'm trying to go; the unit tests in the Zig source are a better idea of where I'm actually at so far), but I'm attempting to slap a "minimum viable "does this shape align with this other shape" type of type system" onto a loosely-FORTH-inspired stack machine with some modern amenities with Gale. https://sr.ht/~klardotsh/gale/ (or for the GitHub fans, https://github.com/klardotsh/gale)
I'm not a C programmer, and it took a fair bit of help from folks here on HN to get it compiling (it was forked from a 20 year old C source), for which I'm grateful.
[1] https://github.com/mikewarot/mstoical
