2026-07-27 01:52:38 <xentrac     > lofty: Forth compilers can be useful
2026-07-27 02:18:10 <Shark8      > lofty, If the word is precompiled and static, then it should be doable to simply analyze the word's own contents, incrementing you count as you get to a [new] 'peek' or 'pop'.
2026-07-27 02:21:41 <Shark8      > lofty, (re: Ada compiler) -- I have a toy/incomplete interpreter, written in Ada, that might help: https://github.com/OneWingedShark/Forth/blob/master/src/forth-vm-functions.ads -- the salient point here is that the implementation uses Ada to compile the functions and uses *that* as the word.
2026-07-27 02:25:26 <xentrac     > well, the issue is that if you want to emit good code, you need to know the dataflow
2026-07-27 02:26:12 <xentrac     > this requires knowing the stack effect of each word that is called
2026-07-27 02:26:55 <xentrac     > for most Forth this is trivial
2026-07-27 02:28:29 <xentrac     > but it can be uncomputable, so unless you're willing to outlaw that, in some circumstances you need to fall back to having an operand stack at runtime instead of just at compil time
2026-07-27 02:41:40 <Shark8      > xentrac, How often does that come up though? You could use the former, either falling back to the operand-stack as-needed or else raising an exception. -- This should get you to a point where you can (a) emit usable code, for many cases, and (b) give a good point to think on 'How do I handle things from here'.
2026-07-27 03:02:32 <xentrac     > not often!
2026-07-27 03:04:12 <xentrac     > but it's one of those cases where catering to the needs of simple implementations of a language makes efficient implementations more complex than they need to be
2026-07-27 03:05:13 <xentrac     > I mean when you're compiling C or Smalltalk or Zig or whatever, you don't need to implement and test that rarely used (and thus poorly tested) fallback path
2026-07-27 03:05:46 <xentrac     > Scheme has a bunch of such things
2026-07-27 03:35:26 <Shark8      > xentrac, Which is where an exception-based approach helps: you can have a "Not_Implemented" exception, and raise that as your default operation, overriding/replacing that call to the correct one as you proceed on implementing.
2026-07-27 03:40:19 <Shark8      > Another thing that can help is having a solid intermediate representation. Ada has several forms for 'return a value' -- (a) "Return X;", (b) "Return Result : Some_Type:= Some_Init do" <STATEMENTS> "end return;", expression functions "Function Expression_Function(Object : X) return String is (X'Image(Object));" -- If you design your IR to 'factor out' things, you could make the node for return-a-value a single node for all of the
2026-07-27 03:40:19 <Shark8      > varients, collapsing the things you have to handle into that single point.
2026-07-27 10:52:55 <veltas      > lofty: I personally think an optimizing Forth compiler isn't worth it
2026-07-27 10:54:08 <veltas      > If you need to optimize some word then you should write it in assembly, that's the tradeoff I make with the reduced complexity of not over-optimising my Forth code generation
2026-07-27 10:54:48 <veltas      > In fact I constantly find myself favouring techniques that simplify programming or empower the programmer at expense of cycles on average colon words
2026-07-27 11:33:54 <lofty       > veltas: it's not going to be doing _much_ optimisation, I just want machine code that doesn't make my eyes bleed :p
2026-07-27 11:35:49 <veltas      > That would take a lot of optimisation that isn't in Forth by default
2026-07-27 11:35:57 <veltas      > A lot of optimisation code rather
2026-07-27 15:51:00 <xentrac     > Shark8: not sure that helps with Forth
2026-07-27 15:52:46 <xentrac     > lofty: you are going to need register allocation to get reasonable machine code, which will require building some sort of dataflow graph, which will require the compiler to know the stack effects of at least the common words
2026-07-27 15:53:55 <lofty       > xentrac: sure, I'm aware of enough compiler theory for that, though I think my hackjob of destination-driven code generation is producing something...not totally awful? :p
2026-07-27 15:54:10 <Shark8      > xentrac, Certainly less-so than many (most?) other languages. -- I've been looking at using Forth as the "VM"/target for the backend of a compiler, so as to ease bootstrapping. (The SeedForth minimalistic, tokenized 'Forth', to be precise; then the words are essentially the bytcode for the 'VM'.)
2026-07-27 15:57:03 <xentrac     > lofty: reverse linear scan register allocation like LuaJIT?
2026-07-27 15:57:49 <lofty       > xentrac: https://bernsteinbear.com/assets/img/ddcg.pdf
2026-07-27 15:58:17 <xentrac     > Shark8: if you're using Forth as a compiler target you can outlaw words whose stack effect is nontrivial to compute.  Java and Wasm do this
2026-07-27 15:59:23 <Shark8      > lofty, Oh, thank you for the document.
2026-07-27 15:59:38 <xentrac     > lofty: thanks!  I'm not sure if this is the same thing, so I'll read the paper attentively.  You're not tekknolagi, are you?
2026-07-27 16:00:17 <lofty       > xentrac: no, it's very different to solid state register allocation, and no, I'm not tekknolagi, I'm Ravenslofty
2026-07-27 16:00:41 <xentrac     > solid state?
2026-07-27 16:01:08 <xentrac     > yes, I knew you were Ravenslofty
2026-07-27 16:02:36 <xentrac     > since you're not tekknolagi you may be interested in https://bernsteinbear.com/blog/linear-scan/
2026-07-27 16:02:44 <Shark8      > xentrac, Sure, just don't emit them. But there's another reason I'm looking at SeedForth: it's smaller, simpler, and I'm pretty sure SPARK-provable if I implement it in Ada. (This means that porting the known-correct "VM" to another architecture is, after the bootstrap-compiler-dance, simply implementing the 30 or so words on the new architecture.)
2026-07-27 16:03:21 <xentrac     > Shark8: sounds appealing
2026-07-27 16:06:41 <cleobuli_   > https://ibb.co/9k5rRdbz
2026-07-27 16:06:42 <Shark8      > xentrac, I show the procedure here: https://downloads.regulations.gov/ONCD-2023-0002-0041/attachment_1.pdf
2026-07-27 16:07:57 <Shark8      > xentrac, (Appendix A)
2026-07-27 16:08:04 <lofty       > I will admit that "recurse" makes it much harder to factor things out of a giant visitor-pattern code generator
2026-07-27 16:08:25 <xentrac     > > When the control destination is a pair of labels, the flow of control is to be altered according to the boolean value of the current expression
2026-07-27 16:08:35 <xentrac     > (from the Dybvig paper)
2026-07-27 16:09:07 <xentrac     > this sounds very similar to Henry Baker's COMFY control-flow scheme, which hadn't been published yet
2026-07-27 16:09:14 <xentrac     > cleobuli_: ?
2026-07-27 16:09:38 <cleobuli_   > a remahe of hypercard xentrac
2026-07-27 16:09:45 <cleobuli_   > remake
2026-07-27 16:10:56 <lofty       > admittedly Dybvig handwaving instruction selection away is a little bit of a headache, but
2026-07-27 16:10:59 <cleobuli_   > million ppls are sreaming that hypercard was finished by apple
2026-07-27 16:11:34 <cleobuli_   > next cleobuline remake it
2026-07-27 16:14:05 <cleobuline  > may be it's a one year project xentrac
2026-07-27 16:25:19 <veltas      > I wonder if modern compilers actually use any of the compiler theory I learned in uni
2026-07-27 17:09:38 <xentrac     > cleobuline: aha, the hc thing you linked the other day!
2026-07-27 17:09:58 <xentrac     > veltas: possibly?
2026-07-27 17:10:03 <cleobuline  > yes xentrac
2026-07-27 17:12:09 <veltas      > I'd have to know anything about modern compilers to find out
2026-07-27 17:12:24 <lofty       > e[quivalence]-graphs are a thing these days
2026-07-27 17:14:21 <veltas      > Neither LLVM nor GCC use those?
2026-07-27 17:14:29 <lofty       > cranelift does
2026-07-27 17:23:11 <veltas      > I'd say a stack-based language lends itself to small encodings and not to easy optimisation
2026-07-27 17:23:44 <veltas      > But you can optimise it fully, for the code that's not doing using the stack as a totally dynamic stack
2026-07-27 17:24:17 <veltas      > But you'd probably yes have to convert it to literally any other representation before doing any real optimisations
2026-07-27 17:24:28 <veltas      > I guess it works well for some peep-hole stuff, some constant folding
2026-07-27 17:24:46 <veltas      > But data flow analysis it's going to not be a good choice for, I'm thinking
2026-07-27 17:26:25 <veltas      > Well I have actually muddled over trying to design optimisers for Forth and I think the complexity explodes to the point where I wonder why you're bothering with Forth at all
2026-07-27 17:26:52 <veltas      > Because the big advantage of Forth is how small it can be, in image size maybe, but mostly in the simplicity of the full environment
2026-07-27 17:27:25 <veltas      > Cranelift is in the range of 200K lines of code they say, which apparently is quite small for what it can do, and that's cool
2026-07-27 17:28:10 <veltas      > But Forth is more in the 1-10K lines of code range (depending on how classic your lines are)
2026-07-27 17:29:17 <lofty       > veltas: nobody ever built anything by saying it couldn't be done
2026-07-27 18:05:54 <veltas      > Nobody ever built anything that can't be done
2026-07-27 18:06:58 <veltas      > mecrisp and a bunch of forths that optimise exist already
2026-07-27 18:07:06 <lofty       > does saying this make you feel better about yourself or something?
2026-07-27 18:08:05 <veltas      > No as I didn't write mecrisp
2026-07-27 18:08:10 <veltas      > Makes me feel good for them though
2026-07-27 18:08:30 <lofty       > okay, so, if trashing my hobby project doesn't make you feel better, why are you saying this?
2026-07-27 18:09:03 <veltas      > When did I trash your hobby project?
2026-07-27 18:09:36 <veltas      > Actually I should just say: I didn't trash your hobby project.  Better than asking for something I know doesn't exist.
2026-07-27 18:09:36 <lofty       > <veltas> Well I have actually muddled over trying to design optimisers for Forth and I think the complexity explodes to the point where I wonder why you're bothering with Forth at all
2026-07-27 18:10:15 <lofty       > <veltas> lofty: I personally think an optimizing Forth compiler isn't worth it
2026-07-27 18:10:15 <veltas      > When I said that I meant "I wonder why one would bother" or really I meant myself, since I was the one doing the bothering in that anecdote
2026-07-27 18:10:59 <veltas      > I stand by what I said, and it seems you have taken it personally, however that was my professional opinion so it shouldn't be taken personally
2026-07-27 18:11:36 <veltas      > If you disagree and prove me wrong then I will admit I'm wrong and would actually be happy
2026-07-27 18:11:54 <veltas      > It's not an opinion I enjoy, it's just my opinion
2026-07-27 18:12:12 <lofty       > if you do not enjoy your opinion, change your opinion
2026-07-27 18:12:48 <veltas      > Well by opinion here I mean my best understanding of the facts, and I can't really change that without new information
2026-07-27 18:18:44 <veltas      > lofty: You might find this interesting https://www.youtube.com/watch?v=tPjSKetEJn0
2026-07-27 18:19:05 <veltas      > Because apart from being about a specific optimisation, it also compares a number of forths that optimise, so might be useful research
2026-07-27 18:27:57 <Shark8      > lofty, (re: if you do not enjoy your opinion, change your opinion) -- Oh, I wish it were that easy! Sometimes the opinion is based in pessimism and track-records. Take, for instance, the rise of C, then C++, then Rust -- They are not good languages WRT readability and IMO maintainability; however they are popular in-industry because [my opinion] so that the management caste can have more replaceable-cogs of programmers, rather than
2026-07-27 18:27:58 <Shark8      > having to take the time to select the best tools for the project.
2026-07-27 18:29:49 <Shark8      > (eg the F-35; they rejected Ada as the implementation language despite having multiple airframes using it, because they didn't want to train programmers or pay those that already knew Ada... they then spent more money and time than it would have cost training them in developing the JSF Style Guide.)
2026-07-27 18:43:22 <lofty       > Shark8: it is, in fact, that easy. you just have to not succumb to despair.
2026-07-27 18:45:31 <Shark8      > lofty, ?? That's not changing my opinion though: the evidence is that management (as a whole) is geared to think in terms not of getting the work done well, but in terms of "reducing costs" and making employees replaceable.
2026-07-27 18:46:10 <lofty       > "Oh, I wish it were that easy!"
2026-07-27 18:47:04 <lofty       > I also have learned my lesson about commenting on Rust bashing in this channel, so I won't do that
2026-07-27 18:51:27 <X-Scale     > For some definition of "getting the work done well".
2026-07-27 20:02:31 <Shark8      > lofty, I have *very* mixed feelings on Rust. On the one hand, I am glad that more programmers are concerned with safety/correctness, on the other hand... it's got some terrible syntax. On the third hand, I'm not a fan of the rabid nature of some of the proponents, for example getting "borrow checker!" thrown in my face when I talk about alternatives like Ada (and SPARK), which are (IMO) much more friendly to onboarding from more
2026-07-27 20:02:31 <Shark8      > mainstream languages.
2026-07-27 21:17:42 <veltas      > Proponents aren't an argument against languages though
2026-07-27 21:18:08 <veltas      > The hype's annoying but the language is separate from its hype
2026-07-27 22:19:26 <Shark8      > veltas, Agreed. Like I said before: it's got some nice features, but horrible syntax/usability (IMO). / I would have liked to have seen it more in the ML or Haskell camp for syntax, instead of the obviously C++ & APL inspired strain of thought.
2026-07-27 22:23:40 <veltas      > Well Haskell already exists