1.0, is glad to see Delta honoring its early advertisements.
JForth has its quirks, some apparently rooted in the collective personality of the Delta team. While JForth is advertised as "Forth 83 Standard". This is an impossibility. The 1983 Standard (unwisely, in many opinions) defined Forth in terms of 16 bits. A 32-bit Forth cannot be 83-Standard, though it may resemble the standard quite closely from the programmers point of view. Further, philosophical differences between Delta and certain trends of the Forth 83 Standard led to some anomalies: NOT in JForth is a logical Boolean NOT instead of the bitwise NOT prescribed by the 83 Standard. Division is floored to zero (0) in JForth, instead of towards negative infinity, which is the 83 Standard. The familiar division operator UM/MOD is missing and is replaced by U/ which operates in a slightly different manner. Delta Research has not been alone in its conflict with the 83 Standard. The world's largest Forth vendor, FORTH Inc., has never totally reconciled itself to the 83 Standard. The question may soon be moot. The Forth language is in ANSI X3J14 procedure right now, and if anything may be gleaned from the BASIS documents leaking out from the committee, the ANSI Standard Forth to emerge in 1990 or 1991 will contain radical departures from the 83 |
Standard, which later was very heavily tilted towards 16-bit micros.
In any event, the Forth standard is currently undergoing revision at the ANSI level to deal with the problems vendors faced as Forth grew beyond the horizons envisioned by the 1983 Standards committee. As a rooter on the sidelines of the current Standardization effort, it is my observation that JForth substantially conforms to the functionality of the still-evolving ANSI Standard BASIS. Some of the observed anomalies in JForth are addressed by the JForth loadable multi-standard package which allows the programmer to go back all the way to FIG Forth if desired, but anyone intending on porting code from other Forths should be aware that the old saw, "If you've seen one Forth, you've seen...one Forth" is not ready for retirement quite yet. Experienced Forth programmers will have mixed feelings about the absence of local multitasking in JForth. Phil and Mike feel local multitasking is inefficient on the Amiga; they recommend using the Amiga Exec facilities for spawning child processes. Your correspondent favors the syntactic convenience of Forth-style local multitasking and hopes to prevail upon the Delta gang to hook up all the stubs they purposely left in the kernel for local |
multitasking Those stubs include full implementation of local variables, and make it possible for the programmer to install local multitasking on his own! I may try it Real Soon Now.
However, not one of the quirks of JForth renders the system unusable or even difficult to use. Forth prograrmners just tend to be eccentric and opinionated (talk to me sometime), and the Delta gang is no exception!
Most important, I cannot envision a more suitable environment for programmers unfamiliar with the Amiga system resources to pleasantly and efficiently explore the intricacies of the Exec-Intuition-AmigaDOS universe. The value of the interpretive
layer, combined with the compact syntax of Forth and the blazing execution speed of JForth, should not be taken lightly by Amigans nor professional Forth users.
Autbor's Info Jack Woehr is a Forth programmer at Vesta Technology, Inc. in Wheat Ridge, CO. He is Chapter Coordinator for the Forth Interest Group, and host of the Forth Conference on the WELL in Sausoltto, CA. Mr. Woehr is also Sysop of the RealTime Control & Forth Board, which ts part of the CFB Forth Network. |