Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!bcm!rice!titan.rice.edu!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.lang.misc Subject: Re: := versus == Message-ID: <1990Aug9.174513.16437@rice.edu> Date: 9 Aug 90 17:45:13 GMT References: <7H+4AM6@xds13.ferranti.com> <1990Aug2.170110.28208@rice.edu> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 46 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1990Aug2.170110.28208@rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >> Same problem in lots of languages where people write functions >> with side-effects. >As, for example, any object oriented language where objects have internal >state. Like, about all of them. Sure, but "methods" could be divided into "procedures" (with side-effects) and "functions" (that have no side-effects). >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? Functions couldn't have I/O, >or for that matter call procedures (since procedures can have side effects). I believe there was a language called Euclid, perhaps originating at Waterloo, that had such a restriction. Probably there are others. Regardless, you are exactly right -- it is a significant restriction. No I/O, no procedure calls (though further functions calls are ok), no modification of global variables, no memory allocation. Sure isn't C! It means however, that expressions behave more like those idealized things we learn about in algebra. When you evaluate an expression twice in a row, you get the same result. When you commute commutative operators, the result doesn't change. When you re-associate associate operators, the result doesn't change (in the context of floating-point, I'm lying). Optimizers like these features. Since most languages don't have them, optimization is restricted in the presence of function calls. (Apparently, in the case of C, the optimizer is allowed to do anything, since expressions with side effects are undefined(!). Remember that "undefined" means the optimizer may fork a game of chess if it cares to.). Historically, people don't seem to care. Almost no languages enforce such a restriction and most people don't care to discipline themselves. Nevertheless, side-effects in expressions are ugly. Functional programming fans go further and say "side effects are ugly". Tastes vary. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu