2025-12-09 10:28:33 <deadmarshal > https://im-just-lee.ing/forth-why-cb234c03.txt
2025-12-09 10:36:25 <dave0       > oh hey deadmarshal
2025-12-09 10:36:34 <dave0       > you're on forth AND oberon
2025-12-09 10:36:40 <dave0       > me too!
2025-12-09 10:39:34 <deadmarshal > dave0: hey ;)
2025-12-09 10:41:28 <dave0       > hi :-)
2025-12-09 11:45:12 <KipIngram   > I try to use vars only when persistent state is involved.  It's a long-term name in the dictionary; I try to use them only when it's long-term information, not just to simplify stack handling.
2025-12-09 11:45:22 <KipIngram   > But that's an individual taste, of course.
2025-12-09 11:46:21 <KipIngram   > I've done it just for simplifying stack stuff, but I feel a little "beaten" when I do.
2025-12-09 11:49:28 <KipIngram   > I invented a very simple "stack frame" system to use instead, which I guess is essentially a local variable system, but "nameless."  Items are accessed by location in the frame instead of by name.
2025-12-09 11:51:32 <KipIngram   > My first go at it used the stack pointer as the anchor point, but that proved really hard to use, since items "move location" relative to SP as your stack evolves.  So I added a "frame register" to use instead, which I manage with words { and }.
2025-12-09 11:53:16 <KipIngram   > I try to use it only when I just can't find a clean way to avoid it.
2025-12-09 11:55:01 <KipIngram   > I realize I'm doing something that's "frowned upon," so I try not to do it much.
2025-12-09 12:05:21 <tpnix       > KipIngram, thats awesome
2025-12-09 12:06:25 <tpnix       > KipIngram, I'm the same as you re " I feel a little "beaten"" when I have to use vars
2025-12-09 12:07:33 <tpnix       > KipIngram, in general tho, I use vars to test out the concept, then get rid of them if I use the Forth Word in something
2025-12-09 12:51:12 <veltas      > Yeah I generally use vars where it's easy or necessary to make sense, and then slowly get rid of them as and where I can
2025-12-09 12:51:45 <veltas      > deadmarshal: Didn't read all of it as it's quite long but I agree with the general gist
2025-12-09 12:53:34 <veltas      > However have you seen the Tiny C Compiler?  I think there's a few reasonable sized implementations of C out there
2025-12-09 12:54:15 <veltas      > And I'd argue they're a bit easier to maintain than the sophisticated optimising Forth compilers, which there are about the same number of
2025-12-09 12:57:01 <veltas      > But I would guess a minimalist Forth implementation is smaller than a minimalist C implementation
2025-12-09 12:57:34 <veltas      > The only sophisticated open source Forths I'm aware of are gforth and mecrisp
2025-12-09 13:22:58 <tpnix       > veltas have you seen zeptoforth ?
2025-12-09 13:24:01 <tpnix       > veltas, or Retro ?
2025-12-09 13:59:51 <veltas      > Retro's not an optimising Forth I don't think
2025-12-09 14:00:04 <veltas      > And it runs in a VM anyway
2025-12-09 14:00:15 <veltas      > I mean Forths that do sophisticated optimisation like mecrisp
2025-12-09 14:01:04 <veltas      > I've not really seen zeptoforth although I might have encountered it before
2025-12-09 14:04:49 <veltas      > So now I know of 3: gforth, zeptoforth and mecrisp
2025-12-09 14:13:43 <veltas      > Assuming zeptoforth does that
2025-12-09 15:23:38 <crc         > my forths aren't really optimizing. Retro has a limited support for inlining words that match to a primitive instruction bundle for the vm, but that's pretty much the extent
2025-12-09 17:18:32 <deadmarshal > veltas: yes i saw tcc before. The thing is in my opinion that Forth is simpler to bootstrap. C needs more work to bootstrap and also needs runtime etc... and C's grammar is ambiguous and harder to parse. parsing Forth is as simple as split on whitespace
2025-12-09 21:28:35 <KipIngram   > I agree 100% - I don't think anything is as easy as Forth to bootstrap.  If something is, I haven't seen it.
2025-12-09 22:39:53 <TactfulCitrus> Is anyone doing advent of code in Forth this year?