Comments on: Functional D: Is Transitive Const Fundamental?

By: Hans-Eric

Hans-Eric — Thu, 31 Jul 2008 14:34:25 +0000

I am bound to agree with you, now that I finally understood

By: mort

mort — Thu, 31 Jul 2008 13:22:37 +0000

I think it’s actually pretty intuitive if you define pure to mean ‘a function completely determined by the value of its parameters’, and think of the parameters as defining deep values. Then if those values are being mutated concurrently, it makes sense that you lose determinism.

Actually I think the current proposal for ‘pure’ is pretty broken for the reasons mentioned above: pure functions aren’t usable on mutable values and mutable functions can’t be used on the local mutable values inside pure code. That thread I linked to is many months old - I wonder if they’ve addressed this…

By: Hans-Eric

Hans-Eric — Thu, 31 Jul 2008 10:19:09 +0000

Now I (finally) see where you’re driving at. You want to allow for what Bruno Madeiros (in the news thread you provided) call “partially pure” functions along with pure (the compiler would have to figure out which is which, which is trivial).
Interesting concept.
The only disadvantage I can think of, and it’s a minor one, is that programmers might think they’re writing thread-safe code when they’re not. Partially pure functions are only thread-safe when invoked from within a truly pure function; at top-level on the other hand, they’re not.

By: mort

mort — Thu, 31 Jul 2008 09:05:37 +0000

If a pure function’s parameters are marked as const, then they can change. Agreed, that’s the point - it allows you to operate on mutable data. If you want to require invariance of the data, you use ‘invariant’ to specify that. Trying to come up with a scheme for specifying things as ‘temporarily immutable’ looks like a can of worms to me.

The other benefit of allowing pure non-invariant functions is that you can write pure helper functions that do mutate their arguments. With only pure invariant functions, if you do local mutations on the stack in a pure (invariant) function, there is no way to factor those mutations out into functions. So you may find yourself cutting/pasting code. That seems like a pretty bad situation.

By: Hans-Eric

Hans-Eric — Thu, 31 Jul 2008 08:23:26 +0000

If the parameters are marked as invariant, mutability can not leak, but - and that was my point - if they are merely marked as const there is a possibility that someone else changes the data while the pure function is executing (in a different thread). Thus, pureness requires invariant arguments.
You have a (contrived) code example that highlights this in my first reply.

By: mort

mort — Wed, 30 Jul 2008 21:50:18 +0000

Ok, I just found a thread on the D forums discussing this very idea. You can find it here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=70762

I didn’t see any compelling arguments against it in skimming the thread. One thing I think you’d need is to generalize the rules if you wanted to allow nested pure functions: I think they shouldn’t be able to access any non-invariant data from their environment (including globals and variables in scope).

By: mort

mort — Wed, 30 Jul 2008 21:36:17 +0000

If you have a function marked pure (in my sense) whose parameters are also marked invariant (or even just const), how can mutability leak in? Obviously you can create *local* mutable state (on the stack), but according to Andrei Alexandrescu’s slides, you’ll be able to do that even if a function is marked pure in your sense. But I don’t see how you can get past the parameters being invariant to do anything undesirable. Can you give a code example?

By: Hans-Eric

Hans-Eric — Wed, 30 Jul 2008 21:01:57 +0000

Ok, I didn’t get that (I’m a bit slow at times ). But if one does what you suggests (pure keyword that only forbids global state access and calls to non-pure functions) there is nothing that stops a programmer from passing references to mutable data. In that case mutability “leaks” through to the pure function. Thus we end up with a function marked as pure, that can not be safely considered pure by the compiler. (Am I making any sense? Have I still not gotten your idea? Sorry if that’s the case, It’s rather late here now and my brain feels like jelly)

There’s not much documentation to be found on the subject, but here’s a couple of links you could check out:

http://www.digitalmars.com/d/2.0/function.html (Pure Functions)
http://www.digitalmars.com/d/2.0/const3.html (Const and Invariant)
And of course the links I gave in the article.

Best regards

By: mort

mort — Wed, 30 Jul 2008 20:40:05 +0000

Hi. I think I didn’t get one idea across. I’m suggesting we keep the ‘pure’ keyword, but all it does is forbids access to global state and calls to non-pure functions. So I don’t think your response to 3) applies to my proposal. Figuring out that a function is pure (in your sense) is trivial: it’s marked pure *and* it’s parameters are marked invariant.

Thus pure in my sense subsumes pure in yours, and is orthogonal to invariance of parameters (rather than implying invariance).

Regarding the optimizations that can be applied, I would observe that nothing is stopping the compiler from specializing every pure function to a faster version that’s pure in your sense if all arguments are known to be invariant.

I look forward to reading more about this topic in the future - I’ve bookmarked your page :). BTW, is there a source you can link to for additional information on the semantics of ‘pure’ in D? Thanks!

By: Hans-Eric

Hans-Eric — Wed, 30 Jul 2008 16:46:27 +0000

Hi again, excellent points. I’ll try to address them.

1) It wouldn’t differ a bit, and that’s my point. Pure functions has the wonderful property of being thread-safe, without you needing to be “careful about thread safety”. If you allow const arguments to pure functions then they are no longer pure, and you lose the thread-safety.

2) This is absolutely true. The problem is that since a then can be used in both situations the compiler can not assume it’s free of side-effects and can not make optimizations (like automatic multi-threading) based on the thread-safety property.

3) True, but the compiler will have a hard time figuring out whether a is thread-safe or not unless you help it (with the pure keyword that enforce the pure function rules). It’s not enough to look for invariant arguments, all contained function calls and access of global state must also be considered, deeply. Furthermore, the programmer gets no help from the compiler to make the code thread-safe, which is one of the big advantages of pure functional languages.

4) This is definitely a problem for complex types. I guess there has to be some way to implicitly convert mutable types to immutable ones, but I see several problems with this. I will dig into this subject in a coming post so please stay tuned.