Proposal: [36] EXCEPTION LOCALs
This proposal has been moved into this section. Its former address was: /standard/exception/THROW
This page is dedicated to discussing this specific proposal
ContributeContributions
AndrewRead
[36] EXCEPTION LOCALsProposal2017-10-28 07:04:49
Disclaimer - my opinion is biased by the work I have already done on my hardware Forth machine
Conceptually I see BASE, and STATE (and some variables connected to the standard input / output) not as GLOBALs but as "EXCEPTION LOCALs". I.e. variables located on the exception stack. (My analogy here is with the more familiar "SUBROUTINE LOCALs" we are familiar with from the subroutine stack.)
When the Exception stack is PUSH_ed (by CATCH), then the current values of BASE etc. are pushed onto the Exception stack too.
When the Exception stack in POP_ed (by 1 THROW), then the current values of BASE etc. are discarded and the values from the exception layer above become current.
This is easy to implement if BASE etc. are located wherever the exception stack is located. I do it in hardware, but that's a detail.
AntonErtl
There is a lot of STATE that can be changed in a word called through CATCH, and that we may want to restore when an exception is THROWn, not just BASE and STATE. Conversely, there are many words that are called through CATCH that do not change BASE and STATE, so always saving and restoring BASE and STATE would be wasteful. My solution for this is cleanup wrappers, such as
: base-execute ( xt u -- )
base @ >r base ! catch r> base ! throw ;
And while the standard describes the input source specification as a kind of exception locals, at least Gforth uses a cleanup wrapper for restoring it. You can read more about cleanup in my EuroForth'08 paper.
Anyway, I don't think we need exception locals.
Another issue is that some people fail to use such wrappers (after all Thinking Forth does not advocate it), and then a THROW returns to a different CATCH or the Forth command line without restoring the state. For STATE, the standard specifies that it is set to interpreting when there is no user-supplied exception handler, for BASE the user has to fend for himself (as advocated in Thinking Forth). It is a good idea if the system warns of non-decimal BASE, e.g., by mentioning it after "ok".
AndrewRead
Anton is correct, this is a small part of a wider issue. I believe in small government and small standards. Let’s avoid unnecessary complexity.