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,908 of 117,927   
   Gerry Jackson to Hans Bezemer   
   Re: Recognizer proposal   
   13 Feb 26 23:50:56   
   
   From: do-not-use@swldwa.uk   
      
   On 13/02/2026 12:43, Hans Bezemer wrote:   
   > On 13-02-2026 09:27, Anton Ertl wrote:   
   >> Hans Bezemer  writes:   
   >>> On 12-02-2026 08:35, Anton Ertl wrote:   
   >>>> [...] small implementations   
   >>>> pick and choose from the standard requirements anyway, even among the   
   >>>> requirements for CORE words.  The CORE wordset has only been a   
   >>>> goalpost for peoplle who implement Forth as an exercise.   
   >> ...   
   >>> I don't think that people who are "implementing Forth as an exercise"   
   >>> can be bothered to make it "a standard compiler".   
   >>   
   >> The point is not standard conformance, but a goalpost: To have   
   >> something to direct the work, and also to have something that tells   
   >> the implementor when the project is complete.   
   >>   
   >>> And although wordsets build modularity (which I welcome) it becomes   
   >>> useless when it requires you to patch wordsets already implemented.   
   >>   
   >> Who is "you" in this sentence?  Given that you write "implemented",   
   >> you seem to argue that the standard requires the system implementor to   
   >> implement the base word, and then to patch it.  This is not the case.   
   >> The system implementor who has decided to implement the FILE words in   
   >> addition to the CORE words can implement the FILE version of S" from   
   >> the start, without any patching.   
   >>   
   >> Note also that the FILE version of S" conforms to the requirements for   
   >> the CORE version of S", and that's generally the case for the extended   
   >> versions of words.  E.g., the specification of CORE's POSTPONE   
   >> includes   
   >>   
   >> | An ambiguous condition exists if name is not found.   
   >>   
   >> so it does not specify what "POSTPONE 123" means.  The proposed   
   >> recognizer version of POSTPONE specifies that.   
   >>   
   >> - anton   
   >   
   > I could have used "one" - wouldn't have changed the meaning. Nice   
   > "Whataboutism"! The argument was (and is) what use has a standard for a   
   > toy compiler?   
      
   There's another point I think you're missing. I just looked on at my   
   Forth test suite on GitHub and 78 people have found it useful enough to   
   give it a star. I've no idea whether they are all developing their own   
   "toy" system but I would guess most are, and their system has to have   
   some testing. I suggest that the easiest way is to use an existing test   
   suite. As far as I know there is only one, so that automatically leads   
   them to make their system (at least partially) standard compliant. An   
   unexpected (and unintended) consequence of having a test suite.   
      
   Things are done when "one" says they're done. You (like   
   > "Anton") overestimate the authority of a standards body greatly.   
   > Especially when the language concerned is almost dead. There are more   
   > people implementing that compiler than writing programs for it!   
   >   
   > And yes - it often happens (I speak from my own experience) that "one"   
   > (now clear for you? :) thinks - "that's as far as I want/need to go" and   
   > consider otherwise later. And yeah, then "one" has to patch it. Because   
   > the word *IS* already defined "one" has to extend its functionality.   
   >   
   > "An ambiguous condition exists if name is not found."   
   > That's not a point I addressed. (Not "one").I just looked on GitHub   
   >   
   > Hans Bezemer   
   >   
      
   --   
   Gerry   
      
   --- 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