Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!usenet.ins.cwru.edu!abvax!iccgcc!schmidtg From: schmidtg@iccgcc.decnet.ab.com Newsgroups: comp.lang.forth Subject: Re: General Purpose Forth Message-ID: <3835.27e4e843@iccgcc.decnet.ab.com> Date: 18 Mar 91 21:18:10 GMT Lines: 143 In article <13837@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > In article <3729.27db5037@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: >> bouma wrote: >>> Forth down. A language that deals only with characters and integers >>> is a joke. It is no coincidence that Forth gravitated to the embedded >>> processor area, they don't need to deal with anything besides integers >>> ... >> >>FORTH is an excellent general purpose language for just these reasons! FORTH >>provides one with the tools to create more specialized tools which are useful >>to solve a given problem. Try adding a new control structure to 'c'! > > Why do people always try to drag C into the argument? I have never felt > the desire to add a new control to C. I can program sufficiently in C > given the structures which are provided. In addition C provides me with > a wide variety of types and uniform ways to create new ones and deal with > intermixing. > > I consider both FORTH and 'c' to be "multi-level" languages and hence the comparision. Both languages allow you to get close to the machine and then build up to higher levels of abstraction. I think FORTH encourages one to create specialized tools which are useful to solving the problem at hand. For example, if your application requires extensive pattern matching, you might consider creating a CASE statement based on character string comparisons. > > Heck, Assembly language has more "expressive power" than Forth! Does > that make it a good general purpose language? I agree that "expressive power" alone does not make for a good general purpose language although it is a big part of it. Where FORTH excels is in the ease in which higher levels of abstraction may be applied until an application specific high level language is created. As an aside, in some ways I consider FORTH more powerful than assembly since I don't have complete control over the assembler, yet I have complete control over the FORTH "colon compiler" and may redefine it if I like. For example, let's say that I am writing a program in assembly and I want to trace program flow by printing the name of each subroutine as it is called along with its arguments. In assembly, this would be a laborious task and would require source code modifications. In FORTH, I can simply redefine the "colon compiler" to compile my traceback routine into the beginning of each word and then recompile my application. This would require 2, maybe 3 lines of FORTH. > > Ok, write a floating point package (+ - * / are sufficient) using only > Forth. Given a rich variety of integer and character operations this > could be done. Now try sharing your code that uses this package with > a friend. Good, that works because you have been careful to use only > Forth in your package and avoided machine dependencies. Now try com- > bining some code that uses your package with your friend's code that > uses his package. Trouble. At that point you and your friend are both > thinking you should have used the same package to start. If my friend and I have both implemented a standard such as IEEE then I would not expect to have a problem. This is a standards issue and I won't argue the point that FORTH standards for things such as floating point have been slow to mature. > > Suppose in Forth I want to create a new type which is just a data struc- > ture of integers and characters. In doing so I have to think about > memory in a concrete sense. Memory allignment, slot access functions, > byte size of integers are all considered in writing my code. In any > language besides Forth all I gotta do is say I want a type named * > which has slots ** of types ***. The compiler takes care of memory > offsets, allignment, and access. Memory has become an abstraction with > little shape or structure. Personally, I have found the higher the > level of abstraction, the farther I am away from the actual machine, the > more productive I can be. And I am one who LIKES to program in assembly > language and can do so at lightning speed (brag, brag, brag). This is a matter of control. I'd prefer to have the control in my own hands rather than leave it to the compiler. Nothing is more frustrating than a compiler which is "too smart for its own good" and makes assumptions which are correct 90% of the time. A compiler which assumes a particular alignment may not allow me to use its data structuring capability to define an external interface, such as a communication packet because it is making assumptions about alignment which may not always be true. > 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. I agree that FORTH requires you to build a base and I think the standards should at least suggest uniform ways for building the "base". However, in practice, I have found that the needed "base" tends to be small as it need only address those aspects which are important to the problem I am solving. > > Data types is such a basic and fundamental abstraction in programming > that it is silly for Forth not to deal with it in a standard fashion, and > be done with it. Why should each person that wants to use different types > have to first figure out a method, and then implement it individually? It > seems proof that Forth was never meant to be general purpose, that the > type issue was not dealt with long ago. > I tend to think of FORTH as a set of tools which allow me to build special purpose tools which are useful for a given application. Initially, I may put forth (no pun intended) more effort in developing these application specific tools, but once these tools are in place, I may then use these new tools to allow me to be highly productive when applying them to a given problem. I find this to be one of the most creative and productive ways to solve a problem. I like the flexibility of creating my own tools, rather than having them rigidly provided by traditional compilers. I refer to the "staircase" example that Brodie mentions in "Thinking Forth". If I were building a house, I would like to have the ability to build my own staircase, rather than be limited to one supplied by a contractor. By building my own, I can get exactly what I want and be satisfied that it blends well with the rest of the house. On the other hand, I would agree that I should still have the option of buying the staircase from the contractor. With regards to FORTH, I think that issue is something which should be addressed by the FORTH standards. > variables, pattern matching, ... (eg. Common lisp with CLOS) 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. > -- > Bill If you dislike FORTH so much, why do you spend so much time in this newsgroup? Do you have some constructive comments on the direction you would like to see FORTH take, or do you feel that the language is a "joke" and should be abandoned altogether? -- ============================================================================= Greg Schmidt -> schmidtg@iccgcc.decnet.ab.com ============================================================================= "People with nothing to hide have nothing to fear from O.B.I.T" -- Peter Lomax ----------------------------------------------------------------------------- Disclaimer: No warranty is expressed or implied. Void where prohibited. =============================================================================