Re: single-xt approach in the standard

On 24/09/2024 12:45 am, Anthony Howe wrote:

On 2024-09-22 23:34, dxf wrote:

The only guidance a standard can give is on duplicating the past.  I see
no value in creating a new forth simply to do that.  As an individual one
has the opportunity to bring something new that's not merely repetition.
At the very least one can avoid repeating the same mistakes.

 
A standard does provide guidance and knowledge of the past, but also provides a jump off point for new work, new designs, new blood.
 
In the 1980's there were a plethora C compilers (tiny c, small c, sozobon c, bsd c, turbo c, watcom c, gnu c, sysv c, solaris, ...) just different enough to make portability of source code a PITA.  Similarly all the *nix variants drove a need for POSIX and X/Open (now SUS) to improve portability of software (especially if they wanted government contracts).
 
Linux came about and aimed for standards compliance in most aspects and then built new and/or improved tools that extend beyond the standards.  Now clang has come on scene looking to dethrone the megalith gcc that is a bit of portability nightmare within itself as it tries to support numerous CPUs and OSes.
 
Having an *agreed on* standard is a good thing, it helps new people learn what is portable, see/hear of pitfalls, and _then_ improve (speed, size, supported hardware) and extend.  A standard should not get in the way of that, but help.

There's no comparison between C and Forth.  Good luck taking a credible application
written in SwiftForth and compiling it on VFX.  Literally every app I write involves
a command-tail and a way to save it as a turnkey.  There's not even a standard way
to do these basic things.  So obviously lacking in pretentiousness has been the
standard one must ask whether there was ever a serious intent.  At best it's a sparse
set of words that TC's have agreed you should have and even these have proven divisive
spawning decades of argument.

Maybe - just maybe - one could write a library routine with them but would one?  Not
me.  Why would I use anything as restricted as CASE or as broken as REPRESENT ?
There's a myriad of tiny useful tools lurking in every forth no standards committee
appears to have considered: /CHAR >DIGIT >CHAR MU* MU/MOD (.) /SIGN +STRING etc on the
grounds these can be defined portably.  Sorry, I've no intention of going through the
nonsense of defining words I already have simply to give others the impression the
standard is useful.

If there's anything the standard has helped me learn is that I don't need it and
indeed better off without it.