2023-02-04 11:00:55 <joe9        > anyone experiemented with exception stack in forth?
2023-02-04 11:01:11 <joe9        > or, something like the (with-open-file) construct of lisp..
2023-02-04 11:01:22 <joe9        > to release resources if there is an exception
2023-02-04 11:02:35 <veltas      > joe9: Yes but the standard syntax is lackluster
2023-02-04 11:03:30 <veltas      > Exceptions are pretty damn useful for many things, and R> DROP EXIT is more useful when it can be applied
2023-02-04 11:03:55 <veltas      > I use exceptions for parsing and freeing certain kinds of resources
2023-02-04 11:04:03 <veltas      > It's great for recursive descent parsing
2023-02-04 11:08:38 <joe9        > veltas: do you have a separate exception or resources stack?
2023-02-04 11:08:57 <joe9        > veltas: which forth is this in? So, I can read up on it.
2023-02-04 11:11:01 <thrig       > with-open-file is probably more about unwind-protect
2023-02-04 11:17:25 <veltas      > joe9: Exceptions can be handled using dictionary and return stack
2023-02-04 11:17:29 <veltas      > I wouldn't do it any other way
2023-02-04 11:19:16 <veltas      > Actually I can't even remember what dictionary is for but CATCH definitely just use return stack for that
2023-02-04 11:20:59 <veltas      > Oh yes, the dictionary is needed because THROW needs a variable or something to know how far to pull back the return stack
2023-02-04 11:21:21 <veltas      > And this would be a user variable if you have tasks
2023-02-04 11:25:55 <veltas      > And if this variable, let's call it CATCH-POINTER, is assigned when CATCH is called you need to save and restore that as well. So the context you store on return stack will contain the value to restore CATCH-POINTER with.
2023-02-04 11:28:34 <veltas      > And what else needs restoring? SP, RP, IP. So four things need to be saved: SP, RP, IP, CATCH-POINTER. I think that's it.
2023-02-04 11:29:19 <veltas      > CATCH-POINTER contains the value to pass to RP! (so this can't be trivially implemented with only standard words, but something like RP! is available in 99% of forths)
2023-02-04 11:29:47 <veltas      > I guess RP doesn't need to go on return stack as well, so just SP, IP, CATCH-POINTER.
2023-02-04 11:29:59 <veltas      > 3 cells isn't a massive overhead
2023-02-04 11:30:28 <veltas      > And of course CATCH-POINTER should start as zero, so THROW et al can detect a proper abort throw
2023-02-04 11:31:25 <veltas      > I've used this in gforth, but as I just described the implementation isn't complicated
2023-02-04 11:31:38 <veltas      > gforth and swift-forth
2023-02-04 12:16:01 <veltas      > gforth's CATCH https://github.com/forthy42/gforth/blob/master/except.fs#L81
2023-02-04 12:20:40 <thrig       > LOVE COMEFROM COBOL
2023-02-04 14:11:33 <veltas      > COMEFROM is a bit like a breakpoint
2023-02-04 15:34:23 <KipIngram   > joe9: I have something like an exception stack.
2023-02-04 15:34:27 <KipIngram   > Kind of.
2023-02-04 15:34:44 <KipIngram   > I have a register for the "current top" of that stack; the return stack is used to hold the deeper values.
2023-02-04 15:35:04 <KipIngram   > It lets me set a return point, high in a call hierarchy, that I can then return to from as many levels down as I like.
2023-02-04 15:35:24 <KipIngram   > I use it in one place in my system, to escape from the deep levels of FIND when I actually get a name match on the dictionary search.
2023-02-04 15:35:42 <KipIngram   > All the definitions between there and the top don't have to deal with the success case - it jumps out over them when it finds the word.
2023-02-04 16:02:12 <veltas      > "to escape from the deep levels of FIND" recursive FIND, first time I've seen that lol
2023-02-04 16:02:56 <veltas      > You know you did your max stack depth measurements, I'm interested in your max return stack depth!
2023-02-04 19:22:24 <dlowe       > veltas: not sure what you mean by 13:22 but epubs should scale. You talking about a table or a diagram?
2023-02-04 19:23:21 <dlowe       > the svgs used in diagrams don't scale, and sometimes tables can squeeze to the side depending on content
2023-02-04 19:39:59 <KipIngram   > I didn't mean that it was recursive.
2023-02-04 19:40:46 <KipIngram   > I just meant that it was factored into seven or eight levels of call/return.  Success is detected down at the deepest level, and from there it uses this exception feature to jump all the way back up to FIND itself, at the top.
2023-02-04 19:41:44 <KipIngram   > That jump up takes it into the middle of a { ... } stack frame, so the } puts the stack back to the right balance regardless of what was going on down below.  The TOS item, which is register cached, is brought back up and constitutes the return from FIND.
2023-02-04 19:42:00 <KipIngram   > Otherwise the stack just gets whacked back to what it was when { was executed.
2023-02-04 19:42:28 <KipIngram   > Actually for the exception system it's {| ... |} but otherwise as I just described.
2023-02-04 19:43:25 <KipIngram   > {| ... |} shares that same stack restoration feature of { ... }
2023-02-04 19:44:03 <KipIngram   > But also restores the return stack, whereas { ... } relates only to the data stack.
2023-02-04 19:45:38 <KipIngram   > I don't actually use recursion overtly anywhere in the system, though I have plenty of words that end in me; which is tantamount to tail recursion.
2023-02-04 19:45:56 <KipIngram   > Tail optimized tail recursion.  I tend to think about it as iteration, though.
2023-02-04 19:48:40 <KipIngram   > Here's what find looks like, if you're interested:
2023-02-04 19:48:43 <KipIngram   > https://pastebin.com/VrG0rUwB
2023-02-04 19:50:07 <KipIngram   > That does the whole job of searching a vocabulry list, so it's got three levels of iteration going on - iterating through the vocabularly list, iterating through each word list, and processing each character of each name (though that's mostly hidden inside s=  now).
2023-02-04 19:50:21 <KipIngram   > s= uses rep cmpsb