Digest #25 2018-01-08
Contributions
referenceImplementation - Suggested reference implementation
: FILL -ROT 0 ?DO 2DUP C! 1+ LOOP 2DROP ;
referenceImplementation - Suggested reference implementation
: 2DROP DROP DROP ;
referenceImplementation - Suggested reference implementation
: 2DUP OVER OVER ;
referenceImplementation - Suggested reference implementation
: 2SWAP >R -ROT R> -ROT ;
referenceImplementation - Suggested reference implementation
: 2OVER 2>R 2DUP 2R> 2SWAP ;
referenceImplementation - Suggested reference implementation
: OVER >R DUP R> SWAP ;
referenceImplementation - Suggested reference implementation
: TYPE 0 MAX 0 ?DO DUP C@ EMIT 1+ LOOP DROP ;
referenceImplementation - Suggested reference implementation
: ['] IMMEDIATE ' POSTPONE LITERAL ;
referenceImplementation - Suggested reference implementation
: [CHAR] IMMEDIATE CHAR POSTPONE LITERAL ;
referenceImplementation - Suggested reference implementation
: HEX 16 BASE !
referenceImplementation - Suggested reference implementation
: NIP SWAP DROP ;
referenceImplementation - Suggested reference implementation
: TUCK SWAP OVER ;
Replies
Not every CATCH needs to be wrapped, only code that changes STATE. If you have a word that changes and has to restore STATE, use a STATE-wrapper. All other CATCHes are unaffected. Because the INCLUDED can change STATE, use a STATE-wrapper for the INCLUDED in your example.
The cited statement from the rationale is about what happens on the stack, and is unrelated to other state.
A system that saves and restores STATE on a CATCH would not be standard, because it would do programmer-visible things that are not specified in the standard.
The current definition of CATCH and THROW is deliberately minimal. I believe that it should stay minimal. An embedded system may use CATCH/THROW but not have STATE or BASE.
We (MPE) have attempted in the past to cope with customer wishes for extended facilities. 30 years later we regret all these concessions. The best that we could do now is to DEFER CATCH and THROW.
In the given use case (INCLUDED and friends), the most likely action of the final error handler is to leave compilation and perform some form of restart. We also have plenty of instances in which errors are rethrown because the CATCH/THROW mechanism itself is used to ensure state recovery at several levels. In this case, putting a CATCH inside INCLUDED and then throwing again permits STATE restoration, and no specification change for CATCH is required.
referenceImplementation - Suggested reference implementation
IMMEDIATE itself is not immediate, so Bernd Paysan's reference implementation is correct, and it contains a stack effect comment.
referenceImplementation - Suggested reference implementation
IMMEDIATE is not immediate, so this won't work. A working version is:
: ['] ( compilation: "name" --; run-time: -- xt ) ' POSTPONE literal ; immediate