💾 Archived View for bbs.geminispace.org › s › FORTH › 5285 captured on 2023-09-28 at 17:36:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
If there is one thing I hate about classic Forth is the duality of interpret/compile modes. It makes for a lot of complications, like special versions of conditionals [IF] [THEN], etc. that work in the interpreter but not the compiler. And the whole idea of 'state-smart' words that do different things in compile mode. Yech.
So I thought I was smart when I eliminated the problem alltogether by leaving the system in compile mode always. Now, originally, I compiled a line at a time, and then I would execute it. It worked wonderfully at the top level prompt, and defining words would just adjust the execution position when needed, so defined words would not execute.
But then, in my smaller forths, like nforth, I stopped bothering with lines, and started compiling and executing each token as I see it. That works for simple things, but for more complicated tasks (like ``` " hello" . ```) it fails, because first the string is compiled and executed, and then erased, then dot gets compiled in the same place, and we crash.
To avoid that, I have to compile a bunch of things before running, by grouping things with [ ... ] braces. But now we are kind of reintroducing the compile mode with weirder semantics. For instance Forth allows us to switch between compiling and interpreting, which is good for tricks like calculating constants and doing some meta stuff while compiling. I can't do it with the braces, because as soon as I close the brace the system will try to run.
So I would have to introduce some kind of run-now syntax, like some other kind of braces which would execute code now. That seems clumsy.
ColorForth deals with it by using a special color to execute words immediately, another to compile... But I think it's kind of unwise, because most of the time you just want to compile, and when you want to interpret, you want to do something different, you want to operate on entire expressions, not words anyway.
I'm also annoyed with the paren thing. I think that regular parentheses should be used to ( group things ). { lambda expressions } can be inside curly braces, because that just screams 'code!'. Then I can use square braces to indicate [ code to run right now for side-effects and abandon].
Otherwise, the system should just compile code. The only problem is that it's confusing on the command line, requiring one to surround all transient commands with [ ]. But right now you pretty much have to do it anyway, for anything non-trivial. So maybe it's better.
I think I will give it a try in a test branch.
2023-09-13 · 2 weeks ago · 👍 BBSman