In article <2025Apr18.082817@mips.complang.tuwien.ac.at>,   
   >One way to keep backwards compatibility with the current common   
   >practice would be to require having a word FORTH-2030-FP-SYNTAX (or   
   >maybe just FORTH-2030) in every file that uses the new FP syntax   
   >before the use of that syntax.  If that word does not appear in that   
   >file, "1.0" would still be non-standardized.   
      
   This would be easy enough   
   The file   
      dbase_FORTH-2xxxx.frt   
   contains   
   "   
   ALSO FORTH-2xxxx \ A named vocabulary   
      do   
      your   
      thing   
   PREVIOUS   
   "   
   wordlist are underused. You could have two independant random   
   number generators, by loading the source twice.   
      
   Because ciforth uses prefixes 0 1 2 .. 9 parse a number I can redefine   
   (in a separate wordlist or just in FORTH)   
      
   : 7   
     -1 PP   +!   (NUMBER)   POSTPONE SDLITERAL   
    IMMEDIATE  PREFIX   
      
   It is sufficient to revector SDLITERAL   
      
   Now SDLITERAL is   
   (DPL is the position of the decimal point, initialised at NULL)   
   : SDLITERAL DPL @ IF POSTPONE DLITERAL ELSE DROP POSTPONE LITERAL THEN   
    IMMEDIATE   
      
   I could revector it with   
   : SDLITERAL DPL @ 0<> 10 ?ERROR DROP POSTPONE LITERAL ;   
      
   (With 10 meaning "not a valid digit")   
      
   By the way. Do you really need numbers like   
   340282366920938463463374607431764264639   
      
   Maybe it is time to ditch double integers, the decimal point is a   
   seventy's kludge. The most characteristic feature of integers is ...   
   that they don't contain a decimal point, embedded or trailing.   
   Simply put, it is time to reserve the decimal point for floats.   
      
   If you really are into number theory, primes whatnot,   
   you could think of a proposed prefix (recognizer)   
      
   \ DMAXUINT in decimal:   
   ##340282366920938463463374607431764264639   
      
   and maybe   
   $$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF   
      
   I see Marcel Hendrix programs and there constant integers have   
   a $ or a # prefix anyway.   
      
   Groetjes Albert   
      
      
      
      
   >   
   >Next: "1.".  If we had such declarations, we could even support "1."   
   >(standardized as double-cell in Forth-94 and Forth-2012) as FP number.   
   >The alternative would be to treat "1." as double-cell and 1.0 as FP   
   >value, which IMO is even worse than requiring an "e" in every FP   
   >value.   
   >   
   >But back to the dial-a-standard things: I have never seen such a   
   >proposal that limits the dialing to one file.  Instead, the proposals   
   >and existing practice is to dial for the rest of text interpretation   
   >(or until somthing else is dialed).  That would mean that previously   
   >working files might no longer work when included after dialing the new   
   >FP syntax.  E.g., all versions of the recognizer proposal have been   
   >along these lines, and Bernd Paysan has actually proposed allowing to   
   >treat "1." as FP value by swapping the integer and FP recognizer in   
   >the recognizer order, which would have exactly this effect.  And Bernd   
   >Paysan is not the only one: Among other dialing features that all are   
   >not limited to the file, VFX supports disabling the recognition of   
   >"1." as double, which then leads to its recognition as FP number; but   
   >that disabling is not limited to a file, but extends to the rest of   
   >the text interpretation.   
   >   
   >Here's the example for VFX:   
   >   
   >',' dp-char 1+ c!  ok   
   >1.  ok F:-1   
   >f. 1.  ok   
   >   
   >So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I   
   >expect that the reactions would be along the following lines (in the   
   >community and in the standardization committee):   
   >   
   >1) A number of people consider this completely unnecessary, and   
   >   actually heretical, because Chuck Moore came down from the mountain   
   >   with doubles, not floats, so that's the way it was always meant to   
   >   be.  Some would argue that treating "1.0" or "1." as FP number is   
   >   proposed just to cater to C programmers, and that Forthers should   
   >   take pride in deviating from the beaten path.   
   >   
   >2) A number of people would argue against the limitation to a specific   
   >   file because of "complexity" (meaning implementation complexity),   
   >   "WIBNI", or because Chuck Moore came down from the mountain without   
   >   that idea, and that Chuck Moore has argued against libraries, that   
   >   he has argued against saving and restoring state, and instead has   
   >   argued for always setting it.  And that the common practice (e.g.,   
   >   in VFX) is to just set the state, and never   
   >   
   >3) And if you changed your proposal to just affect the rest of text   
   >   interpretation (and include another word FORTH-2012-FP-SYNTAX or   
   >   somesuch to switch back), some people (including me) would argue   
   >   that this variant of FORTH-2030-FP-SYNTAX would break existing   
   >   code, and that introducing FORTH-2012-FP-SYNTAX is a poor and   
   >   error-prone substitute for defining FORTH-2030-FP-SYNTAX properly.   
   >   Word counters would dislike this variant because it introduces an   
   >   additional word, and the people who argue 1) would also dislike the   
   >   proposal.   
   >   
   >The bottom line is that the proposal would probably not find a   
   >consensus and would not be accepted by the committee.  The bottom line   
   >is:   
   >   
   >>> One could dream up ways to deal with that problem, but given past   
   >>> experience, I doubt such ideas would find enough support   
   >   
   >And the bottom line of that is that proposals for incompatible changes   
   >have little chance of being accepted.   
   >   
   >>There could be special words like [FORTH78], [ANSFORTH] - which would no   
   >>nothing but:   
   >>- Either hiding words in the dictionary that should be disabled;   
   >>- Activating words that are part of this standard;   
   >   
   >Interestingly, Forth-79 includes a word 79-STANDARD, and Forth-83   
   >includes a word FORTH-83, but Forth-94 and Forth-2012 do not include   
   >such words.  We had a discussion whether we should have Forth-94 and   
   >Forth-2012 versions of environmental queries for wordsets in   
   >Forth-2012, but the committee decided against that.   
   >   
   >In any case, if you want to support including libraries written for a   
   >different standard, the effect of such words should be limited to a   
   >specific file.  If the standards are incompatible and you want   
   >libraries, and you do not provide this kind of dialing, you can take a   
   >look at the Python 3 transition pain (or worse, what happened with   
   >Perl6) to see what happens.  The Python community has learned from   
   >that experience not to introduce such incompatible changes again.   
   >   
   >>- Assigning the proper "version" words to trampolines or DEFERs.   
   >   
   >That's exactly the wrong thing to do.  You want to statically bind the   
   >name to the word with the right version.  E.g. if you have a Forth-83 program   
   >   
   >  forth-83   
   >  100 load ( includes a library written in Forth-79)   
   >   
   >  : foo ( ... -- ... )   
   >    ... not ... ;   
   >   
   >and the library contains   
   >   
   >  79-standard   
   >  : bar ( ... -- ... )   
   >    ... not ... ;   
   >   
   >you want the use of NOT in FOO to be statically bound to (what   
   >Forth-94 calls) INVERT and the NOT in BAR to be statically bound to   
   >0=; you usually don't want BAR or FOO to change its behaviour   
   >depending on which standard is selected.   
   >   
   >>But I think maybe, just maybe the same effect could be achieved by using   
   >>wordsets.   
   >   
      
   [continued in next message]   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)