On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
<xtzgzo...@gmail.com> wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
<xtzgzo...@gmail.com> wrote:
Purity inference won't happen either way. Purity is part of your API
and also meant to help you reason about your code. If the compiler
just infers purity in a function and you later change the
implementation so it's no longer pure, you break your users' code.
Also, purity would no longer help you reason about your code if it's
not explicit.
It can be pure for the purposes of optimization without affecting code
whatsoever. Inferred purity can be marked separately from explicit
purity, and explicitly pure functions would not be allowed to call
implicitly pure functions.
-Steve
But that kind of inferred purity is something a compiler back end
cares about, not something the language should have to care about at
all. In practice, most compilers *do* analyze all functions for
possible side-effects and use that information where applicable.
It affects how callers code will be generated.
If I have a function
int foo(int x);
and I have another function which calls foo like:
int y = foo(x) + foo(x);
Then the optimization is applied to whatever function this exists in. If
the source isn't available for foo, the compiler cannot make this
optimization.
I have no idea if this is a back-end or front-end issue. I'm not a
compiler writer. But I do understand that the compiler needs extra
information in the signature to determine if it can make this optimization.
-Steve
OK, point taken; didn't consider that. But in the first place, for
inference of purity to work, the source would have to be available.
Then, that inferred property has to be propagated somehow so that the
compiler can make use of it when linking to the code as a library...
--
- Alex
