UNBCIC@BRFAPESP.BITNET (03/20/91)
> 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 <cond> : <action> <cond> : <action> ... ... 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 <cond> : <action> ... ... 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
wsbusup@EUTWS1.WIN.TUE.NL (Jan Stout) (03/20/91)
> > 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 <cond> : <action> > <cond> : <action> > ... ... > 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 <cond> : <action> > ... ... > 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. What's that you said? Dijinskra? (Since you called him that twice I don't consider the posibility of faulty transmission software:) I knew Dutch is not the easiest language for a non-native, but the man was called Dijkstra when he left this university X years ago. Furthermore I would use the original (shorther) spelling, so the constructs become: IF guard0 DO guard0 -> statement0 -> statement0 [] guard1 [] guard1 -> statement1 -> statement1 ... ... [] guardn [] guardn -> statementn -> statementn FI OD By the way, implementing IF/FI and DO/OD as is in Forth, will be a bit hard, because of the prefixedness. Therefore I'd suggest a syntax like the following: guard0 guard0 IF statement0 [] DO statement0 [] guard1 guard1 IF statement1 [] DO statement1 [] ... ... guardn guardn IF statementn FI DO statementn OD Note that when [] gets rewritten as ELSE, you'd have a alternative to the Baden's OF THENS and Eaker's CASE. I'll leave the implementation pleasures to you :) Jan Stout, Eindhoven University of Technology wsbusup@eutws1.win.tue.nl (for now anyway)
adam@visix.com (03/23/91)
In article <9103210409.AA14380@ucbvax.Berkeley.EDU>, UNBCIC@BRFAPESP.BITNET writes: > I did understand you. You are, basically, right. I just wanted to point out > some information... I am glad that you have said this. I don't like to be picky, but I do want to say that it was kind of confusing to start your previous message with "hehehe, I'll show you that you are wrong". > ...The style that you suggest is the functional paradigm (or applicative > paradigm). I will refute this statement below. > I don't know what kind of LISP programs you have seen, but this is > the base of LISP. Again, I am uncertain how to take this statement. If you mean to imply a question about my LISP experience, then I will mention that my first programming course was Structure and Interpretation of Computer Programs by Abelson and Sussman at MIT. But it would not make sense for you to imply this question, since it is irrelevant to the discussion at hand. > (about Dijkstra's suggested commands) > 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. These are the examples I suggested. However, the fact that these examples arose in the context of functional programming does not mean that they ARE functional programming. If you claim that these examples ARE "the functional paradigm", then you cannot make the statement that these are "operators to improve functional programming." You must instead claim that these are operators necessary for the implementation of functional programming. This distinction may seem to be picking nits, but I must separate the examples from the paradigm in order to show that we can use the examples without using the paradigm, namely that the statement below: > The whole problem is that functional > programming is not well adapted to our computers. is irrelevant to my suggestion. We refute the statement, "the style I suggest is the functional paradigm" in two ways. I. We show that the functional paradigm does not imply the style I suggest. The following Scheme function: (define (factorial n) (if (= n 1) 1 (* n (factorial (- n 1))))) is functional, since it does not make any assignments. However, it is not written in the style I suggest. That would look like: (define (factorial n) (accumulate * 1 (enumerate-interval 1 n))) II. We show that the style I suggest does not imply the functional paradigm. The following Scheme code: (define 'marys-account 100) (define 'jims-account 200) (define 'toms-account .25) (define bank-accounts '(marys-account jims-account toms-account)) (define (add-interest bank-accounts) (mapcar (lambda (x) (set! x (* x 1.05))) bank-accounts)) is written in the style I suggest, but it is not functional, because it has side-effects and its behavior depends on state. Part II is important because it means we can program without explicit control structures in a language like Forth without first making Forth a functional language. I am also planning on using this style in C. > IF is necessary. But you can try guarded commands.... > GUARDED-BEGIN <cond> : <action> > <cond> : <action> > ... ... > GUARDED-END This is an interesting example, but I hope you understand that it is not actually in the style I suggest, and so I will not be pursuing it. Adam