On 24/07/2008, at 10:55 PM, Adelle Hartley wrote:
That's kind of the idea. I'm not sure the user should know whether they are using a constant or a function.[..]I've long considered deterministic functions, like sine, to be an interesting case. By deterministic, I mean that given the same set of input values, the return value will be the same for each invocation of the function with those input values.
The usual term for your idea of "deterministic function" is "pure function". Congratulations, you've just invented Haskell ;). <http://www.haskell.org/ >
You can also specify pure functions in GCC by declaring a function as e.g.
int square (int) __attribute__ ((pure)); Linux Weekly News also had a good recent article about this topic: "Implications of pure and constant functions" http://lwn.net/Articles/285332/though after being exposed to functional programming, the message I personally take away from that article is that annotating pure/ constant functions in C is just not worth the trouble. In the traditional C spirit, the compiler gives you no guarantees about whether your annotation is actually correct, and stuff like memory allocation hurts your head when you're trying to figure out whether a C function is really pure or not. C++ is better, since you can specify that methods can be const, but const-correctness in C++ is a bit of a headache. The D programming language may be gaining an interesting functional programming feature set for version 2.0 too, where your idea of deterministic functions are called invariant data structures/functions in D; see
http://de.reddit.com/r/programming/comments/6sv8d/Alexandrescu_on_Functional_Programming_in_D_pdf
In a compiled language, is it possible for the compiler to identify such functions and * treat calls to deterministic functions where all of the submitted parameters are constants, as constants within the calling code. (I think this may already happen in C++ if the function is inlined).* identify situations where a second call to a deterministic function will be passing the same values as the preceding call, and compile the second function call as though the user had writtenfloat tmp = Sine(Angle); DoSomething(tmp); DoSomethingElse(tmp); when they had in fact written DoSomething(Sine(Angle)); // Compiler knows that the value of Angle hasn't changed here. DoSomethingElse(Sine(Angle)); ?
Compilers can theoretically do this if you give the compiler enough annotations about which functions are pure and which aren't: the name for the optimisation is common subexpression elimination (CSE). However, the verdict's still out about whether this optimisation is actually useful; at least one paper was written that showed it wasn't very beneficial for Haskell:
http://www.springerlink.com/content/87m4m1294j472456/ http://www.haskell.org/haskellwiki/GHC:FAQbut Haskell's a very different programming language from C/C++, so it's possible that more traditional imperative languages would gain a lot more from CSE than Haskell does. In practice, I don't think any compiler actually does this at all, except for some very basic maths functions.
-- % Andre Pang : trust.in.love.to.save <http://www.algorithm.com.au/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ coders mailing list coders@slug.org.au http://lists.slug.org.au/listinfo/coders
