REEVES@VANDVMS1.BITNET ("Terry W. Reeves") (10/30/90)
I have read a number of messages recently attacking compromises the ANS
Technical Committee has made in order to produce a standard. The most recent
concerns VOCABULARY. Before that it was / and MOD. Before that it was ....
I personally support these compromises. While they may not always be the
best solution available by any given group's criteria, they do tend to solve
what I consider to be two very crucial problems. 1) They allow me to write
a program that will hopefully be able to run on a wide range of hardware
platforms with many different Forth systems while at the same time 2) not
breaking programs that have always run in the past. I have learned to detest
having to fix code that worked last week or last month or last year simply
because the underlying system changed. If I was told by the vendor of my
software that I would have to change years of software that was debugged
and working just because certain Forth words that were being used had changed
in some nontrivial way, I would at least entertain the idea of using some
other vendor's package. Therefore, if I were the vendor of some package
that had a substantial number of users, I would resist any effort create
a standard that would force me or my users to choose between a package that
conforms to the standard and one that does not. With the compromises, I
can write new code using the standard as much as possible so that it will
be as portable as possible, and I will be able to continue to run old programs
with the same package. I have heard very similar arguments from a
representative of DEC at a Computing in High Energy Physics conference at
to why they were opposed to certain changes that might be made to the FORTRAN-
8X standard. They were simply trying to make sure that old Fortran code
that dated back to the 60's would still work. They did not want to lose
those customers. As for myself, I would not want to have to change thousands
upon thousands of lines of Fortran to conform to a new standard, nor would
I want to have to support two Fortran compilers.
Terry Reevesrob@innovus.UUCP (Rob Sciuk) (11/01/90)
In article <9010311403.AA07645@ucbvax.Berkeley.EDU> "Terry W. Reeves" <REEVES%VANDVMS1.BITNET@SCFVM.GSFC.NASA.GOV> writes: >I have read a number of messages recently attacking compromises the ANS >Technical Committee has made in order to produce a standard. The most recent >concerns VOCABULARY. Before that it was / and MOD. Before that it was .... >I personally support these compromises. While they may not always be the [ stuff deleted ... ] > Terry Reeves I would also like to voice my support for the ANS group. Although I may not agree entirely with the Basis, A standard is better than NO standard. Let us not forget the `extensibility' and `redefinability' (are those words?:-) inherent in the language. If we do not agree with a feature in the ANS standard, we can re-implement the offending words in an implementation independant manner (on top of ANS) to make the ANS look like anything we want, and THEN compile your application on top. What the ANS Standard provides is a guarantee that the `onion-skin' necessary to support your old applications WILL BE PORTABLE since it is written in ANS Forth. What we can reasonably expect, IMHO, is a series of EMULATORS for Fig, F79, MVP, F83, etc etc to run on ANY standard ANS implementation. Thus ANS CAN APPEAR TO BE WHATEVER DIALECT YOU WANT --- it is the nature of Forth. Whether these emulators remain proprietary, or are offered into the public domain remains to be seen. As someone who makes a living from migrating VERY LARGE software packages written in various languages across different architectures, compilers, dialects etc. ... I do understand the desire to have applications port unchanged. Further I do understand the performance penalty which may occur with the approach I've outlined, but in this case I value portability much higher than application speed, otherwise why have a standard at all? Terry makes a good point with FORTRAN 88. Having seen a draft of the proposed standard for that language, it immediately appears that FORTRAN 77 (almost) C, Ada, Pascal, PL/1 and Algol are all legal subsets of the FORTRAN 88 (well, maybe not ALL of those ;-). FORTRAN 66 and FORTRAN IV are not. They were legal subsets of the 77 standard, and warnings were given in that standard not to use old features. FORTRAN 88 WILL BREAK FORTRAN 66 CODE BECAUSE FORTRAN IS NOT EXTENSIBLE! This is a standards effort that got out of hand! The maintainers of FORTRAN IV programs have a much bigger problem than do the Forth world particularly in light of the spaghetti like nature of the old applications as encouraged by the language itself. (Perhaps a FORTRAN IV emulator can be built on ANS Forth as well? :-) Let us not take the parochial view of whether ANS will bust my own application but rather, let us understand how ANS differs from, say Forth-83, and attempt to characterize just how to emulate the 83 standard on top of ANS for those applications which require 83. I'm sure in the final analysis, the effort required in this task will be much less than flaming the committee (and much more constructive). In his `Computer Language' column P.J. Plauger gives a detailed description of the agony of working on the ANSI C standards committee (I'm sorry I can't give the reference but it was within the last year or so). From this I gain a small appreciation of the process. My hat is off to them! I continue to support their efforts. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Sciuk rob%innovus@maccs.dcss.mcmaster.ca Innovus Inc. 204-200 James St S. Hamilton, Ont. Phone: (416) 529-8117 {not a flame ... merely a glimmer ...} Fax: (416) 572-9586 <<< Note: to avoid routing problems do not r(eply), use my address as above >>>