ir230@sdcc6.ucsd.edu (john wavrik) (09/07/90)
Mitch Bradley writes, > You used to create (etc. etc.) using your *implementation dependent* > access to the IP, etc. ANS Forth won't make these techniques portable, > but neither did it create the existing portability problem. > > Like it or not, these techniques have never been portable except among > selected subsets of Forth systems. Even in the halcyon days of FIG Forth, > there were other Forth implementations that did things differently. Mitch Bradley's experience with Forth has been quite different than mine, and I do not contest the validity of his experience. Mine has been using a variety of Forths on a variety of computers all of which worked in essentially the same way. I admit to being isolated -- so much so that I was taken aback when a colleague refused to even consider Forth for a project because "its not portable". Of course, I'm not the only one who has been isolated. The two textbooks that I have used for my courses are Brodie's "Starting Forth" and Kelly and Spies' "Forth: A Text and Reference" -- both are considered Forth's leading textbooks -- and both describe how Forth works in exactly the way it has worked on the machines and implementations I have used for the past 10 years. The code I've written is pretty consistent with what is found in the major textbooks, Forth Dimensions, etc. It uses, in a pretty traditional and common way, an understanding of the virtual machine to substitute for built-in features. (The most outstanding contribution of Forth to computer science is to show that power derives from building the language around a conceptually simple virtual machine.) While writing this I came across a parenthetical note in Kelly & Spies (at the point where they describe what is in the code field). They say: "(Actually, the use of the code field that we have described, although by far the most common, is that of what is called indirect threaded code. There are other possibilities, but they are not commonly used.)" [written 4 years ago] I really don't think it is a quibble to say that Forth as I've experienced it is actually the mainstream. To say that there were other ways of implementing Forth even during the fig-Forth days actually has very little bearing on the problem. Tom Almy, several months ago, said something like "to do anything significant with Forth you have to throw portability out the window". Please note -- this is not a comment (as I understand it) about the nature of Forth, but rather what the Forth Community has allowed to happen to the language. I have an idea that there are more uses and potential users for Forth than anyone imagines. I think all this "lets find ourselves a cosy little niche where we can hide" talk is unnecessarily pessimistic. I hope I have shown (and will continue to try to show) that Forth is an excellent language for Mathematics. [I'm excited about this. Even if you have always hated math, I hope you'll read my postings. Forth can let us easily do things that are very hard to do in other languages.] But there is a catch: Portability is a language feature that is almost essential. "It's not portable" is enough to eliminate a language from consideration for most projects. (We are not talking about producing software for a client -- we're talking about using a language for collaboration -- which is how the other half of the world lives.) I see the job of the ANSI Team as identifying why people use Forth (particularly those whose needs are not met by other languages) and making sure that the necessary features are part of the new language it is building. Forget this talk about making Forth like other languages -- sell the unique properties of Forth to those who need them. If you point to something and say "you can't do that portably now" my answer is "YES, I agree with you -- that's the problem that needs to be fixed". John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093