Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!BRFAPESP.BITNET!UNBCIC From: UNBCIC@BRFAPESP.BITNET Newsgroups: comp.lang.forth Subject: Forth in CS Message-ID: <9103061356.AA26910@ucbvax.Berkeley.EDU> Date: 5 Mar 91 21:03:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Organization: The Internet Lines: 99 > I've recently concluded that control structures suck. They focus your > attention on nitpicky little details of tests and switches instead of > the higher level tasks you want to do. Hehehehehe. I'll show you that you are wrong! > Structured programming states that GOTO's are evil because they are > used to implement many different kinds of loops and branches. It is > better to name the higher level constructs and use them directly. Not at all. Structured programming let you use GOTO to simulate IF THEN ELSE, WHILE and or any higher level control structure. But you can use GOTO in other ways. > Why don't we take this reasoning further? Ok, let's reinvent the weel (your arguments were used sometime ago... 196X). > What are loops used for? LOOPs doesn't mean CONTROL STRUCTURES! > (1) Applying an action to all members of a set. > (2) Sequencing similar actions. > (3) Filtering a stream. > These uses are focused around data types: set, sequence, stream. In > (1), our iterations equal the size of the set, but we don't care about > the execution order. In (2), we have a fixed set of actions for which > order matters. In (3), we have an arbitrary length (perhaps infinite) > sequence of actions. > Why denote all of these with the same construct? > Why not provide Sets, Sequences, and Streams, each with a > corresponding "execute_over" operation? Yes, iterators. They exist in Functional and Object Orientation Paradigms. Sometimes they are not efficient, by the way. > Think APL. Think Lisp. Think Unix. I didn't understand the last. Anyway, for the first two: Think Functional Paradigm! And Think OOP because there you have this too... > Similarly, conditionals and switches are used primarily to map sets of > values to sets of actions. > I suspect all control structures can be "hidden" this way. I suspect > you could program in a style that uses control structures as rarely as > structured programming uses GOTO. No IF's? How can you do that? LISP can't... APL have IFs too. I know the operation that selects part of the vector depending upon other vector of zeros and ones. But what to do is so important as with what to do. > All through my compilers course I was thinking "what a waste of time." Now, that is important. If you don't want to program in an enviroment. (Not a joke) > This is not to say that I think Forth is a great language for theory. > Forth is a practical language, not theoretical. But precisely for > that reason, Forth hints at questions that theorists forget to ask. Some of them, yes. Most of them, probably. All - NO WAY. But you cannot expect that many theorists do the right thing -- statistically there is less brilliant people than than the commom ones. > The theory of control structures is interesting, but what good is it? > (Most control details should be abstracted away.) 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 control structure, repeat many times is a control structure, and it doesn't matter if your LOOP is hidden or not. You HAVE to specify an iterator, don't you? > The theory of parsing is interesting, but what good is it? > (If you want your programs to look like algebra or natural language, > you have to parse them. But parsing costs power and efficiency.) Ok. But the theory applies to NL Interfaces too, not only programming languages. > Theorists follow their interests, often without considering > applications (nor should they). Compiler theory is supposed to be all > about productivity, but a compiler theorist is buried too deep to ask, > "should I really be using a compiler?" > When I'm trying to maximize my productivity, a lot of computer science > looks like right answers to the wrong questions. Yes. That's why there is the word vanguard. > Adam (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET