Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!BRFAPESP.BITNET!UNBCIC From: UNBCIC@BRFAPESP.BITNET Newsgroups: comp.lang.forth Subject: Functional (Applicative) Programming Message-ID: <9103210409.AA14380@ucbvax.Berkeley.EDU> Date: 20 Mar 91 13:35:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Organization: The Internet Lines: 159 > Okay, I guess I should explain myself more carefully. I did understand you. You are, basically, right. I just wanted to point out some information.... > I stated that structured programming considered GOTO's evil, primarily > because I wanted to use that example for an analogy. > I won't argue about whether GOTO's have legitimate uses. > I won't argue about whether the definition of structured programming > necessarily considers GOTO's evil. > I know that not all control structures are loops; e.g. CLU and Ada > have exception handling. I used loops as a common example. Yes, I know. But this should be made clear for the others. Information is important, and all this messages are public. We must care about the others. > I only concluded recently that "control structures suck," so I am not > prepared to demonstrate equivalents for every existing control > structure, and so I wrote "used primarily", and "I suspect." This is why I have presented you more information. > I do not think all theorists forget to ask the right questions. I do > not think my questions are the ones theorists have to ask; I do not > think that theorists are doing the wrong thing. > > Theorists follow their interests, often without considering > > applications (nor should they). > ^^^ ^^^^^^ ^^^^ > I do think that techniques like parsing, which may be very well > understood theoretically, are not necessarily the best way to improve > my productivity as a programmer (unless I do Natural Language). Someone that do not impose what he think to the others! Wow! > > Ok, let's reinvent the weel (your arguments were used sometime ago... 196X). > I don't understand the purpose of this comment. Are you claiming that > people already program in the style I suggest? I don't find this in > the code I have seen, except for APL, some (repeat: some) Lisp > programs, and UNIX one-line command scripts. Yes. The style that you suggest is the functional paradigm (or applicative paradigm). I don't know what kind of LISP programs you have seen, but this is the base of LISP. Actual LISP compilers have procedural extensions in name of speed. But the original LISP was all the way you propose. APL is very slow, and this is why the programs are very functional -- is the only way to make it more fast. Believe me, LISP should be programmed the way you suggest. > I wouldn't claim to have invented this wheel; APL, Lisp, and UNIX are > examples. I should also say that my train of thought was started by > the "Minimizing Control Structures" chapter of Thinking Forth. I know, I know. But you like the idea, so I'm giving you more information about it. Dijinskra, I think, have a group of languages (non-comercial ones) that are totally functional, and he suggest some kinds of "commands" (control structures, basically) that can be used to improve these kind of languages. Things like: do X to all elements of Y; With X # Y (X it's a operator like +, for example) return (first element of Y) X (X # (rest of Y)) -- this reduce a vector to a element through one operator. In other words, operators to improve functional programming. > But wheels that have been invented still need to be used. Only the round ones! :-) > I also can't tell what you mean about my arguments being used back in > 196X. I'm not even sure if you might have misunderstood my argument. > References would help. Your arguments were used back in 196X, and APL, LISP and other functional languages are the result of this. The whole problem is that functional programming is not well adapted to our computers. > > I didn't understand the last. (UNIX) > Briefly, UNIX's pipe operator allows you to construct surprisingly > sophisticated one-line command sequences, without conditionals. > Please don't ask me to explain in detail; any good UNIX book will do. Thanks. I didn't though about the shell. I know it, and, believe, I use this kind of things even in DOS. > > Anyway, for the first two: Think Functional > > Paradigm! And Think OOP because there you have this too... > Functional programming is about evaluation and avoiding side-effects. These are the WHYs. What you proposed are the HOWs. > These are separate issues from how often the keyword "IF" appears in > your program. IF is necessary. But you can try guarded commands.... GUARDED-BEGIN : : ... ... GUARDED-END If no condition is satisfied, the program aborts. If two or more conditions are satisfied the action assossiated of one of them (non-determined) will be executed. GUARDED-LOOP-BEGIN : ... ... GUARDED-LOOP-END The loop will be executed as long as there is one condition being satisfied. You can choose whatever behavior you want when there is more than one condition being satisfied. These are Dijinskra structeres. > > your program. And, Goldberg and Robson's _Smalltalk-80_ contains > > neither use nor mention of the programming style I suggest. No. But they have iterators, and these are the basic control structures of the style you suggest. > > No IF's? How can you do that? LISP can't... APL have IFs too. : : > > Iteratio is a control structure, if you don't know. Control structures makes > >the program do things in a non-sequencial way. Calling procedures is a contro l > > structure, repeat many times is a control structure, and it doesn't matter i f > > your LOOP is hidden or not. You HAVE to specify an iterator, don't you? > I just realized what I should have said in the first place. > Every line should be a basic block. > A basic block has one entry point and one exit point. In languages > like C, since a function is the unit of decomposition, it is only > required that functions be basic blocks. Since Forth encourages a > finer decomposition, it suggests that we can make basic blocks > smaller. > Smaller basic blocks also provides enormous benefits for traditional > compilers; smaller basic blocks makes programs easier to reason about, > and therefore easier to optimize, and also easier to parallelize. Parallelize. That's true. But think about finding prime numbers. It's obviously more ellegant in functional style. But is much more faster in the "normal" style with our current computers. > > (almost everything) Daniel C. Sobral > Adam (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET