From: ruvim.pinka@gmail.com   
      
   On 2025-09-26 02:19, Ruvim wrote:   
   > On 2025-09-17 20:53, Anton Ertl wrote:   
   >> This posting is a more general reflection about designing types in   
   >> Forth; it just uses recognizers as example.   
   >>   
   >> The original proposal for recognizers had R:FAIL as the result of a   
   >> recognizer that did not recognize the input.  Later that was renamed   
   >> to NOTFOUND; then there was a proposal where 0 would be used instead,   
   >> and Bernd Paysan changed all the uses of NOTFOUND in Gforth to 0.   
   >> Finally, on last Thursday the committee decided to go with   
   >> TRANSLATE-NONE for that result.   
      
   [...]   
      
   >   
   > There is a quite general type: ( i*x x\0 ). Let's call it "any-nz".   
   >   
   > The unique feature of this type is that there is a simple and general   
   > method to check whether a data object is a member of this type — just   
   > check whether the top single-cell value is a non-zero. And this method   
   > applies to *any* subtype of this type.  This method is made even more   
   > elegant by the fact that control flow operators apply it automatically.   
   >   
   > Note that nt, xt, wid are subtypes of any-nz.   
   >   
   > Another side of any-nz is that a union type ( any-nz | 0 ) is a natively   
   > discriminated union. This has led to a common approach of returning any-   
   > nz on success and 0 on failure.   
   >   
   > The question is: should the recognizers follow this approach? I think   
   > so.  This effectively means that a type of a success result of a   
   > recognizer is a subtype of any-nz, and a type of a failure result is a   
   > subtype of the unit type "0".   
      
      
   This also makes recognizers more convenient to use in programs.   
      
   For example:   
      
      "foo" rec-name if ( nt ) ... else (  ) ... then   
      
      buf accepted ( sd.string ) trim   
      rec-number-float if ( F: r ) ...   
      else ." try again" cr recurse then   
      
   Why burden users with the word `translate-none` in all such cases?   
   (instead of burden systems implementors with special-casing zero in a   
   few cases only).   
      
      
      
   Worse, in the latest proposal this word `translate-none` doesn't do what   
   its name implies — it does not perform any translation.   
      
   In the previous proposal (2024-12-15) translate-* words perform   
   translation. In the latest proposal (2025-09-12) translate-* words are   
   constants (i.e. words that return some value, the same each time they   
   are executed).   
      
   According to the traditional naming convention, the names of constants   
   should be nouns (or noun phrases), not verbs.   
      
   This is as if `read-file` returned a reading mode (a constant) instead   
   of reading data from a file.   
      
      
      
      
   > The only counterargument is that 0 on failure is too restrictive for   
   > implementations.   
   >   
   > This does not seem convincing. Because `search-wordlist`, `find`, `find-   
   > name`, `find-name-in` return 0 on failure and this is not too   
   > restrictive for implementations.   
   >   
   > OTOH, why in this case we should prefer the convenience of   
   > implementations over the convenience of programs?   
      
      
      
   --   
   Ruvim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)