This is specifically about RetroForth/nga.
In the #retro irc channel, ae_chep said:
I was imagining a forth development experience to be like a conversation had with the interpreter. In which case to be hung up on is rather unpleasant
This is a quite reasonable way to view the expected experience. In the current system, I just report errors and exit, but that's not necessarily the best option in all cases.
Rick suggested adding hook-able words for logging/instrumentation/alerting. This seems like something that would be worth adding.
I think we should look at adding words for this, probably under the err: namespace. It might be worth having two paths. In the case of running a program directly, have these default to reporting error and exit. But in the case of an interactive session, it might be better to offer a way to try resetting the system state to something sane and allowing execution to continue.
Thoughts on this?
Hey everyone,
I wanted to jump back into the discussion we had on Patreon.
With regards to the new comment:
Being hung up on is rather unpleasant.
I totally agree with this sentiment. I've personally experienced this issue, and it's not fun. After hearing more about the context of the situation, I think it would be helpful to determine at runtime whether the -i (interactive) flag has been passed or not.
For example, if I'm using Retro to serve requests to TCP sockets in a production environment, I definitely wouldn't want it to swallow errors when it runs into an error. But if I'm working in interactive mode (trying things out / doing dev work) it would be great not to have to restart my environment every time I make a mistake.
So yeah, I hope that clears things up a bit! Thanks for adding more context to the conversation.
Cheers!