Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ames!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: General Purpose Forth Message-ID: <17574@sdcc6.ucsd.edu> Date: 17 Mar 91 01:53:40 GMT References: <3729.27db5037@iccgcc.decnet.ab.com> <13837@medusa.cs.purdue.edu> Organization: University of California, San Diego Lines: 158 In <13837@medusa.cs.purdue.edu> William J Bouma writes, > I can program sufficiently in C given the structures which are pro > vided. In addition C provides me with a wide variety of types and > uniform ways to create new ones and deal with intermixing. > Heck, Assembly language has more "expressive power" than Forth! > Does that make it a good general purpose language? > The reason Forth has not gotten any attention is because it has > failed to keep up with the latest inovations in computer languages. > It has nothing to do with Forth's bastard-like origins. This discussion seems to confuse several things: (1) what a basic Forth system contains; (2) what Forth is easily capable of support- ing; (3) how Forth has been marketed (including the target popula- tion); (4) how Forth has been managed (or mis-managed) by the Forth community; (5) extraneous factors having nothing to do with the language itself. Forth is a high-level architecture-based language. Like assembly language, most of its primitive commands refer to an underlying architecture. It avoids the extreme machine dependence of assembly languages by being based on an abstract (or virtual) architecture. It retains efficiency by a choice of virtual machine which can be closely mapped to a variety of real machines. On the other hand, it permits hardware dependent programming by containing an assembler producing code which can be readily integrated with high level code. It is unclear what "expressive power" means when applied to assembly language. Apparently it refers to the extent of what can be expressed rather than the ease with which things can be expressed. In terms of ease of expression, assembly language is not very expressive at all. Forth avoids a preoccupation with low level concerns (which charac- terizes assembly language programming) by providing a mechanism for transcending these concerns. It also faciliates program development by providing an interactive environment. In some respects, Forth is "assembly language done right". It avoids many of the shortcomings of assembly language -- while providing the strengths. This accounts for its usefulness in areas where assembly language alone would once have been used (everything from hardware control to the implementation of language features). The discussion above stresses the relationship of Forth to assembly language. Perhaps more important is that most of Forth, including control structures and data structuring words, is written in Forth. Functions conventionally performed by the compiler are, in Forth, distributed to the language. The effect of this is to drastically alter the balance of power between user and language designer/imple- menter. It provides the user with control over the language to an extent not possible in conventional languages. It opens up a possi- bility not offered by other languages: the ability of a user to create a language designed for a particular problem area. It is also not clear why the fact that some people's needs are met by 'C' is regarded as an argument against Forth. The needs of many mathematicians are met by FORTRAN -- but this is not an argument against 'C'. Different people have different computational needs. > A language that deals only with characters and integers is a joke. Here the problem seems to be a failure to distinguish between the core language and what it supports. Forth is a toolkit for building languages. All languages are ultimately built upon the capabilities of processor chips -- thus ultimately on the manipulation of inte- gers. The versions of Forth I use on a day-to-day basis, however, all incorporate more sophisticated data types. The Forth language has been used to produce languages which deal with various types of mathematical objects. The are not languages which "deal only with characters and integers" -- but they are extensions of Forth. > Forth allows me to program at a high level, but only after I have > built a tower with a very concrete base. Having the ability to > merge a tool "seamlessly" into the language and having the tool > provided are very different things. For one, people are basically > lazy and will opt not to write their own given a choice. First let us look at the top of the tower. This is usually a problem- oriented language which is more expressive, within its domain, than a conventional language. The tower has been built to produce a language closer to the target area -- narrowing the gap between the concepts of the area and the means of expression provided by the language. The fact that the tower has a very concrete base is incidental -- in most well-designed Forth systems, concern with the very lowest level occupies only a small part of the building process (and quickly becomes transparent). By the time the first floor has been reached, the system designer is already using specialized building materials, facilitating the construction even from low levels. The idea that such a tower must be erected from its base each time is misleading. Anyone who has programmed in Forth accumulates a repertoire of parts and building materials -- so that eventually towers can be construct- ed from recycled older parts. This not only makes building easier, but it fits in well with current concern about ecology. Apparently the issue being raised here is who will build the parts. There is nothing in the Forth language that prevents people from writing tools for the use of others. It's surprising to find people who actually think that floating point arithmetic has been unavail- able to Forth programmers for these many years. During the past 11 years I have had access to floating point packages on various Forth systems -- and have not had to write one for myself. Perfectly fine strings packages have been available -- and even, for those who want it, packages for adding local variables to a Forth system. The lan- guage does allow features like this to be added to Forth systems by anyone who wants them for building a "tower". The language does not distinguish between tools written by the user and those written by others. There is no doubt that the usefulness of Forth would be greatly enhanced by a variety of building parts that could be added as options to any Forth system. Eleven years ago, Forth was on the right track: the language was probably the most portable computer language in existence. It provided (in the words of John Backus) a flexible framework which could accept powerful fea- tures entirely as changeable parts. The only thing that was missing was a repository for tested and refereed language features. The nature of the language (particularly the access it provides to its implementation) should have opened the door for the production of optional packages of various sorts that could be added (either di- rectly or modified by the user) to any Forth system. There could have been a variety of storage management schemes, methods for introducing classes of data structures, user interfaces, several levels of strings packages, etc. from which towers could be assembled. This approach would have provided a far greater degree of flexibility than conventional languages offer FOR THOSE WHO NEED TO BUILD TOWERS. Let's repeat again that the needs of many people are met by pre-built structures -- there is nothing that Forth can or should do to attract these people to Forth. > The reason Forth has not gotten any attention is because it has > failed to keep up with the latest inovations in computer > languages. It has nothing to do with Forth's bastard-like origins. A language which offers the ability to accept features as add-on options rather than requiring them to be built in should also be in an advantageous position with regard to innovations in computer languages. New ideas can be tested and incorporated into existing systems (by those who want them) without requiring new re-designed languages. The fact that the scenario outlined above (a highly portable, simple, flexible framework -- and the availability of powerful features as changeable parts) has not taken place is not a problem with the Forth language, it is a problem with the Forth community. When a business fails, it could be because the product is bad -- but it also could be that it was not properly advertised, that it was targeted to the wrong market, or that the company was mismanaged. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093