,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2020-01-11 12:07:07  AntonErtl  wrote:
| proposal - Input values other than true and false
| see: https://forth-standard.org/proposals/input-values-other-than-true-and-false#contribution-126
`------------------------------------------
# Problem

"flag" is speficied as:

> Flags may have one of two logical states, true or false.

So what happens if you give a value other than true or false to [if]?  Looking at the specification, that would be a non-standard program, but without stating that explicitly (and it's probably unintentional).  

# Existing Practice

Testing a number of Forth systems with the following code:

    1 [IF] .( true ) [ELSE] .( false ) [THEN]

Gforth, SwiftForth, VFX, iForth, PFE and lxf output "true", so there is common practice for accepting all non-zero values as true (like IF); (spf apparently does not support [IF]).

# Proposal

Replace

> ( flag | flag "<spaces>name ..." -- )
>
>If flag is true, do nothing.

With

> ( x | x "<spaces>name ..." -- )
>
> If any bit of x is set, do nothing. 


,---------.
| Replies |
`---------´


,------------------------------------------
| 2020-01-11 10:35:06  PeterKnaggs  replies:
| requestClarification - Why RECURSE is needed?
| see: https://forth-standard.org/standard/core/RECURSE#reply-344
`------------------------------------------
Your assumption is invalid.  Although the dictionary entry for FACTORIAL is indeed defined when : (colon) is executed, the definition is "smudged" so that it is not available to FIND and friends.  Thus using FACTORIAL will execute a previous definition of FACTORIAL rather than starting the current definition again.  The when ; (semi-colon) is executed it removes the smudge from the dictionary entry, making the new definition of FACTORIAL viable.  Thus to direct execution back to the start of the current definition you must use RECURSE.


,------------------------------------------
| 2020-01-11 17:44:35  KrishnaMyneni  replies:
| proposal - Input values other than true and false
| see: https://forth-standard.org/proposals/input-values-other-than-true-and-false#reply-345
`------------------------------------------
I feel this is a step backwards. I think the stack diagram should remain and [IF] should throw an error for an argument which is not Boolean (TRUE or FALSE).



,------------------------------------------
| 2020-01-11 23:33:50  alextangent  replies:
| proposal - Input values other than true and false
| see: https://forth-standard.org/proposals/input-values-other-than-true-and-false#reply-346
`------------------------------------------
Why? 

You give no reason for doing something that is anathema to (most sane) standards; that is, tightening a definition in a direction that no implementation supports, and that would have a large & unknown effect on extant code.