forcing weak purity

[H. S. Teoh]

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.