From: anton@mips.complang.tuwien.ac.at   
      
   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.   
      
   Bernd Paysan thought that it would be easy to change back to a non-0   
   value for TRANSLATE-NONE, by looking at the patch that changed   
   NOTFOUND to 0.  However, in the meantime there has been more work   
   done, so it's not so easy.   
      
   E.g., there was a word   
      
   ?FOUND ( x -- x )   
      
   that would throw -13 if x=0.  This word was used both with the result   
   of recognizers and with nt|0 or xt|0.  Fortunately, in this case the   
   cases were easy to recognize, and they are now addressed by two words:   
   ?REC-FOUND (for recognizer results) and ?FOUND (for x|0).   
      
   What do we learn from this?  Merging two previously separate types   
   such that they are dealt with (partly) the same words (e.g., 0= in   
   this case) is easy, as is mixing two kinds of sand.  Separating two   
   previously (partly) merged types to use type-specific words is a lot   
   more work.   
      
   You can fake it by defining 0 CONSTANT TRANSLATE-NONE, but then you   
   never know if your code ports to other systems where TRANSLATE-NONE is   
   non-zero.  For now Gforth does it this way, but I don't expect that to   
   be the final stage.   
      
   Should we prefer to separate types or merge them?  Both approaches   
   have advantages:   
      
   * With separate words for dealing with the types, we can easily find   
     all uses of that type and do something about it.  E.g., a while ago   
     I changed the cs-item (control-flow stack item) in Gforth from three   
     to four cells.  This was relatively easy because there are only a   
     few words in Gforth that deal with cs items.   
      
   * With a merged approach, we can use the same words for dealing with   
     several types, with further words building upon these words (instead   
     of having to define the further words n times for n types).  But   
     that makes the separation problem even harder.   
      
   Overall, I think that the merged approach is preferable, but only if   
   you are sure that you will never need to separate the types (whether   
   due to a committee decision or because some new requirement means that   
   you have to change the representation of the type).   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
   EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html   
   EuroForth 2025 registration: https://euro.theforth.net/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)