ZMLEB@SCFVM.BITNET (Lee Brotzman) (11/22/89)
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.
ZMLEB@SCFVM.BITNET (Lee Brotzman) (12/02/89)
John Wavrik writes: >Lee Brotzman writes: >> (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.) > >Mathematicians tend to be independently minded too -- but at some point in >history they decided to agree on the shapes used for the numerals and the base >to be used for the number system. They also agree on a set of basic >assumptions (axioms) and definitions. Without this agreement, progress in >mathematics would be impossible. The key phrase here is "at some point in history". Man was counting for thousands of years before the numerals we use today became "standard". There were many systems of lines, curves, and dots to describe quantities. Each was sufficient to perform the job at hand. The Roman numeral system is only useful for quantities numbering in the few thousands. In Roman times, who needed to count farther than that? Would it have been a good idea to freeze the standard at that point? There is by no means a standard means of denoting numbers today, either. The representation of quantities depends heavily on the application. When writing on paper, a circle can represent zero. In a computer, a series of transisters in a low voltage state represents zero. The same quantity -- two quite different applications and representations. By the same token, a Forth system destined for a small ROM chip might prefer to use indirect threading because every byte counts, while a Forth system on a VAX may be best suited to subroutine threading because of speed considerations. This doesn't mean that a Standard should only be defined for one and not the other. > It would not be considered creative in >mathematics to change the shape of 8 (arguing that a different shape would >allow us to write it more quickly) or to suggest that we change the number >base from 10 to 12. And it would be total disaster to leave such foundational >things "implementation dependent". The foundations on which we agree are >highly portable and are extensive enough to support the superstructure of the >subject. Lots of independent minded people have made contributions to >mathematics without feeling stifled by sharing a common language and a common >set of basic assumptions on which to build -- they show their independence at >a higher level. Mathemeticians, like good programmers, make use of "information hiding". The axioms you mention are not stated in terms on numerals alone, but have other symbols (e.g. greek letters) which represent a class or special quantity. These symbols are also "implementation dependant". When an astronomer refers to right ascension and declination (a form of celestial coordinates) he uses the greek letters alpha and delta. Delta can have a very different meaning when used in a differential equation. (I almost washed out of a Diff. Equ. course in college because the professor preferred his own system of notation to that in the text.) Mathematical notation isn't standard. Most papers have a set of definitions to describe which symbols mean what. This is analogous to documenting implementation dependant features. Axioms are "truths", not just ideas everyone thinks is a good place to start. Theorems can be proven by applying the axioms. Your analogy simply doesn't apply to the question at hand: annointing a single Forth architecture as the only Standard one. There is no single architecture that is better than all others. To state otherwise is only opinion, not truth. > >There is an historical precedent for what I am suggesting. About 10 years ago, >a group of independently minded programmers decided to make a new language >available to the general public. They implemented their model on about a dozen >of the most popular processors of the time. Most people who got past the >unconventional nature of the language found it almost supernaturally powerful. >(Much of the supernatural power derived from the fact that the implementation >was part of the language.) It was also supernaturally portable: the main >barrier to getting code written on one computer to run on another was getting >the code transferred (modems were rare and expensive at the time). I presume that you are referring to FIG Forth here. The FIG model was precedant setting, but is no longer in widespread use. It has been quite a while since I used FIG Forth, but I believe that even it had certain implementation differences between processors. Let's get back on track here. You have stated that the standard should identify one architecture, specifically a threading scheme, and stick to it. Could you please supply us with your choice and a supporting argument for excluding any other implementation from acceptance? Also, should all other architectural design features be rigidly specified? I'm referring to the size of a stack element, the allowable fields and format of word headers, bit-ordering in integers, floating point representation, permissible address space, character codes, whether Forth runs as an operating system or through the services of a host operating system, etc. The current ANSI Basis Standard is designed so that nearly all of these "implementation dependant" features can be used transparently across all systems, even though the underlying architectures may be wildly different. You said yourself that "you do not add power to a language by removing some of its features and declaring them to be 'decidedly non-standard'." The ANSI TC has added a lot of power to the Forth 83 standard, especially by lifting the hard-coded 16-bit stack element size and adding standard sets of floating point and file manipulation words. Declaring a feature "non-standard" doesn't remove it from the language, it only serves to mark a place where the specific design of a system may cause problems when porting code. These areas are explicitly described as completely as possible in the Basis. I think that the ANSI TC is being quite responsible in their efforts to make the Standard as encompassing as they can while at the same time taking care not to break a hell of a lot of Forth code. Forth, like all aspects of electronic computing, is still in its infancy. There is a lot of room for growth. Perhaps in a few thousand years, Roman numeral Forth and Arabic numeral Forth will finally consolidate on a single, perfect solution. Until then, it's just too much fun looking for the ultimate Forth to call an end to the search. > > 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.