6.1.0750 BASE CORE

The word TO has a number of disadvantages, and many in the Forth community avoid using it.

In Forth-2012, separate getters and setters are used. For example, precision and set-precision.

As a replacement to the word base I would prefer the following interface:

• radix Execution: ( -- +n )
  • +n is the current radix (base) of number conversion.
• set-radix Execution: ( u|n -- )
  • if u|n is not in the range {2..36}, an exception is thrown (or at least may be thrown).

Note that with to it could be difficult to check the input value and throw an exception.

If base had been specified as a value (or with getter and setter) in the infancy of Forth, that would have some benefits today. However, it actually has been specified as (user) variable, and we now have established practice in both systems that implement base and programs that use base, so we cannot change base into a value.

One possible route around that would be to propose an alternative word (or words) with the preferred interface for standardization, get that standardized, then make base obsolescent, and many years later destandardize base. However, no alternative has any established (much less common) practice. And arguments about things like "exposes implementation mechanisms" are generally used (often incorrectly) when arguing against proposals, but I don't remember any proposal that was based solely on this argument that has been successful.

My point is broader than BASE itself. The issue is the language model, not the implementation. The current interface requires programmers to access the radix through two separate operations involving an address (BASE @, BASE !). In other words, the programmer performs two operations where there is conceptually only one. Introducing a direct interface would simplify the programming model, not merely optimize an implementation.

When designing a new language, such things should be taken into consideration. And in a new language, I would avoid global/user state like base if possible, no matter how the state is accessed and changed.

But Forth is not a new language, and in its standardization important guidelines are existing practice and common practice. That is even more important for cases where existing words are to be removed or replaced. base is common practice. If you want to replace it, you have to convince many Forth programmers to use your alternative, and many Forth system implementors to implement it, and once that has happened, the alternative can be standardized. You will need to convince all Forth programmers to stop using base and to rewrite existing code to use your alternative in order to destandardize base.

An example of that is locals| and {:. {, an alternative to locals| had common practice; John Hayes published an implementation in Forth-94 in SigForth, but Stephen Pelc keeps pointing out that MPE implemented it earlier; several other Forth systems implemented { and code that I saw posted used { more frequently than locals|.

Based on the common practice { was standardized under the name {: in Forth-2012 (the name change happened due to a different existing practice of { in SwiftForth). Nobody has proposed destandardizing locals| yet (but then, if a system does not want to implement it, it can, because it's an extension word; but I am not aware of a system that implements {: but not locals|).