home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,882 of 117,927   
   albert@spenarnc.xs4all.nl to the.beez.speaks@gmail.com   
   Re: Recognizer proposal   
   11 Feb 26 12:29:38   
   
   In article ,   
   Hans Bezemer   wrote:   
   >On 09-02-2026 08:49, Anton Ertl wrote:   
   >> A more fleshed-out version of the current recognizer proposal is   
   >> online:   
   >>    
   >>   
   >> After many years this proposal is in transition from being fluid to   
   >> solid, so if you want major upheavals, I doubt that your input will be   
   >> acted upon (but you might still want to give it).  OTOH, if you find   
   >> any mistakes, missing parts or unclear parts, now is the time when   
   >> your input will be most effective.  In either case, please report any   
   >> feedback by clicking on the Reply button on the web page above.   
   >>   
   >> - anton   
   >   
   >   
   >Although I'm not gonna honor this proposal - for architectual and   
   >technical reasons - I'd like to give my opinion anyway. Because this is   
   >a mistake of Forth-83 like proportions.   
   >   
   >But let's begin at the beginning: why is is this proposal needed? What   
   >should it fix?   
   >   
   >"The classical text interpreter is inflexible: E.g., adding   
   >floating-point recognizers requires hardcoding the change; several   
   >systems include system-specific hooks (sometimes more than one) for   
   >plugging in functionality at various places in the text interpreter."   
   >   
   >To begin with: this is incorrect. If I define this word:   
   >   
   >: f%   
   >   bl word count >float 0= abort" Bad float"   
   >   state @ if postpone fliteral then   
   >; immediate   
   >   
      
   Adding the simple prefix qualifier   
      
       : f% .. ; IMMEDIATE PREFIX   
      
   the floating point denotation does away the parsing objection.   
   f%1.0E9 is a fp number, working in interpreter and compilation mode.   
      
   Now it is insane orthogonality that you have to postpone these,   
   (i.e. POSTPONE F%1.0E9 ).   
   : ...    ... [ F%1.0E9 ] postpone fliteral  ... ;   
   is accepted practice since ages.   
      
   The ciforth solution is slightly more complicated, where the   
   prefixes 0 1 2 .. 9 decide for themselves if the number is   
   single, double or fp. This is a slight step up from   
   discriminating between single and double.   
   1 single   
   2. double   
   2E0 fp   
      
   This eliminates the number branch in the lowest level interpreting,   
   (in ciforth this is INTERPRET) effectively *simplifying* the Forth   
   engine.   
      
   >Floating point numbers are recognized without a problem. So - the claim   
   >one needs to change the interpreter is simply false.   
   >   
   >Now what does TF have to say about "changing the interpreter"?   
   >   
   >"Don’t write your own interpreter/compiler when you can use Forth’s.   
   >Every time you see a unique interpreter, it implies that there is   
   >something particularly awkward about the problem. And that is almost   
   >never the case."   
      
   Hear hear.   
      
   Recognizers are complexifying and uglifying Forth, going the route from   
   the 70' to revector number.   
      
   Note that the PREFIX addition to ciforth is a nett simplification of   
   Forth.   
      
   >   
   >Hans Bezemer   
      
   Groetjes Albert   
   --   
   The Chinese government is satisfied with its military superiority over USA.   
   The next 5 year plan has as primary goal to advance life expectancy   
   over 80 years, like Western Europe.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca