Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: Essence of Forth Message-ID: <7516@sdcc6.ucsd.edu> Date: 17 Feb 90 03:10:53 GMT References: <9002161546.AA19812@jade.berkeley.edu> Organization: University of California, San Diego Lines: 128 Mitch Bradley writes: # > ... Forth's confusion about strings, and the possibility of defining # > your own strings package ... # # The argument that "you can define your own" is often cited in defense # of Forth's lack of particular features. However, many people do not # wish to have to "roll their own" this and that. Perhaps they do not # have the skill. Perhaps they do not have the time. Perhaps they would # rather concentrate on their application without having to build up # the tool base by themselves. Having well-debugged, optimized, supported # tool packages (e.g. strings) can save application developers time and # money. Given the choice between "rolling your own" and buying, the # "buy" decision is often economically sound. This may be a significant breakthrough in rather protracted exchanges. It indicates a major misunderstanding of what I had always assumed was a well-understood point. The issue is NOT that Forth programmers do not want features -- the issue is how features should be provided and whether they should be built in or not. The most significant feature of traditionally implemented Forth is that F1) the *user* has access to the implementation in a way that in most languages is reserved to the specialists who implemented the language. F2) the implementation is simple enough for the *user* to make use of the access. F3) the "compiler" is extensible -- so that features that would normally have to be incorporated into an (inaccessible) compiler can be introduced as additions by the *user*. There are several rather enormous benefits to this: B1) The user only needs to incorporate language features that are actually needed. B2) The user can select from a variety of variants of a feature to choose the one best suited for an application (this particularly is important for memory allocation schemes, string packages, etc. where there are definite tradeoffs between extent, size, execution speed, etc.) B3) The user can modify a package implementing a feature to suit his needs. [Please note (to Doug Philips and others) that I am talking about access to the *implementation* not just to the *hardware*] Forth programmers are not necessarily cave men who plan to build everything from scratch. An argument that Forth programmers are insisting upon "rolling their own" misses the point. The point is that the Forth language is capable of allowing people to ADD features rather than build them in -- and that retaining whatever is responsible for this capability is more important than encrusting Forth with someone's idea of desirable features. There is a big difference between a situation in which portable feature packages can be purchased or written and will run as add-on's to anyone's Forth system -- and a situation in which features must be supplied by a vendor because the underlying Forth (as defined by the Standard) is too weak to support them as additions. Forth standards should define a nucleus capable of supporting string packages, memory allocation schemes, etc. as portable add-ons. The nature of Forth makes this feasible -- and the definition of the nucleus should be powerful enough to support it. This, rather than quibbles about whether 1 or -1 should be used for TRUE, is my main concern with the ANSI effort. It simply does not answer to say that the ANSI team has spent hours of effort building in the features that people most seem to want. The real question is whether it is spending hours of effort to make sure that the nucleus of the language can (as it has in the past) accept these features as portable additions. I will, like many others, buy optimized and debugged tool packages -- but when it comes to distributing work that I have done, I'd like to know that the power of the core language has been retained -- that what I have done (on the level of difficulty of some of these tool packages) in XYZ-Forth will also run on ABC-Forth. This, rather pragmatically (or "ad hoc") is my bottom line. I don't know how to make this any clearer -- but the issue is not about "people who want to roll their own this or that", it is about making a Standard which preserves Forth's ability to let people roll their own, add their own, buy their own, or modify their own AS THEY CHOOSE. I can also put it as an economic issue: Borland can afford to make its Turbo-X languages as eccentric as hell, because more people will buy Turbo-X than program in all varieties of Forth put together. Turbo-X will be its own standard. If you write in Turbo-X there will be so many other people who do too that you won't worry that your Turbo-X programs don't run on Microsoft-X. (I should mention that, in most cases, Borland has actually been fairly conventional -- but in other cases not.) NAME ME THE FORTH VENDOR WHO WILL BE THE BORLAND OF FORTH. Failing that, we can standardize Forth to the extent that a package written for one vendor's Forth will run on any other vendor's Forth. In this way, a (second party) author of a package (who deserves a just reward for the time it takes to write a professional optimized and debugged package) will be assured of adequate compensation. It will also be possible for a teacher to produce a future generation of Forth programmers and users. He will be able to say in 2 minutes how a certain word acts -- knowing that we have finally agreed on a complete and powerful set of core words. He will no longer have to explain the differences between the '79 tic and the '83 tic or how WMB-Forth differs from YUK-Forth. And he will not have to mention, as a footnote, that there are ANSI standards for Forth, but no one really uses them because they are not adequate for writing substantial programs. Forth should be a relatively easy language to standardize -- the kernel needed to support the features we are talking about is relatively small. That's all we need to agree on. [Note to Mitch Bradley: If your memory allocation package, file package, string package (do you have one?), etc. cannot be written in the Standard core vocabulary, then pester people about the core. In return, I'll grant that a floating point package must be an Extension.] John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093