From: anton@mips.complang.tuwien.ac.at   
      
   Gerry Jackson  writes:   
   >Sorry Anton I read your message and was going to reply and I   
   >accidentally did something that caused Thunderbird to lose your message.   
   >I can't find it and it isn't in the 'deleted' folder. I'd be grateful if   
   >you could repost it please.   
      
   It's <2025Oct31.153524@mips.complang.tuwien.ac.at>.  You can look it   
   up on, e.g., .   
      
   > From my memory the gist of your message was:   
   >given   
   >   
   >my-condition [if]   
   >\  I have something witty to say about [if]   
   >      ....   
   >[else]   
   >      ....   
   >[then]   
   >   
   >I think you said that if MY-CONDITION is TRUE then the first [if] let's   
   >the Forth interpreter take over and so the second [IF] is ignored   
   >because it's in a comment and all is good   
   >   
   >But if MY-CONDITION is FALSE the second [IF] is reached with unknown   
   >consequences.   
      
   The consequences are known, but probably unintended: the [ELSE] and   
   [THEN] are perceived as belonging to the second [IF], so at the end   
   one is still scanning for the [THEN] or [ELSE] that belongs to the   
   first [IF].   
      
   >Or are you saying that the second [if] should be found because that is   
   >what is expected in a standard by the Forth standard   
      
   Yes, a system that ignores [IF] in comments would not be   
   standard-conforming, and not in line with existing practice in   
   systems.   
      
   Given that nobody will write something like the example above (if   
   their system is standard-conformung), does it matter?  Let's see if I   
   can construct an example that might occur and where it matters:   
      
   my-condition [if]   
     .( a)   
   [else]   
     .( b)   
   \ [else]   
     .( c)   
   [then]   
   .( d)   
      
   I tested on gforth 0.7, iforth-5.1 mini, lxf, sf64-4.0.0-rc89, and   
   vfx64-5.43.  I put the lines above into /tmp/xxx.fs.   
      
   With   
      
   true constant my-condition include /tmp/xxx.fs cr bye   
      
   all systems except iforth output "acd", as specified by the standard.   
   iforth outputs "ad", i.e., it has a scanner that treats "\"   
   especially.  For   
      
   false constant my-condition include /tmp/xxx.fs cr bye   
      
   every system outputs "bcd", as specified by the standard.   
      
   Again, I doubt that anybody will use that intentionally in production   
   code.  There might be some opccurences by mistake, where, rather than   
   fixing the problem (the [ELSE] in text that's not text-interpreted),   
   some workaround was implemented.  Still, these cases should be so rare   
   that a change should be doable, if it was really wanted.   
      
   The bigger problem is that you get the same problem with other parsing   
   words.  Parsing words can be user-defined, and with search order   
   changes one can make things even harder for an [IF] etc. set of words   
   that try to be smart about such uses.  So where would we stop?  Should   
   we stop right at the beginning before special-casing any parsing word?   
      
   >Or have I missed some nuance in your message?   
   >I remember a comment about ." but don't remember anything else   
      
   I gave an example where ." was used as a parsing word that parses [IF]   
   and [ELSE].  But nothing fundamentally different from the cases   
   involving \.   
      
   - 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)