Hacker News Reader

Comment by Gibbon1 | Hacker News Reader

I wonder does that mean you could also enforce freeing memory allocated by a pure function as well?

I'm not sure what you mean?

Allocators are often pure in D, they probably shouldn't be but that would mean allocating outside the function which would be ugly and probably buggy too

Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do.

Forgive me I'm just a small brained firmware programmer.

So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.

So where do we draw the line? Of course, no real computer implementation of any language is going to be able to generate fundamentally pure code because in the end they're going to be mutating memory (at the very least the program counter).

That's not a very useful distinction, and usually one talks about "purity" at a conceptual level. The language provides a layer of abstraction in which things can be considered pure (or not), even if the underlying implementation e.g. makes optimizations that require mutation. The language is just a guarantee that you can ignore these aspects of its implementation.

I think that is a good point at the end. Pure may be defined in regards to the language. So allocating memory in C may make a function unpure but something other languages may still be pure.

Rolling it over I think vaguely along the idea that marking a function as pure is a contract that tells the compiler that the function and it's call tree ultimately shouldn't modify external state.

A function that allocates memory isn't pure, except perhaps iff it frees that memory either itself or by compiler magic. Then perhaps it is.

Reply on news.ycombinator.com