From: ruvim.pinka@gmail.com   
      
   On 2024-03-07 16:29, Ruvim wrote:   
   > The accepted proposal for quotations [1] specifies only compilation   
   > semantics for the words "[:" and ";]".   
   >   
   > The expected interpretation semantics for "[: ... ;]" are that this   
   > construct behaves like ":noname ... ;" (at least for the resulting stack   
   > effect), but the system should correctly work regardless whether the   
   > current definition exists (i.e., a definition that is being compiled).   
   > It means, if a definition is being compiled, its compilation shall be   
   > correctly suspended by "[:", and resumed after ";]" under the hood.   
   >   
   > Bellow are the test cases for the standardized compilation semantics,   
   > and for the expected interpretation semantics.   
   >   
   > Interestingly, some Forth systems fail the t12 and t13 tests for the   
   > standardized compilation semantics.   
   >   
      
   [...]   
      
   >   
   >   
   >   
   > ===== start of "quotation.test.fth"   
   >   
   > \ Test cases for quotations "[: ... ;]"   
   >   
   >   
   >   
   > \ Testing the compilation semantics   
   >   
   > \ t11   
   > t{ :noname [: 123 ;] ; execute execute -> 123 }t   
   >   
   > : lit, postpone literal ;   
   > : ([:) postpone  [: ;   
   > : (;]) postpone  ;] ;   
   >   
   > \ t12   
   > t{ :noname  [ ([:) (;]) ]  ;  0<>  ->  -1  }t  > \ t13   
   > t{ :noname 1 [ ([:) 2 lit, (;]) ] 3 ; execute swap execute -> 1 3 2 }t   
   >   
      
   t12 roughly tests that the compilation semantics for the words "[:" and   
   ";]" can be correctly performed programmatically.   
      
   This test fails in Gforth, VfxForth, minForth.   
      
   The problem is that the system enters compilation state after executing   
   "([:)". But it shall not. This action cannot be a part of compilation   
   semantics at all (it's not possible to correctly specify this action,   
   and it is not actually specified for the "[:" compilation semantics).   
      
   The reason of the problem is that "postpone" is implemented not quite   
   correctly in these systems. After including a polyfill for "postpone"   
   [2], the tests t12 and t13 are passed in Gforth.   
      
   VfxForth (5.20 Alpha 1 [build 4065]) and minForth (V3.4.8) provide   
   neither "find-name" nor correct "find", so "postpone" cannot be   
   correctly defined by the polyfill.   
      
      
   [2] About POSTPONE semantics in edge cases / Solution   
      
      
      
   --   
   Ruvim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)