In article , Ruvim   wrote:   
   >On 2024-08-05 14:04, albert@spenarnc.xs4all.nl wrote:   
   >> In article ,   
   >> Ruvim   wrote:   
   >>> On 2024-08-04 15:11, albert@spenarnc.xs4all.nl wrote:   
   >>>> Particularly I hate ' / ['] .   
   >>>> My solution that ' has to elevated to a denotation.   
   >>>> Meaning 'someword leave the address/dea/handle/nametoken   
   >>>> of `` someword '' that is the same in interpret and compile mode.   
   >>>   
   >>>   
   >>> I also often use `'someword` instead of `['] someword` and `' someword`,   
   >>> because I hate different forms for the conceptually same thing in   
   >>> interpretation and compilation, and because the form `'someword` is   
   shorter.   
   >>>   
   >>> Another thing I hate is when it's not obvious that a word is a parsing   
   >>> word, or what its delimiter. So I prefer when parsing delimiters are   
   >>> visible.   
   >>>   
   >>> For example, I would prefer:   
   >>>    want( word1 word2 word3 )   
   >>> rather than:   
   >>>    want word1 want word2 want word3   
   >>   
   >> I have changed WANT to accept several words on the same line   
   >>      want word1 word2 word3   
   >> This is one of the few "improvements" I'm not sure about.   
   >> By itself WANT is a concession because it is actually   
   >> "word1" WANTED "word2" WANTED "word3" WANTED   
   >> Your proposal makes sense, having several WANT(ED) on the same line   
   >> is ugly and impractical, but parsing to the end of line is dubious.   
   >>   
   >>>   
   >>> But if you hate parsing words in principle (just because they do   
   >>> parsing), why not hate such long parsing words like `[if]`, `\`, the   
   >>> construct "]]...[[", etc? What is an alternative for them?   
   >>   
   >> WANT is used recursively in blocks. If you wanted to accomplish the   
   >> same thing with [IF], it would be a horrid mess.   
   >   
   >I meant the word `[IF]` by itself, without connection with `WANT`.   
   >   
   >The word `[IF]` is a parsing word. If you hate parsing words in general,   
   >what alternative to `[IF]` could you suggest?   
   >   
   >   
   >The word `]]` is also a parsing word (in a standard-compliant   
   >implementation). It parses the input stream till the lexeme "[[".   
   >   
   >How to implement such functionality without active parsing the input stream?   
   >   
   >   
   >But if such long parsing words like `[IF]` and `]]` are acceptable, why   
   >the words that parses a single lexeme are not acceptable? (apart from   
   >naming and terminator visibility problems)?   
      
   Long story short:   
   I'm practical. I don't care for [IF] and I just copied from the   
   ANSI manual. I'm not dogmatic about it.   
   [IF] can be implemented by wordlists, relying on regular parsing   
   INTERPRET. I don't care for [IF] to implement that more elegant   
   method, and take on the burden of testing.   
   In my lisp efforts I have found that using INTERPRET recursively   
   can be very effective as long as you can switch the inputstream   
   easily. That makes EXECUTE-PARSING all but superfluous.   
      
   E.g. manx is an elaborate program running from windows32 to linux64.   
   There is only one [IF] to do tracing output, not used in a long time.   
   My reverse engineering assembler/disassembler is equally portable and   
   contains not a single [IF].   
   This is possible by using a library mechanism described above   
   WANTED.   
      
   >Ruvim   
      
   Groetjes Albert   
   --   
   Don't praise the day before the evening. One swallow doesn't make spring.   
   You must not say "hey" before you have crossed the bridge. Don't sell the   
   hide of the bear until you shot it. Better one bird in the hand than ten in   
   the air. First gain is a cat purring.            - the Wise from Antrim -   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)