dwpst@unix.cis.pitt.edu (Douglas W Philips) (08/31/90)
In article <9008291905.AA11250@ucbvax.Berkeley.EDU> Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes: >We could design a new language that fixed this problem and other problems >with Forth. >Would it succeed? Almost certainly not. >Viewed in this light, I think that trying to design a new Forth-like >language is an utter waste of time. From a practical standpoint, we >should be trying to nurture Forth, patching over its faults as best >as we can. That is what I feel that I am helping to do with my >participation in the ANS Forth effort. I think you have a valid point. In trying to get at the best of both worlds... Do you (plural you) think that building a clean Forth kernel, onto which one can build existing Forth words, is a viable solution? To paraphrase the attitude of "fix it only", but perhaps erroneously: One may only add more and more on top of Forth. Given the current diversity of implementations such as: (indirect threaded, direct threaded, subroutine threaded, whole or split dictionary headers, etc.) creating new diversity such as a cleaner postfix kernel from which the traditional Forth words are built is creating a new language? Perhaps the best approach would be to build and release a Forth which was built that way and not fret about whether it is a "new language" or merely an acceptable variant or an acceptable implemention alternative? I agree with your premise that making a new language will flop. My question is what actually constitues a new language? (i.e. How have CM's various Forth implementations changed over the years? Are or aren't they all "Forth"? Does your answer depend on whether or not it CM is the author of those systems?) -Doug