DAVID@PENNDRLS.BITNET (07/14/90)
I think having the standard say "'\' is guaranteed to work thus-and-such over the following range, and the rest is implementation dependent, but 'xx/MOD' and 'yy/MOD' (I forget the names) are available and work like this . . ." is a wonderful compromise, and one you probably couldn't get away with in any language but FORTH, where adding words to the language is so easy. The reason I think it is wonderful is the compromise between not breaking current code (eliminates one straw man against implementing the standard as an extension of an extant FORTH system) and allowing new programs to be written in a highly portable fashion. Several years ago I was involved in a program development project for a program that was to run on two rather disparate platforms: an IBM 370 family processor and an IBM PC/XT. After careful examination of the available language compilers for both platforms, we selected C as the only language with which we could solve the problem that had a sufficiently robust PC implementation (at that time). We were also encouraged by C's claims to portability. Some of the things that gave us the greatest problems with portability were exactly those things that were left implementation dependent. The two that come to mind are whether or not CHAR was signed or unsigned and just how big an integer was. My memory is a bit hazy, but I think ANSI solved the first one by fiat and the second one by allowing you to use SizeOf in a conditional compilation expression. Specifying whether or not CHAR was a signed type actually did break code, since complying with the standard meant changes in the behavior of old code run through the new ANSI compliant version of a given vendor's compiler. In fact, it was a real good thing we were trying to write portable code, because when the PC vendor went ANSI, we had to fix the (carefully isolated) routine that handled the two possible cases for CHAR. If the assumption about CHAR had permeated our code, we would have been stuck. (Actually, in this case the vendor had a compiler option to go back to the old behavior, but I doubt they'll keep that in forever!) What the FORTH TC is trying to do avoids this problem. A vendor can make an ANSI compliant version of its FORTH, a version fully capable of running new, portably written programs, but one that will still run, *UNCHANGED*, code that ran on the pre-ANSI version of their FORTH. Given the ANSI standard, if you need to write a portable program, you use the words that are specified to have the effects you need. If your program does not perform division of negative numbers, you can happily use '\'. But if you do, and the exact nature of the results is important, you use one of the new operators. Without the ANSI standard, THERE IS NO WAY TO WRITE SUCH A PROGRAM SO THAT IT WILL RUN ON 'EVERY' FORTH. With the ANSI standard, you can write a program guaranteed to run on any *compliant* FORTH, no matter how that vendor has been doing (e.g.) division since time immemorial (which is how his '\' *still* does division). If you don't want to write portable code, *NOTHING CHANGES*. The vendor can be ANSI compliant, but *YOU DO NOT HAVE TO USE THE NEW ANSI WORDS*. Finally, since we are dealing with FORTH here and not some monolithic compiler, it may well be quite practical for a vendor to have two versions of its FORTH: one fully compliant (and perhaps a little less efficient and a little bigger (perhaps)), and one fully optimized for its established customer base that is not interested in portability. It sounds to me like the TC is trying hard to allow the vendors to allow us to write portable code without forcing the vendors to break current code while doing it. The portable code may have to use some funny words (but, hey, : / SM/MOD ; works wonders for that :-), but there is not one common language where writing portable code is not ugly in *SOME* fashion, when it is possible at all. -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU) P.S.: John, a better toolshop (and some good tools!) is a wonderful idea. But we've got a non-conformant reality to deal with. Legislating something desirable *NEVER* makes it happen, and often slows it down. I think *portable* FORTH is more important than improving the FORTH toolshop in the current context, and a whole lot more practical. If you want a better toolshop, the best way to get it is to make it, possibly with the help of some friends, and then see if it is good enough that other people will adopt it. That's what Chuck did, after all! P.S.S.: Standard or no standard, there will always be as many versions of FORTH as there are FORTH programmers. Maybe *that* is the essence of FORTH! :-)
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
In <9007161459.AA12996@ucbvax.Berkeley.EDU>, DAVID@PENNDRLS.BITNET writes: > I think having the standard say "'\' is guaranteed to work thus-and-such > over the following range, and the rest is implementation dependent, but > 'xx/MOD' and 'yy/MOD' (I forget the names) are available and work > like this . . ." is a wonderful compromise, and one you probably > couldn't get away with in any language but FORTH, where adding words > to the language is so easy. I agree and for the reasons you stated. > Some of the things that gave us the greatest problems with portability > were exactly those things that were left implementation dependent. > The two that come to mind are whether or not CHAR was signed or > unsigned and just how big an integer was. The value of knowing that something is Implementation defined is in knowing that you had better be very careful in using that something. Whether or not CHAR is signed doesn't effect its use for storing printable characters. It does effect what kinds of small integers you can stuff into it, but that *is* implementation dependant unless you are very careful. The point is not that CHAR should or shouldn't be unsigned, the point is that you need a red-flag to tell you that it is a potential problem area. > If you don't want to write portable code, *NOTHING CHANGES*. > The vendor can be ANSI compliant, but *YOU DO NOT HAVE TO USE THE > NEW ANSI WORDS*. It seems that this point is being made over and over again, but there are some that don't accept it. For those of you that don't, *reasons* would go a long way to generating more light than heat. If there are flaws with this kind of reasoning, then point them out. > P.S.: John, a better toolshop (and some good tools!) is a wonderful > idea. But we've got a non-conformant reality to deal with. Legislating > something desirable *NEVER* makes it happen, and often slows it down. > I think *portable* FORTH is more important than improving the FORTH > toolshop in the current context, and a whole lot more practical. > If you want a better toolshop, the best way to get it is to make it, > possibly with the help of some friends, and then see if it is good > enough that other people will adopt it. That's what Chuck did, after > all! I'm curious to know what John's reply to this is going to be. :-) -Doug ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu