Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: Forth in C (was Re: Forth from scratch) Summary: virtue of traditional implementation Message-ID: <4969@sdcc6.ucsd.edu> Date: 9 Nov 89 20:05:48 GMT References: <4839@sdcc6.ucsd.edu> <2570@fai.UUCP> Organization: University of California, San Diego Lines: 92 kurtl@fai.fai.com (Kurt Luoto) writes: > .............. Some might call it a toy implementation, > but it gave me the ability to exploit the power of Forth on a machine that > otherwise only had C. I did "real work" with it, stuff that helped save > time and effort on my projects. Does that qualify it for non-toyness? > Now I'm an assembly hacker at heart and, having done realtime/embedded > systems programming for most of my career, I can appreciate the need for > efficiency and machine-level access for many applications. But I don't make > the mistake of assuming that all applications are like this. There are two things at issue here: the definition of "toy" and the reason that an assembly language implementation is desirable for Forth. Let me deal with the second issue first. Because Forth is close to the architecture of the host processor (and includes an assembler) it does have the advantages Kurt Luoto notes (it is good for projects which require machine-level access and for projects which require efficiency). But it is a mistake to assume that these are the primary reasons for implementing Forth in the traditional way (using a little assembly language and a lot of Forth). Traditional Forth implementation is so simple that it is easy to add new features to the language -- new primitives, control structures, data types, etc. What would you like: quadruple precision integers? complex numbers as a primitive data type? graphics? strings? local variables? arithmetic of sets? A construct "IF: COND1 COND2 COND3 ... DO:" that tests for a conjunction but will stop testing as soon as a condition fails? redirection of I/O? It is one thing to say that a professional compiler writer can build these things into a language -- quite another to say a language allows such things to be added by typical users. The ability of a USER to add to a language almost anything one could conceive of is a rare attribute. It is this extraordinary degree of control (rather than the use of stacks and RPN) that characterizes Forth -- and it comes from the simplicity and accessibility of Forth implementation. Forth (when implemented traditionally) is more than just a rather small interactive stack-based language with Reverse Polish Syntax. To make matters more concrete, suppose a Forth implementation lacks certain primitive words involving double precision numbers (D+, D-, */, */MOD, etc.), lacks a desired feature (like access to the OS timer) and has some errors in the implementation of one or two primitives. A typical Forth programmmer using a traditional Forth system can readily add the words (they have short definitions in assembly language), provide the features, and fix the bugs. How is one to characterize a Forth implementation that does not allow a user the ability to add new primitives to the language? Or to tap features of hardware and OS to do such simple things as adding a timer or redirecting output to a printer or file? By imbedding Forth in another language this is exactly the situation that seems to be produced. New primitives cannot be added (or existing ones modified) from within the Forth environment without knowledge of how the program and compiler handle register assignments and stacks. They only can be added outside the Forth environment by someone who knows the implementation language and has access to (and understands) the source code for the implementation (most likely the implementor and not the user). Most people never miss what they don't know exists -- so it is no surprise that people who come to Forth from other languages will accept a version of Forth which is as static and rigid as a 'C' compiler. To someone accustomed to compiled languages, an interactive environment can be quite an experience -- and there is no doubt that even a limited version of Forth can do useful things. To call something "toy" does not mean that it is not useful -- it means that, in comparison to a non-toy version, it lacks both important characteristics and the means for obtaining them. (Thus a soap-box racer is a "toy" car, but a child is not a "toy" adult). Forth would be a "toy" language were it not for its ability (at least in traditional implementations) to accept important features as optional add-ons and to support almost unlimited modification. Let me emphasize again that it is not speed or the ability to do hardware control applications that is the main argument for the traditional implementation of Forth. It is the resulting simplicity and accessibility of the implementation -- making the language malleable, allowing a user to exercise a high degree of control and to add powerful features as options. One of my differences of opinion with my friends who speak Forth as a second language is how to best introduce Forth to speakers of their first language. Their idea is to package Forth in a form that natives will find familiar and comfortable (even if it means giving them the "look and feel" without some of the substance). My idea is to confront new people with a version of Forth that challenges rather than supports pre-conceived notions about programming languages. I want them to meet Forth on its own terms. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093