10:36:25
##forth
<dave0>
oh hey deadmarshal
10:36:34
##forth
<dave0>
you're on forth AND oberon
10:36:40
##forth
<dave0>
me too!
10:39:34
##forth
<deadmarshal>
dave0: hey ;)
10:41:28
##forth
<dave0>
hi :-)
11:45:12
##forth
<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.
11:45:22
##forth
<KipIngram>
But that's an individual taste, of course.
11:46:21
##forth
<KipIngram>
I've done it just for simplifying stack stuff, but I feel a little "beaten" when I do.
11:49:28
##forth
<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.
11:51:32
##forth
<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 }.
11:53:16
##forth
<KipIngram>
I try to use it only when I just can't find a clean way to avoid it.
11:55:01
##forth
<KipIngram>
I realize I'm doing something that's "frowned upon," so I try not to do it much.
12:05:21
##forth
<tpnix>
KipIngram, thats awesome
12:06:25
##forth
<tpnix>
KipIngram, I'm the same as you re " I feel a little "beaten"" when I have to use vars
12:07:33
##forth
<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
12:51:12
##forth
<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
12:51:45
##forth
<veltas>
deadmarshal: Didn't read all of it as it's quite long but I agree with the general gist
12:53:34
##forth
<veltas>
However have you seen the Tiny C Compiler? I think there's a few reasonable sized implementations of C out there
12:54:15
##forth
<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
12:57:01
##forth
<veltas>
But I would guess a minimalist Forth implementation is smaller than a minimalist C implementation
12:57:34
##forth
<veltas>
The only sophisticated open source Forths I'm aware of are gforth and mecrisp
13:22:58
##forth
<tpnix>
veltas have you seen zeptoforth ?
13:24:01
##forth
<tpnix>
veltas, or Retro ?
13:59:51
##forth
<veltas>
Retro's not an optimising Forth I don't think
14:00:04
##forth
<veltas>
And it runs in a VM anyway
14:00:15
##forth
<veltas>
I mean Forths that do sophisticated optimisation like mecrisp
14:01:04
##forth
<veltas>
I've not really seen zeptoforth although I might have encountered it before
14:04:49
##forth
<veltas>
So now I know of 3: gforth, zeptoforth and mecrisp
14:13:43
##forth
<veltas>
Assuming zeptoforth does that
15:23:38
##forth
<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
17:18:32
##forth
<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
21:28:35
##forth
<KipIngram>
I agree 100% - I don't think anything is as easy as Forth to bootstrap. If something is, I haven't seen it.
22:39:53
##forth
<TactfulCitrus>
Is anyone doing advent of code in Forth this year?