Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SCFVM.BITNET!ZMLEB From: ZMLEB@SCFVM.BITNET (Lee Brotzman) Newsgroups: comp.lang.forth Subject: Standards and Portability (was Re: Some Code) Message-ID: <8911221536.AA24445@jade.berkeley.edu> Date: 22 Nov 89 13:39:48 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 123 John Wavrik writes, >Tom Almy writes, >> It's sad but true -- to get the best results with Forth you have to >> throw portability out the window. > >That's only because we've made some bad decisions about what constitutes >the language -- but fortunately we have a chance to rectify these mistakes. > >I think that the use of implementation details in Forth is the subject of >dishonest controversy... > >> ... The problem, if >> indeed there is one, is that this sort of program plays around with the >> internals of Forth, and the internals are decidedly non-standard. >> Unfortunately, if these details were to become part of the standard then it >> would inhibit better implementations. > >Please let's distinguish things like the use of assembly language or features >of the host processor from "the internals of Forth". A Standard COULD be >proposed in which implementation details are specified (the FIG model was of >this type) and then these details WOULD be standard (and portable). A >decision to declare such programming "non-standard" is made by a committee of >human beings, not forced on us by our computers. It's quite a reasonable idea >to take a look at that decision to see if the reduction in power of the >language is a price worth paying for baptizing a variety of deviant >implementations. > >If you give people a "compiler" that they can modify, guess what they will do. >There is no problem with someone producing a private version of Forth that >they feel is "better" for them -- and many people do just that. It is quite >likely that some of the most important applications of Forth in the past 10 >years have been written using "non-standard" versions of Forth. I don't think >that Standards inhibit people from experimenting with the language. The issue >is more what can be done powerfully and portably. You do not add power to a >language by removing some of its features and declaring them to be "decidedly >non-standard". > I'm not a member of the ANSI Forth Standards Committee, but I have had some experience with that committee. If what I say is contrary to the actual Standards efforts, I ask that a ANS TC member correct me. The ANSI Standard (and the previous Forth standards, as well) make a distinction between "Standard Systems" and "Standard Programs". The above discussion seems to have blended the two concepts. The Standard sets down criteria for qualification of Standard Systems such as the required word sets and extension word sets, but there are also specifications for required documentation and labelling. The Standard specifies what should be done but not *how* while at the same time saying that the "how" must be documented by the implementer. This is as it should be. (Let's be realistic: do you really think a requirement for specific internal design would be adhered to by one of the most independantly minded programming communities in existance -- Forth programmers? Any such Standard would be dead on arrival.) Standard Programs also have to meet certain criteria such as avoiding some implementation dependant features. The points of implementation dependance are (or should be) clearly marked in the Standard. The Standard does not stipulate that non-portable code can not be created with a Standard System, only that such code can not be labelled and marketed as an "ANSI Standard Program". The issue of portability is part of standards, but not wholly encompassed by it. Standards issues are a proper subset of portability issues, not vice versa. I have never experienced any language implementation -- Forth, Fortran, Pascal, C, etc. -- that is completely and without question portable to another implementation of the same language. All have implementation dependant features over and above the underlying Standard. Now, when I write a program in, say, IBM S/370 Fortran 77 and stick to only standard features, I can be reasonably assured that the program will compile and run under VAX VMS Fortran 77. But if I use some of nifty add-ons provided by either of those compilers (i.e. if I use knowledge of the implementation details), I might be in for some trouble when I port the code. Since the Standards require documentation of non-standard features, I can avoid or use them if I desire. Forth is by no means the only language that has some characteristics that depend on internal design, nor can it be made otherwise in a universally acceptable way. The Forth Standards Team should be commended in their efforts to determine and label anything that would cause someone to encounter portability problems. They have done a pretty good job at specifying most of the Standard so that implementation-specific details are kept to a minimum across disparate hardware platforms. Considering that Forth programmers are as close to the hardware as a high-level programmer can get, this is an impressive feat. >Forth has been in existence for about 20 years -- readily available for about >10. During that period of time, we may have learned some things about how to >improve its implementation. (I think a good case can be made that as much time >and effort have been spent in experimenting with the language's implementation >as in actually doing something with the language.) At this point we should >take stock of what we have learned and embody that in a new Standard. If it is >decided that direct threaded code actually produces major performance >advantages over indirect threaded code, then the new Standard should specify >direct threaded code. If we decide that floored division is preferable, then >the new Standard should specify that. Instead we have a situation in which a >vocal group says we should drive on the left side of the road, an equally >vocal group which says we should drive on the right -- and a Standards team >which declares the issue to be "implementation dependent". If it were only that simple. The decision about which threading scheme gives the greatest performance depends almost entirely on the situation. What might be best for some might be horrible for others, and there is no one method that clearly outshines the rest (or we all would have heard about it by now). Like I said, some implementation dependance is unavoidable. A Standard that specifies the internal implementation might as well go ahead and specify the hardware, host operating system (if any), and tasks to which Standard Forth can be applied. Another factor is cost of compliance. Clearly, since no one threading scheme dominates the market, a choice of one will render obsolete a very large fraction of existing systems and programs. Forcing a change of internal design would be much too expensive. Let me sum up. A Standard can not ensure 100% portable code, but it should at least define a set of bounds within which maximum portability is maintained. A Standard is meant to define and reconcile "common practice" not to improve a language. A Standard should apply to the widest possible range of situations, but recognize the fact that it can not apply to EVERY situation. And finally, a Standard must specify "what" not "how". > > John J Wavrik > jjwavrik@ucsd.edu Dept of Math C-012 > Univ of Calif - San Diego > La Jolla, CA 92093 -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM -- Internet: zmleb@scfvm.gsfc.nasa.gov -- The government and my company don't know what I'm saying. -- Let's keep it that way.