Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr From: orr@cs.glasgow.ac.uk (Fraser Orr) Newsgroups: comp.lang.forth Subject: Forth and Functional Languages Message-ID: <1625@crete.cs.glasgow.ac.uk> Date: 12 Sep 88 15:00:22 GMT References: <8809092121.AA09902@jade.berkeley.edu> Reply-To: orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) Organization: Comp Sci, Glasgow Univ, Scotland Lines: 180 In article <8809092121.AA09902@jade.berkeley.edu> Forth Interest Group International List writes: >Fraser Orr writes: [Stuff that I believe justifies the following assertion deleted] >>Forth bears absolutely no resemblance to any functional programming >>language I know, (appartfrom the fact that the both run on a computer of >>course :^>). > >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. Yes, you've got me there. I'm sorry, but that wasn't really the intent of what I was saying. Clearly modularisation is possible in all languages (even down to the ubiquitous 68000 assembler), the question I was adressing was the support the progrmming language provided for modularisation. Now let me restate my point, Forth has very little support for the programmer's concept of modulariation (with the above proviso) >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?) I'm no expert on all the functional languages in extant. Those that I do know of though do need this package of extra stuff. The point though is that this packet of extra stuff is STANDARDISED. It comes with all releases of the language, so everybody has them avaliable, they are not added and rebuilt by every miranda programmer. Moreover many of the things we have been discussing in this group come as part of the language itself (as it should be), things like modularisation and glue, they are not bits stuck on as an afterthought, but are fully integrated into the language. >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.) Come on David. If you're going to make statments like this it would be helpful if you could give your reasons for believing so. I cannot even imagine why you believe this because I see no way in which forth is better at this sort of this that just about any other language I know (in fact I can see no way in which forth is not worse at this sort of thing than just about any language I know, my justification? Hidden parameter lists - thus it is dificult to see the data flowing, lack of type checking thus loosing all the benifits of having the compiler check out you are using data properly.) You reminded me that I had promised someone to post the name of a good generic program design book, I forgot who it was so I'll post it here, I would recomend - "Software Enginerring - A Practitioner's Approach" by Roger PressMan (McGraw-Hill 2nd Ed) You go on to discuss some of the things I said were avaliable in Functional languages but not in Forth. I've missed out the things we agree on to a large extent. > 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, As I said above, you can also do this with 68000 assembler, the improtant thing is the notational convenience. In functional languages (the ones I know that is) the higher ordered-ness is not stated explicitly, but implied from the context. I'm not convinced this is good because there are a lot of errors that could result from this (most of which will be picked up by the type system), I don't know if I would prefer a seperate notation for partially applied functions The big win in functional languages (fl from now on) is that they provide this sort of facility with type checking. > 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. All the fl that I know have type checking as one of their central features. I've only seen Bakus' FP from afar, and what I saw, I don;t want to see any more. I'm interested in the new functional languages that are being designed now, and have been in the near past. And in answer to your implied question, yes this type checking is done at compile time (or pre-run time in the Miranda we have, which is interp) > 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. Again you can do this in assembler, notation is the important thing. There is no standard forth notation for records (that I know of anyway). > 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 As I've said earlier I would be in favour of a pipeline notation as an alternative to function composition. That is ... h (h-list) | g (g-list) | f(f-list) is equivilent to f(g(h(h-list),g-list)f-list) > Type security: Again, how does functional programming provide > type security? (That's not a challenge, that's an honest > question.) See above. FLs are the most type secure langusges I've ever used. > 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. If your saying that people should write in a functional style then great, I agree. All I'm saying is that your programming language should to as large an extent as is possible back up your programming style. FLs back up a functional style, forth in my opinion backs up a very low level style (by the falure of the language to abstract away from implementation details) I can't justify this without a few years of research, so I'll have to leave it as a gut reaction, that I'm sure you'll all agree with :^) >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.) Yes, this is all true. You can make any program more functional by applying these rules, regardless of their programming language. Functional programming is educational in that it challenges you to program in other languages in a better manner. I agree with you that FLs are too slow for all practical intents just now (and I don't and wouldn't use one for my work). It is possible to put many functional features into languages that can be used practically. Now if forth had a pre-processor ... (Yawn, YAWN, Yawwwww zzzZZZZZ ! :^) >-- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU) You other forthers might think this is an inappropriate discussion for this group, but for the reasons outlines above I think it is benificial since by looking at the strengths and weaknesses of other langauges (and I freely accept that Miranda has both strengths and weaknesses) we all might learn something that we can take back and apply to our own style of programming. I would recomend that everybody learned at least simple functional programming, and I certify that you will be a much better programmer for it. Regards, ===Fraser