Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: function side effects (was: i++, i+=1, i=i+1) Message-ID: <456@quintus.UUCP> Date: 21 Sep 88 08:10:01 GMT References: <3987@h.cc.purdue.edu> <3821@lanl.gov> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 30 In article <3821@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Still, you haven't addressed the REAL issue that _I'm_ interested in - >should side effects be allowed where Fortran currently doesn't allow >them? If so, how can the language be modified to make such an allowance >without throwing out the ability to optimize expressions? This has a >bearing on the original subject of this discussion - should Fortran >(or any language) have those extra assignment operators? If functions >aren't allowed side effects, the extra assignments are not very interesting. I imagine that Fortran functions are allowed to change things in order that they may be passed suitably dimensioned working storage, and that if/when functions were/are allowed to have dynamically dimensioned local arrays, function side effects could/can be dispensed with entirely. This has essentially no bearing on the question of whether a language should have assignment operators: they are, like long identifiers, technically a luxury, but in practice a useful aid to reading and writing code. Note that C could dispense with update assignment: for each type T and operation O for which Lhs O= Rhs is currently defined, we could define T T_O_asg(T *Lhs, T Rhs) { return *Lhs = *Lhs O Rhs; } e.g. long long_plus_asg(long *Lhs, long Rhs) { return *Lhs = *Lhs + Rhs; } and then use TOasg(&(Lhs), Rhs) instead of Lhs O= Rhs, e.g. (void) long_plus_asg(&i, 2); instead of i += 2; This would take care of the "side effects occur only once" point, and with C++'s inline functions would presumably result in the same code being generated. It's (now) a "readability" issue, not a "power" issue.