mrkeyoor.com_
Tue 27 Oct 17:33 UTC
Open Source3 min read

Gforth 1.0 documents which extensions it intends to keep

Gforth 1.0 pairs development tools and multicore tasks with an explicit support boundary. Code that uses undocumented internals still needs scrutiny.

Gforth 1.0 is available, with release notes that document which language extensions the project intends to keep supporting. The project website, checked on October 27, lists 1.0.0 as its latest release. For developers maintaining Forth programs, the support boundary deserves attention alongside the longer feature list: finding a useful operation in the interpreter's source does not guarantee it will survive an upgrade.

Gforth implements the Forth 2012 language. Its 1.0 release notes cover changes from the 0.7.x series and explicitly warn that some entries describe previously available functionality being documented for the first time. The pages reviewed do not date the release announcement, so this article does not treat October 27 as the launch date or every listed capability as newly introduced.

Check the wordset before depending on a word

Forth calls its named operations words. Gforth's stability policy says programs that work on earlier versions should work on newer ones, with qualifications. The maintainers commit to keeping standard words and documented stable extensions. Undocumented internal data structures, including the representation of code, can change.

The manual gives a practical way to inspect a dependency: look at the wordset named in the source comment after a word's stack-effect comment. Extensions marked gforth or gforth-<version> fall within its stable categories. A word with no wordset is an internal factor that may be removed.

The labels distinguish different risks. According to the policy, gforth-experimental means supported but not yet stable. gforth-obsolete signals an intention to remove the word in the next version. For gforth-internal, or an absent wordset, removal may happen once Gforth itself no longer needs the operation. That gives maintainers a more specific upgrade check than whether their program still starts.

Development tools come with a chronology caveat

The release notes describe source lookup and searches for uses of a word, plus browsable backtraces with source locations. They also list tasks across multiple cores or hardware threads, message queues for communication and synchronization, and C interface work including callbacks. This is a documentation-based account; we did not build Gforth 1.0 or measure its execution speed.

For an existing codebase, a useful next step is to inspect dependencies on internal or experimental words before adopting the release. The maintainers invite requests to make particular unstable words stable, while reserving the option to suggest an alternative. Watch whether an operation your program needs receives that documented commitment before assuming it will remain available.

Sources

  1. Gforth project website
  2. Gforth 1.0 NEWS
  3. Stability Goals (Gforth Manual)