In article <66c94c52$1@news.ausics.net>, dxf   wrote:   
   >On 22/08/2024 8:59 pm, albert@spenarnc.xs4all.nl wrote:   
   >> In article ,   
   >> Hans Bezemer   wrote:   
   >>> On 13-08-2024 06:07, dxf wrote:   
   >>>> On 13/08/2024 5:34 am, albert@spenarnc.xs4all.nl wrote:   
   >>>>> ...   
   >>>>> In my book the code should be   
   >>>>>   
   >>>>>                          "        "   
   >>>>>                          "######  "   
   >>>>>                          "  ##    "   
   >>>>>                          "        "   
   >>>>> DEF-BRICK BRICK1   
   >>>>>   
   >>>>> Instead of   
   >>>>>   
   >>>>> DEF-BRICK BRICK1        S"         "   
   >>>>>                          S" ######  "   
   >>>>>                          S"   ##    "   
   >>>>>                          S"         "   
   >>>>>   
   >>>>> The code (untested) could be   
   >>>>> : DEF-BRICK CREATE   
   >>>>>      2>R 2>R 2>R 2>R   
   >>>>>      2R> ,, 2R> ,, 2R> ,, 2R> ,,   
   >>>>>   DOES>  ... ;   
   >>>>   
   >>>> OTOH it's no less difficult to write...   
   >>>>   
   >>>> : M"  [CHAR] " PARSE  HERE  OVER ALLOT  SWAP MOVE ;   
   >>>>   
   >>>> : DEF-BRICK  CREATE  DOES>  ROT 4 * ROT + 2* CHARS + ;   
   >>>>   
   >>>> DEF-BRICK BRICK1         M"         "   
   >>>>                           M" ######  "   
   >>>>                           M"   ##    "   
   >>>>                           M"         "   
   >>>>   
   >>>   
   >>> In 4tH, the easiest solution would be:   
   >>>   
   >>> : BRICK@ ROT + @C SWAP 2* CHARS + ;   
   >>>   
   >>> CREATE BRICK1   
   >>>   ,"         "   
   >>>   ," ######  "   
   >>>   ,"   ##    "   
   >>>   ,"         "   
   >>> DOES> BRICK@ ;   
   >>   
   >> I dislike the use of parsing here by ," . It happens to work   
   >> because ," doesn't destroy the concatenation of HERE.   
   >> So you couldn't check the solution without digging into the 4TH   
   >> documentation.   
   >>   
   >> In these case parsing is more or less advantageous because it allows   
   >> easier represent the bricks. The introduction of an auxiliary word M"   
   >> that is easily understood and checked is far superior using ," .   
   >> ...   
   >   
   >For the general case that's true.  OTOH 4tH is free to exploit what it has.   
   >The original ANS-Forth version tried using S" but it got complicated due   
   >to the dual-action word.  If standard compliance is the goal then options   
   >are limited.  OTOH a Gforth user not caring about compliance could exploit   
   >what he had and define things more succinctly:   
   >   
   >  : M"  \"-parse mem, ;   
   >   
   >(assuming he knew these words existed)   
      
   I accept the use of non standard words if there is an advantage for it.   
   In this case a small change keeps the program totally standard,   
   at the same time allowing to escape confusion over allocation   
   situations and having it run on a ciforth 10% of the complexity of   
   gforth.   
      
   I occasionally promote ciforth techniques, if they are substantially   
   simpler and standard programs look akward in comparison.   
      
   Probably mem, is the same as my   
   : ,, HERE SWAP DUP ALLOT MOVE ;   
      
   Groetjes Albert   
   --   
   Temu exploits Christians: (Disclaimer, only 10 apostles)   
   Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall   
   Art For Home, Office And Garden Decor - Perfect For Windows, Bars,   
   And Gifts For Friends Family And Colleagues.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)