On Thu, May 24, 2012 at 08:56:25AM -0400, Steven Schveighoffer wrote: [...]
> The more I think about it, the more I believe that what gc_collect does (i.e. run a full collect, or run a pure-function specific collect) is an implementation detail.
[...]

I agree.

Purity only exists at a certain level of abstraction. Even "completely pure" languages like Haskell are ultimately compiled into machine code that modify pointer memory, do pointer arithmetic, and all sorts of other "impure" operations. Yet at a certain level of abstraction, that is, at the language-level abstraction, all functions are still pure. Purity is not violated because the "impure operations" are part of the Haskell runtime, which expose a pure interface to the programmer. IOW, the impure operations are implementation details.

So it's unreasonable to require that all low-level operations be pure. At a certain level, the D runtime has to do "impure", or low-level operations. That doesn't mean stuff built on top of the runtime can't be pure. I would argue that since the GC is part of the runtime, it should be regarded as part of the "implementation details" that are allowed to do "impure" operations, as long as the runtime itself provides an API that abstractly exposes a pure system.

In that sense, I think that things like triggering a GC collection, etc., are just an implementation detail. We explicitly trigger collection in order to optimize performance. In an ideal world, the compiler would divine how to do this automatically without needing our code to call "impure" GC functions. But we're not in an ideal world, and sometimes we do need to allow pure functions to optimize by hinting to the GC when is a good time to run a collection. I don't think this should violate purity. Otherwise, the notion of purity would be greatly limited in its usefulness.


T

-- 
Bomb technician: If I'm running, try to keep up.