COTTRELL@BRL.ARPA, JAMES (08/08/85)
/* > 3) Is there really much to be gained by using assignment within > a boolean expression, for example, is > > if ((fp = fopen("foo", "r") == NULL) { Darn tootin! Consider the common case of: while ((c = getchar()) != EOF) { process(c); } /* AT EOF */ Now how do you write it without the assignment? 1) c = getchar(); while (c != EOF) { process(c); c = getchar(); } /* AT EOF */ 2) for (c = getchar(); c != EOF; c = getchar()) { process(c); } /* AT EOF */ 3) do { c = getchar(); if (c != EOF) process(c); } while (c != EOF); 4) for(;;) { c = getchar(); if (c == EOF) break; process(c); } Get the idea? Either 1) you have to duplicate the initial assignment, 2) you have to duplicate the test, or 3) you have to use TWO control struxures (three if you count break) in a non-obvoius way where one would do. This is a very simple example, but things get quite complicated if either the assignment or the processing is expanded inline. There is no reason why assignment should not return a value. LISP & APL both do. An experienced programmer in either language can handle that. In LISP, even conditionals & loops return values, & I see no reason why they couldn't have been designed that way in C. The penalty for excluding assignment in conditionals is contortions in the control struxures. If you can't stand the heat, stay out of the compiler. Stroll around the grounds until you feel at home. jim cottrell@nbs */ ------
peter@kitty.UUCP (Peter DaSilva) (08/09/85)
> There is no reason why assignment should not return a value. LISP & APL > both do. An experienced programmer in either language can handle that. > In LISP, even conditionals & loops return values, & I see no reason why > they couldn't have been designed that way in C. In the language 'C' is rumored (:->) to have developed from, they do. In BCPL any block can return a value: FOO = $( ... RESULTIS <expr> $) (or is that )$???) You can also do this: foo(table 1,5,7,9) Which is the equivalent of int *tmp={1, 5, 7, 9} foo(tmp) I wish 'C' kept both of these. I can do without the weird TEST/IF/UNTIL/WHILE... control structures, though. Hell, even auto-initialise aggregates other than strings would be ok. I know. The language purists are going to shoot me. (hides behind copy of "BCPL, the language and it's compiler" (Richards & Whitby-Stevens, Cambridge University Press, 1980)
gwyn@BRL.ARPA (VLD/VMB) (08/10/85)
Having built a compiler for a purely functional language, I can attest that the idea is not as good as it may appear to those who haven't designed such a language. I used to think it would be nice if every statement returned a value, but as a result of the experience I have changed my mind.
ray@othervax.UUCP (Raymond D. Dunn) (08/12/85)
> Having built a compiler for a purely functional language, > I can attest that the idea is not as good as it may appear > to those who haven't designed such a language. I used to > think it would be nice if every statement returned a value, > but as a result of the experience I have changed my mind. Why? How? When? What? ..or do we just all take your word for it and never do it (what?) Ray Dunn. ..philabs!micomvax!othervax!ray
ludemann@ubc-cs.UUCP (Peter Ludemann) (08/14/85)
In article <594@brl-tgr.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: > ... I used to >think it would be nice if every statement returned a value, >but as a result of the experience I have changed my mind. A while back, I read a paper from the University of Toronto which tested two otherwise "identical" languages - one was expression oriented and one statement oriented. Conclusion: the statement oriented one was easier to learn and programming was faster in it. The only problem was that the authors weren't sure how much of this effect was caused by most other programming languages being statement oriented (sorry, I don't have a reference for this - it was a CSRG report from U of T). -- ludemann%ubc-vision@ubc-cs.uucp (ubc-cs!ludemann@ubc-vision.uucp) ludemann@cs.ubc.cdn ludemann@ubc-cs.csnet Peter_Ludemann@UBC.mailnet
peter@baylor.UUCP (Peter da Silva) (08/16/85)
> > Having built a compiler for a purely functional language, > > I can attest that the idea is not as good as it may appear > > to those who haven't designed such a language. I used to > > think it would be nice if every statement returned a value, > > but as a result of the experience I have changed my mind. I thought you just mailed this to me. OK. 'C' isn't a purely functional language, so there is relatively little you can learn from this comparison. Maybe if it supported "call by name", but that's another story. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@baylor.UUCP (Peter da Silva) (08/21/85)
> A while back, I read a paper from the University of Toronto which > tested two otherwise "identical" languages - one was expression > oriented and one statement oriented. Conclusion: the statement > oriented one was easier to learn and programming was faster in it. > The only problem was that the authors weren't sure how much of > this effect was caused by most other programming languages being > statement oriented (sorry, I don't have a reference for this - > it was a CSRG report from U of T). I think I saw that. It was in CACM or some similar journal... just ran through my back copies but didn't find it, so either it's not a straight article, it has a funny title, or I lent it to someone. That wasn't the only flaw. The other problem was that the two languages *weren't* otherwise identical, because if they were the statement oriented one would have been a subset of the expression oriented one. -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076