Digest #92 2020-02-07
Contributions
referenceImplementation - sample implementation that can also be interpreted
The current sample implementation uses >R and R>, which are compile-only (technically "Interpretation semantics for these words are undefined").
Instead WITHIN is expected to work also when interpreting.
The following implementation fixes that, and is correct under the same condition "For two's-complement machines that ignore arithmetic overflow" as the current sample implementation:
: WITHIN ( test low high -- flag ) OVER - ROT ROT - U> ;
Problems in the current wording
- Start a definition, append semantics, and end the definition — are the steps of creating a colon definition. Therefore, create a definition, and then start the definition — looks confused. Also, I think, a standard should not require (or even specify) the side effects that cannot be detected by a standard program.
So, «Create a definition for name, called a "colon definition".» part may be removed.
- "colon definition" term should be defined separately.
It may be moved into the Rationale (since it is not used in the normative parts) or into the Terms definitions (since a noname definition and a quotation are also colon definitions, but this fact is not expressed explicitly at the moment).
- «start the current definition» is doubtful wording, since "current definition" is a definition that was already started (according to the terms definitions).
Therefore, it is better to say "new definition".
Suggested wording of the first paragraph
Skip leading space delimiters. Parse name delimited by a space. Enter compilation state and start the new definition for name, producing colon-sys. Append the initiation semantics given below to the current definition.
Replies
There is a reason why it's not findable in the dictionary, and it's a feature: it allows you to extend existing words in the dictionary be referencing the old behavior without having to know the original code. For example:
: dup ." Duplicating " dup . cr dup ;
I don't need to know how DUP is implemented, but I just extended it so that future uses of DUP will output to the console that it was called. Additionally, it doesn't affect the original behavior, which other code is using; it only impacts new uses, meaning there's no chance of damaging existing, working code.
Given that [IF] accepts only flags as the input type, the only word in the forth standard that specifies this. If that is the appropriate action for [IF], then should that also apply to IF, WHILE, UNTIL, etc.???
I'm sure it would break a great deal of code to tighten up the definition of IF to only accept flags as input. The standard specifically talks about this.
A.3.1.3.1 Flags A FALSE flag is a single-cell datum with all bits unset, and a TRUE flag is a single-cell datum with all bits set. While Forth words which test flags accept any non-null bit pattern as true, there exists the concept of the well-formed flag.
While it goes on to talk about issues with certain logic words and flags, it has clearly set the intent for valid inputs to conditionals including all numbers and not just flags. This concept goes all the way back to "Starting Forth" and is embodied in every system I've used. Why should [IF] be defined differently from IF in terms of the inputs???
@alextangent I don't doubt the proposer's statement that the standard's description of [IF] was probably unintended, and that my suggestion has little chance of being adopted; however, it is worth considering for the following reasons:
Keeping the requirement of a well-formed flag for [IF] will ensure that programmers provide greater precision in the logical operand to [IF].
Your claim that it will have an unknown effect on extant code is incorrect. Existing source code which does not provide a well-formed flag to [IF] will simply fail to load. This gives the authors a chance to fix the problem. For example, "1 [IF]" can be replaced by "true [IF]". Any computed flag which may not be well-formed can be converted to a well-formed flag using 0<> .
@gnuarm No, I made no suggestion that a well-formed flag be a requirement to other conditional branch words such as IF , WHILE , UNTIL. Such a proposal would have severe consequences for exisiting code and cannot be done so easily. It may be worth heading in that direction ultimately, but the present suggestion is more modest.
It will likely confuse people when IF and [IF] differ in that IF takes an x and jumps on 0, where [IF] only takes a well-formed flag.
Forth is not a typechecking language, and as consequence, we don't demand well-formed flags as inputs.
@BerndPaysan Yes, the possible confusion for programmers in the difference in behavior between [IF] and IF is a legitimate concern.
Standard Forth is not a type-checking language. However, it is a typed language; otherwise stack diagrams would simply consist of the number of cell operands before and after. The standard makes anathema words with a stack diagram such as ( flag -- ), both through exclusion of any standard words which take well-formed flag operands (although [IF] is probably an unintended exception), and via the language of A.3.1.3.1. That appears to me to be an extreme position.
I believe my suggestion and discussion about this is probably premature in connection with this proposal, since it likely deals with unintentional language in the standard. Therefore, the language should be fixed per intent and per common practice. I agree with @alextangent that, from a standards perspective, this makes sense for the current proposal.
"@gnuarm No, I made no suggestion that a well-formed flag be a requirement to other conditional branch words such as IF , WHILE , UNTIL. Such a proposal would have severe consequences for exisiting code and cannot be done so easily. It may be worth heading in that direction ultimately, but the present suggestion is more modest."
@KrishnaMyneni Your present suggestion may be "more modest', but it is no less consequential for breaking existing code. Certainly it would not be "easy" to implement such a change. It is good that you retracted it.
Perhaps, in place of:
start the new definition for name, producing colon-sys
it is better to say:
start compilation of the new definition for name, producing colon-sys
To be in sync with the term definition:
current definition: The definition whose compilation has been started but not yet ended.