Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: Forth Implementation (long) Summary: reply Keywords: Forth implementation Message-ID: <5224@sdcc6.ucsd.edu> Date: 18 Nov 89 04:18:36 GMT References: <5172@sdcc6.ucsd.edu> <5599@eos.UUCP> Organization: University of California, San Diego Lines: 95 jbm@eos.UUCP (Jeffrey Mulligan) writes > Isn't having a special word "D+" for adding doubles (instead of using "+") > equivalent in a sense to having a special function long_add? > You made a point in the C example of pointing out that the compiler > has to be able to add double precision to single precision integers; > Does this require yet another forth word, or do you have to do it > as a series of two operations, a type conversion followed by D+ ?? Part of understanding Forth involves understanding that, as an interpreted language, it is forced to make certain decisions at run time which a compiled language can make at compile time. [Forth is actually in the same class as APL, interpreted BASIC, and interpreted LISP. The fact that Forth runs a few orders of magnitude faster than these is a tribute to Charles Moore's ingenuity at selecting what should be done by the language and what by the user.] In any language implementation, the process of adding two floating point numbers (to take an extreme) is different from the process of adding two integers. These are really two different operations. If, however, the language has you declare the types of the variables a compiler can decide which operation to perform when the code is compiled (rather than each time it is executed). In a compiled language, therefore, "+" is in a position to know in advance which type of "+" you have in mind. In Forth a "+" imbedded in a word has no way of knowing what type of things will be on the stack when the word is executed -- so using the same symbol for a variety of different addition operations would require a determination of type each time it executes -- obviously inefficient. The Forth solution is to have the programmer decide on the type and use a different symbol for what really are different operations ( + for integers, D+ for double precision, F+ for floating point, etc.) If a b c are on the stack, a + b * c is computed by * + if a b c are integers D* D+ if a b c are double precision F* F+ if a b c are real so all the types are treated using the same syntax. (Notice that my example doesn't involve any stack manipulation -- John, you devil!) In Pascal we would do x := a + b * c using integers. But if we use functions to add a new type, we would have to do, at best: x:= type_add(a,type_mult(b,c)) Syntactically this is quite different. It gets worse if the new type is a component of another type. Pascal does not provide for "addition of records". Thus if we make complex numbers (or whatever) a record type we will never be able to say z := x + y for complex numbers. Pascal does automatic coercion on its built-in types -- so if you ask a floating point to be added to an integer, it will automatically convert the integer to floating point (and then apply floating point addition). [Forth requires the programmer to specify any type conversion necessary just as it requires the programmer to decide on which addition is needed.] Forth requires the programmer to make decisions that would be made by the compiler in other languages -- this is the price that Charles Moore decided we should pay for having a fast interactive language. (editor's note: actually the decisions are obvious ones -- like what kinds of things we intend to add). The claim can be made that new types can be added to Forth in a way, both syntactically and sematically, to have the same status as "built in" objects -- in this way we claim that we have done the equivalent of "extending the compiler". Pascal, on the other hand, the compiler has been "taught" to treat its built- in objects in a certain way -- new objects can be added, but they are treated differently -- there is no realistic way to retrain the compiler to make first-class citizens out of these second-class citizens. The example in my last note suggests, and the responses confirm, the following: If someone sends you source code that your Pascal compiler has not been "taught" to recognize, you will have to alter the source code. A Forth programmer in a similar situation would alter the "compiler" and leave the source code untouched. (Philosophical comment: If things which are not taught to your compiler are treated in a different (and uglier) way -- you want a compiler which is as fat as possible. It should allow you to select from things that you may or may not use. If you can add anything you want without penalty, you want a system which is slim and understandable. Fat systems are hard to understand. You'd rather have the power to create anything you need. "Thin and powerful" vs. "Fat and ugly" -- it's the Forth difference) John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093