Hacker News Reader

Comment by rickcarlino | Hacker News Reader

Hacker news may be giving this site the hug of death. https://web.archive.org/web/20230711163359/https://retrofort...

Retro is an interesting Forth platform because it has numerous features not present in more traditional Forth systems, such as the ability to create closures and first class literals while still maintaining compactness that would be expected of a Forth system.

It was originally meant for desktop scripting but has been ported to tiny devices like microcontrollers.

It is worth a look if you are even mildly curious about Forth

View on HN

I would love a Forth with a type system. I don't know if that is heretical, but I'd love a higher-order type system for when you are several meta-words deep. Disclaimer: I've only used Factor on Project Euler problems.

While not quite a Forth, Kitten is a stack language:

https://kittenlang.org/

Might not be quite what you're thinking of, but for typed Forth, there's StrongForth, which is statically typed. I wrote a Forth-based scripting system for Dreamcast homebrew, and used StrongForth's type system in it. I would run and edit the scripts live on the console, and the static typing was a big help to prevent errors that could crash the system (since the game ran under a single process, and did not use the MMU).

https://www.stephan-becher.de/strongforth/intro.htm

Personally I prefer Dr. Becher's follow-on project, StrongForth.f, which is just a library to load into a standard system like gforth (which is probably in your OS's package repo).

http://www.arestlessmind.org/2013/08/17/

That's a nice thing you built! Is it still in use?

I didn't make StrongForth, I just based my own Forth on it. I've really only used it in my game engine.

> I would love a Forth with a type system. I don't know if that is heretical [...].

Jack Woehr (of the ANS Forth committee) and Mitch Bradley (of Open Firmware fame) think it’s old hat[1], so guess not. (They also think it probably 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 identidally sized 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 even just for stack checking), 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 between Forths proper and “postfix Lisps” like PostScript, Joy, and Factor, as such manipulation doesn’t seem feasible without some sort of automatic memory management.)

[1] https://github.com/ForthHub/discussion/issues/79#issuecommen...

[2] https://github.com/ActorForth/ActorForth

There are a few stack-based languages that you might enjoy. Pop-11 is a typed open stack language roughly at the level of Common Lisp. RPL (originally "reverse Polish Lisp") is an interpretive stack based language on some HP calculators.

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)

When I'm working on something like that I tend to literally have a directory called sketches/ in the root of the repo, a few of which will currently run, a few more of which -did- run at some point, and then the rest are more thinking out loud than anything else.

Calling it that straight out the gate reminds me not to worry too much about it and just get the thing down into a file for future reference, if I derive a 'real' version of anything in there that I intend to both run now and to stay running I'll put that somewhere else (and leave the sketch in place for historical curiosity purposes).

I've only used Forth briefly, but one of the things I loved about it is that it almost has the opposite of a type system - everything is just 'memory' - but you just build words around that and barely even notice.

I've seen people recommend C as a way to "get closer to the hardware", but I think we all know that that's not really been a thing for longer than most of us have been alive. Forth, though? Maybe!

Forth is the only language I have dabbled with that in some ways feels lower level than assembler itself.

smaddox is working on one called Dawn:

https://news.ycombinator.com/from?site=dawn-lang.org

There hasn't been an update in over a year but I hope it's still going because it looked really interesting.

Factor is a typed forth descendent

https://factorcode.org/

It was such a HN darling back when it HN first launched.

MStoical[1] is a fork of a fork of Stoic[2], which has toggle-able runtime type checking. It supports the following parameter types for each parameter (see the docs)

  short long
  ----- ----
  *     bah ( don't care )
  f     float
  s     string
  r     reference
  p     pointer
  io    stream  ( file / socket )
  a     array
  h     hash 
  c     clause

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

[2] https://en.wikipedia.org/wiki/STOIC

Reply on news.ycombinator.com