philj@tekig5.PEN.TEK.COM (Phil Jansen) (09/17/88)
In article <26098@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: . . . >In Forth, you can [use "+" to add complex numbers], >but you have to use a special version of "+" that lives >in a different vocabulary from the integer "+" and you must explictly >tell Forth to switch vocabularies. Since forth does not automatically >keep track of the types of operands and automatically insert type >coercion operators, you'd have to write something like: > A @ FLOATVOC B @ INT->FLOAT + FLOAT->COMPLEX COMPLEXVOC C @ * >much more cumbersome and error prone. (Note that I have to explicitly >switch vocabularies to get floating "@", and again to get complex "@". Note that if you define your variable B to change vocabularies for you when it executes, the switch is transparent. You can even have the vocabulary only include the functions you want that type to have! Find a copy of _Object-Oriented Forth_ by Dick Pountain. (Copyright 1987, Academic Press Ltd. ISBN 0-12-0563570-2 Unfortunately, the book is out of print, but I found it in our library.) The book describes records and abstract data types, etc. in Forth. The implementation Pountain comes up with will do the type checking you want. . . . >[Forth doesn't handle automatic single -> double conversion on overflow,] >[ or bigger than double if necessary, etc.] Sorry, the book doesn't cover these things. The advantage is that the extensions the book *does* cover take up less than 4k. (The book is only 119 pages, but the ideas are really thick in there.) . . . >LISP is type safe: if the compiler doesn't know the types, they'll > have to be checked at run time. > You can extend the domain of the built in operators like "+" to > handle new types. You can set up the system to detect and do > something reasonable on overflow. ... >Forth is chaotic: if the programmer accidently applies an operator to > inappropriate arguments, he is screwed. ... >--- David Phillip Oster Usually true, but these extensions should help prevent that. Maybe if enough people read this book, the extensions will become standard? Nah, never mind. (LISP may handle types better, but Forth doesn't *have* to be awful) Come the Revolution, all languages will be perfect for everything. -- Phil Jansen If you repeat things often enough, they become true. philj@tekig5 If you repeat things often enough, they become true. If you repeat things often enough, they become true.
XRBEO@VPFVM.BITNET (Bruce O'Neel) (09/20/88)
As another reference, the May and June issues of Computer Language Mag have articles by George Shaw about multiple code field words which can give you operator overloading. The basic idea, as I understand it, is that @ doesn't do a standard fetch, it just moves to code field n and executes it. What that does it give you different actions for different types of variables. If you said the variable was a floating point variable you actually fetch a floating point number. If, on the other hand, it is a double variable, then @ fetches a double number, and so on. bruce