gale VS 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 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