| |||||||||||||
Implications of pure and constant functionsImplications of pure and constant functionsPosted Jun 11, 2008 1:40 UTC (Wed) by rsidd (subscriber, #2582)Parent article: Implications of pure and constant functions
As MisterIO points out, the statement "pure functions cannot be constant functions" is obviously wrong. Another point: in a language like C, surely the pureness of a function depends on all the other functions in a program? For example, you say (accurately, as far as the definition of "pure" goes): "Because the global memory state remains untouched, two calls to the same pure function with the same parameters will have to return the same value." Your example is the strlen() function. But what if some other function has tampered with the contents addressed by your pointer in between the two calls, without modifying the pointer itself? You hint at this issue later when you say of an example: "(The pure function is called just once) because there was no change to global memory known to the compiler between the two calls of the pure function." So the compiler needs to determine whether the memory addressed could have changed. This is not always possible, unless the compiler decides that any intervening non-pure function call could have changed the memory addressed -- a drastic assumption since in practice most such calls are probably harmless. My take is, if you care about pure functions, use Haskell :)
(Log in to post comments)
Implications of pure and constant functions Posted Jun 11, 2008 2:21 UTC (Wed) by droundy (subscriber, #4559) [Link] Indeed, the article should have stated that two consecutive calls to the same pure function with the same arguments will give the same result, that's the difference between pure and constant functions (constant functions always return the same for the same input). With regard to your suggestion to just use Haskell, I'd point out that ghc doesn't support CSE. I love Haskell, and it's a great language, but this sort of optimization is not one of its strengths. Laziness interferes with its strengths as a pure functional language in this case. The trouble is that it's hard to determine when using the memory to store the result of a computation is worth paying to avoid recomputing it. For primitive data types the answer is obvious, and we should do CSE, but ghc doesn't perform that analysis, and even if it did, I wouldn't be happy with a CSE pass that only worked on functions returning Int/Double/Bool etc. Of course, dead code elimination comes for free in Haskell, so that does gain us something. But as the article points out, it's really only useful for things like conditional compilation, which is much less of a gain than CSE.
Implications of pure and constant functions Posted Jun 11, 2008 6:45 UTC (Wed) by nix (subscriber, #2304) [Link] A classic example of a common class of functions that can't be optimized over even though you'd think it could be is *printf(). Standard printf() without %n can be freely optimized over, but alas glibc has an extension (user-defined format masks) that means printf() can call arbitrary functions for you. That nobody ever uses this extension is irrelevant: the compiler must assume that you might be.
|
|||||||||||||