Path: utzoo!utgpu!news-server.csri.toronto.edu!csri.toronto.edu!norvell Newsgroups: comp.lang.misc From: norvell@csri.toronto.edu (Theo Norvell) Subject: Re: := versus == (really side effects in expressions). Message-ID: <1990Aug9.172356.599@jarvis.csri.toronto.edu> Organization: CSRI, University of Toronto References: <=L-4T-A@ggpc2.ferranti.com> <17559:Aug101:50:5290@kramden.acf.nyu.edu> <7H+4AM6@xds13.ferranti.com> <1990Aug2.170110.28208@rice.edu> Date: 9 Aug 90 21:23:56 GMT Lines: 47 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Aug2.170110.28208@rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >> With C, Q, and PL/M, this doesn't hold. > >> (i := 1) + i is not always equal to i + (i := 1) > >Oh, it's worse than that. (i := 1) + i is not always equal to (i := 1) + i, >depending on optimisation level, or (for a sufficiently clever optimiser) >surrounding code. I can even imagine cases where the same expression twice >in a row produces different results. But, as was pointed out, these expressions are not licit in C (even after changing := to =). Both lead to undefined behaviour and in that sense they are equal. What they are ``equal to'' numerically is as uninteresting as what they are equal to in Fortran, Cobol, or Lisp. The situation may be different in Q or PL/M. >As, for example, any object oriented language where objects have internal >state. Like, about all of them. No problem. Divide methods into two classes: Functions, which may not alter the internal state, and Procedures, which may alter the internal state. Object orientedness is orthogonal to this discussion. >A language that prevents functions from >having side effects is likely to be pretty restrictive. Can you think of >one, other then purely functional languages? Several. Euclid, Turing, Cybil. Ada too, no doubt. Even Fortran, I think, though this is not enforced by compilers. Language designers have long been aware of the unhealthiness of side effects. >Functions couldn't have I/O, >or for that matter call procedures (since procedures can have side effects). There is no need to ban all procedure calls, only calls that cause side effects. If you want all potential side effects banned compile time, all calls in some superset of those that have side effects must be banned, but still not all calls to all procedures. Something that would be useful is a notion of a ``benign side effect''. For example, a storage allocation function (e.g. a cons function) may have the side effects of shortening a free list or collecting garbage. But the side effect is likely hidden by a module interface. Theo Norvell