Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!PENNDRLS.BITNET!DAVID From: DAVID@PENNDRLS.BITNET Newsgroups: comp.lang.forth Subject: Re: Why FORTH is good Message-ID: <8809092121.AA09902@jade.berkeley.edu> Date: 9 Sep 88 18:44:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Forth Interest Group International List Organization: The Internet Lines: 148 Fraser Orr writes: >I haven't read the paper in question. But if I know John Hughes, the two >forms of glue that he will be talking about are lazy evaluation and >higher order functions. Neither of these glues are avaliable is forth. >Moreover I know of no proper module facilities in forth like languages >(although PostScript - a forth like language- has added object oriented >features). > >To suggest that this paper backs up forth as a wonderful programming >language is ridiculous. I does quite the opposite. It says that >modularity is crucial in large programming projects, this is not >avaliable in forth. It says that glue is crucial, the glue avaliable is >forth is the worst glue avaliable in just about any programming language >there is (because it is untyped, and unsized, and it has very limited >facilities for passing complex structures about). The princliples that >undergird functional programming are clarity, explicitness, flexibility >and type security. > >Forth bears absolutely no resemblance to any functional programming >language I know, (appartfrom the fact that the both run on a computer of >course :^>). I'd like to comment on this in two parts. First insofar as it is a response to an earlier posting, and second as a comparison of FORTH and functional programming. First of all, I don't think the original poster was claiming that the paper backed up FORTH as a wonderful programming language, but rather that it singled out modularization as the greatest good; the fact that FORTH makes it easy to completely modularize code then implies that FORTH is a ``good'' language *in this regard*. Obviously, however, you do not agree that FORTH allows easy and complete modularization. I think we need a definition of modularization. I suspect you are in fact referring to language facilities directly aimed at building modules. If so, you are correct, plain FORTH has none. But even the computer scientists agree that modularization is something that happens in the programmer's head, not in the language. So to say that modularization is not available in FORTH is a misstatement. Further, I remember reading of at least one example of adding MODULA style modules to FORTH ``in a few simple screens of definitions.'' (Before you object that this is not part of the standard, keep in mind that most functional programming languages start out with a very simple (but powerful) core to which quite a bit of code must be added before you have an adequate *programming* environment. Sound familiar?) But even (or especially) *without* MODULA style modules FORTH provides a good environment for modularization because it allows the problem to be decomposed in a way that fits the *problem*, not the programming language. (Of course, some traditional languages are better at allowing this same kind of decomposition than others.) A program design book I was reading recently (yes, Fraser, I found a generic one) maintains that the proper way to decompose a program is to design data structures in terms of the operations that may be performed on them (including transformations between data structures). FORTH is excellent for this kind of decomposition, better than any traditional language I know. (C++ and SmallTalk may be as good; I don't know them.) Other points vis-a-vi FORTH and functional programming (this is neither a rebuttal nor an attack, but more of an opening of a discussion): Lazy evaluation: There is no reason why one could not define individual FORTH words that evaluated in a lazy fashion. Still, it is clearly much better to have the system make that decision if it can. Here I would agree that a functional programming language is superior to FORTH. Higher order functions: are functions that operate on other functions as data. FORTH can do this in several ways, since a function can be represented by its address. Agreed, this is not as elegant in practice as true functional programming, but it is closer than FORTRAN or PASCAL can come. Of the current most widespread languages, only C approaches FORTH in its potential for higher order functions. FORTH glue bad because it is untyped: Since when have functional program glues been typed? I didn't think that type checking was part of the fundamental design. Well, Backus' FFP returns undefined if you apply a function to an argument it doesn't handle, but that doesn't help during the ``compilation'' step. Your arguments for type checking were based on informing the programmer of errors *before* running the program. Complex data structures: FORTH can pass data structures of arbitrary complexity; this is one of its strengths. Any data structure is represented by the address of its root. I'm sure you could implement S-expressions in their full glory in FORTH, in fact I suspect someone has by now done so. Clarity: We've been arguing for a while now about what is clear and what is not. You find explicit argument lists clear, another poster found the absence of argument lists clearer. (I agree with the latter.) At first exposure I did not find functional programming notation clearer than I found FORTH or APL at first exposure. In each case the examples have become clearer as I have grown used to the notation. Some algorithms I find easier to comprehend in the (best of) the functional notations I have seen, others I find clearer in well written FORTH. Explicitness: Functional programs may be explicit about what functions are getting what arguments, but you still have to visualize the actual data being handed around to *really* see what is going on. If I see f(g(h(z))) I have to visualize the result of h on z, then of g on that result, then of f on *that* result. Even when the visualization is in symbolic terms, how is that easier than visualizing a three deep stack? Especially if Z is an S-expression (or equivalent) with three or more subexpressions of distinct types? Flexability: Well, you'll never convince us that FORTH is not flexable, so I guess I'll let this one alone. Type security: Again, how does functional programming provide type security? (That's not a challenge, that's an honest question.) FORTH as a functional programming language: As I understand it, the basic characteristic of a functional programming language is that a function always has the same result when given the same input values, regardless of the state of its environment. Many many FORTH words have this characteristic. A number do not, and many of these are critical to the functioning of the FORTH system. It is this latter that makes FORTH appear so un-functional. Good FORTH programs minimize and restrict these state-changing words. Consider how few variables good FORTH programs have relative to traditional programs and FORTH may start to seem more functional. FORTH would appear to be inferior to a true functional programming language because (1) Not all FORTH words are true functions. This reduces their mathematical tractability, ease of comprehension, and ease of maintenance. (2) FORTH cannot perform lazy evaluation automatically. (3) Higher order functions are not easy to write in FORTH. The price the functional programming languages pay for having these features are the complexity of the program interpretation process and the slow speed of execution. This can be alleviated by special purpose hardware, and may have advantages in a massively parallel environment. FORTH programs can be made more functional by reducing non-local variable use. Higher order functions and lazy evaluation of some functions can be introduced if sufficiently desirable. (I'll have to think about that some.) FORTH runs efficiently on current hardware. Until functional programming languages come of age, I'll stick to FORTH. (But I'll try to investigate Miranda.) -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)