2026-03-02 08:33:17 <tulushev    > Do people use THROW/CATCH? Looks like a complex bolted on (no primitives to redefine from scratch) feature, no in the spirit of Chuck. Just returning a flag/value from a word seems fine and less complexity even if you need to propagate.
2026-03-02 10:33:44 <veltas      > tulushev: People often use R> DROP EXIT to simulate it, with different amounts of R> DROP  (or RDROP) in the middle to do further long jumps
2026-03-02 10:34:03 <veltas      > It's more like THROW/CATCH provides a standard way of doing something similar
2026-03-02 10:34:21 <veltas      > The effect it has on parsing state and input state is a little complicated and under-specified I'd say
2026-03-02 10:34:40 <veltas      > But the implementation of it is actually quite trivial and the example implementation makes sense
2026-03-02 10:35:16 <veltas      > The main issue I have with it is it doesn't really fit with the rest of Forth's syntax, given it takes an xt, which is idiosyncratic for a Forth control word
2026-03-02 10:36:16 <veltas      > Returning a flag from a word to indicate an error/success is also quite idiosyncratic for Forth
2026-03-02 10:36:30 <veltas      > But there are some words that work this way
2026-03-02 10:37:03 <veltas      > But usually a 'rare error' is handled with an ABORT, which without exceptions is as simple as : ABORT S0 SP! QUIT ;
2026-03-02 10:37:11 <veltas      > Or ABORT"
2026-03-02 10:37:52 <veltas      > So something like an I/O error, in my opinion, shouldn't take up loads of stack / control logic.
2026-03-02 10:43:02 <tpbsd       > I often use QUIT if the error is serious enough
2026-03-02 10:45:30 <veltas      > Does mecrisp QUIT clear the stack?
2026-03-02 10:45:50 <veltas      > ANS ABORT is just QUIT but also clears the parameter stack
2026-03-02 10:52:43 <tpbsd       > no QUIT doesnt clear the stack but it exits any loop
2026-03-02 10:53:11 <tpbsd       > which drops my device out of it's program and I know that something bad happened
2026-03-02 10:53:54 <tpbsd       > I normally run a BIG LOOP for my devices, so QUIT kills that
2026-03-02 11:10:08 <tpbsd       > veltas, Mecrisp-Stellaris doesnt have ABORT
2026-03-02 11:11:03 <KipIngram   > I've always thought of QUIT as clearing the return stack but not the data stack.
2026-03-02 11:12:09 <KipIngram   > QUIT quickly goes right into the interpreter loop - I usually write it so that that return stack clear is inside the loop.
2026-03-02 11:14:11 <tpbsd       > KipIngram, that seems to be just what it does in Mecrisp-Stellaris tho the notes have this  "quit  ( many - - ) (R: many - - ) Resets Stacks" which seems to include the data stack
2026-03-02 11:15:13 <tpbsd       > but it doesnt in my tests
2026-03-02 11:15:29 <KipIngram   > That loses the ability to inspect the state you quit from, but I guess it's just a design option.  If ABORT does it instead that works too.
2026-03-02 11:15:53 <tpbsd       > I could make an ABORT if I wanted one
2026-03-02 11:15:57 <KipIngram   > Really so long as there is a way.  Clearing the data stack would of course have to be outside the loop - just an initialization thing.
2026-03-02 11:16:24 <tpbsd       > EXIT takes care of testing for bad errors well enough for me tho
2026-03-02 11:16:34 <KipIngram   > And actually I think FIG Forth had the return stack clear outside the loop too.
2026-03-02 11:17:01 <KipIngram   > The loop just began with QUERY INTERPRET ...
2026-03-02 11:17:33 <KipIngram   > Also I think QUIT guarantees interpret mode (STATE=0).
2026-03-02 11:23:09 <tulushev    > hmm, thanks for the context
2026-03-02 11:28:01 <KipIngram   > tpbsd: the thing is, the code to clear the data stack, clear the return stack, and enter interpret state all has to be there anyway - it runs as the system initializes.  So it's really  just a matter of where you decide to put entry point / labels in it and what you choose to call them.
2026-03-02 11:28:49 <tpbsd       > KipIngram, good point
2026-03-02 11:31:20 <KipIngram   > On a notebook where I have plenty of RAM to do it without concern, my choice is to have any overt error (anything that actually gets reported as an error) restore the entire system (the whole image) to the state it had at the beginning of the line that threw the error.
2026-03-02 11:31:30 <KipIngram   > So I don't clear the stack - I put it back how it was at the outset.
2026-03-02 11:31:50 <KipIngram   > That way I'm set up to  just up-arrow to get that faulty line back and can fix it and run it again very easily.
2026-03-02 11:32:24 <KipIngram   > It completely undoes any results of the part of the line that executed before the error.
2026-03-02 11:33:00 <KipIngram   > Restores the stacks, the dictionary, etc.  Unfortunately it doesn't restore the mass storage buffers - they're outside of the primary image.
2026-03-02 11:33:44 <KipIngram   > Basically I snapshot the whole system before I call QUERY, and error recovery copies that back.
2026-03-02 11:34:31 <KipIngram   > I tried to do a less aggressive error recovery, but kept discovering there were corner cases I hadn't covered.  So finally I gave in and sledge hammered it.
2026-03-02 11:35:39 <KipIngram   > I also trap addressing errors and divide by zero errors and those get handled the same way.
2026-03-02 11:35:48 <KipIngram   > Having addressing errors NOT segfault is a godsend.
2026-03-02 11:36:01 <KipIngram   > That's hard to do in Linux, btw.
2026-03-02 11:36:31 <KipIngram   > The whole business of traps and signals is rather poorly documented and is somewhat platform dependent.
2026-03-02 11:39:48 <KipIngram   > You have to install a handler for the pertinent exceptions (that part is well documented), but that handler has to modify the stack frame so that when it returns it takes control back to the right point in your error handling code, which then flows control on into the interpreter.
2026-03-02 11:40:38 <KipIngram   > My snapshot of the prior state gets restored, which resets the stacks appropriately.
2026-03-02 11:41:18 <KipIngram   > My stack pointers are NOT the cpu stack, so it has to get properly reset somewhere in there too.
2026-03-02 11:42:02 <KipIngram   > I just leave rsp untouched; it only gets used when I make syscalls or do this exception handling.
2026-03-02 11:42:51 <KipIngram   > There are no calls or returns in my good path code, so it never gets changed any other time.
2026-03-02 11:44:43 <KipIngram   > Anyway, I noted above I have to modify a stack frame - that's the part that seems platform dependent.
2026-03-02 11:45:48 <KipIngram   > I think the normal use case for exception handling is that you will either fail completely or else you will correct the problem and return to whatever was executing when the fault occurred.  But that's not what I need to do - I want to return somewhere ELSE.
2026-03-02 11:46:39 <KipIngram   > So some return address down there buried in the frame has to get modified.