Digest #197 2022-08-29
Contributions
I am trying to implement >NUMBER on the top of a working 79-STANDARD CONVERT implementation. What I came up with so far is:
: >NUMBER ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
R DUP >R \ S: ud1 c-addr1 R: u1 c-addr1 1- CONVERT \ S: ud2 c-addr2 R: u1 c-addr1 DUP R> - \ S: ud2 c-addr2 c-addr2-c-addr1 R: u1 R> SWAP - ; \ S: ud2 c-addr2 u1-(c-addr2-c-addr1)
But I have a problem with one of the test cases:
T{ 0 0 GN' F' 10 >NUMBER-BASED -> F 0 GN-CONSUMED }T
My interpreter chokes on the F character right after -> because the current BASE is decimal. I think this test pattern is incorrect. Anyone cares to shed tome light on this?
This is a test proposal
Let's see if the system & programmer proposals work
Replies
proposal - Exclude zero from the data types that are identifiers
Should the notation
{0}be also described?
Since relative complement is used only for {0}, this notation can be introduced at once with relative complement:
The notation i \ {0} is used to denote "the data type that includes all those and only those members of i which are not single-cell zero value".
Actually, I agree. It just useful to see a comparison of different solution, and a clear list of proposed changes.
a standard program would have to consider both behaviours.
If a program relies on the Exception word set (e.g. it uses catch), it have to consider only one behavior, since it cannot work on the systems that don't provide the Exception word set. If the program doesn't use catch, it doesn't consider any specific behavior in the corresponding cases at all.
Having the Exception word set mandatory, don't you think that CORE ABORT and CORE ABORT" should be removed, and their EXCEPTION versions and THROW should be corrected/rewritten?
Even if the program did not contain CATCH, it would have a different (unambiguous) meaning with the exception wordset and be ambiguous without.
Having the Exception word set mandatory, don't you think that CORE ABORT and CORE ABORT" should be removed, and their EXCEPTION versions and THROW should be corrected/rewritten?
Yes, something like that.
requestClarification - Should QUIT propagate exceptions?
Concerning the throw code -56 that you mention on github, I don't think it has anything to do with the Forth word QUIT. My guess is that it's for the Unix signal SIGQUIT (however, none of Gforth, iforth, lxf, SwiftForth, VFX converts it into a Forth exception; instead, SIGQUIT terminates them all).
In the frame of a big re-organization of THROW specification, the following phrase should be also corrected:
If any bits of n are non-zero, pop the topmost exception frame from the exception stack, along with everything on the return stack above that frame.
The part "along with everything on the return stack above that frame" should be removed, since it implies that the exception stack is implemented using the return stack.
The return stack depth is restored according to the part "adjust the depths of all stacks defined by this standard so that they are the same as the depths saved in the exception frame".
Also, the specification for CATCH should require it to save in the exception frame the depth of all stacks defined by this standard .
Call for votes, does that work?