Clarify referential transparency

[grumpyrodriguez]

F# newbie/learner here. Came across ply while following discussions about the performance of Async. Can we assume ply provides a referentially transparent representation of Tasks since it is based on computation expressions? If yes, it sounds like best of both worlds, performance and purity. Worth making this point in the introduction document.
I'd love to learn the answer to the question anyway. Many thanks for making this work open source. Looking forward to experimenting with it.

[NinoFloris]

@grumpyrodriguez sorry for the long silence here.

Let me just get to the meat of your question :)

ply provides a referentially transparent representation of Tasks

As Tasks are values and capable of storing the result of any computation they can be used in a referentially transparent manner - but this is not enforced in any way. As long as computations are pure you would be able to replace those Tasks that have to compute a value with Tasks storing this same value.

In any case Task and Task<'t> give no guarantees on purity and are entirely incapable of restricting side effects (producing side effects is even the main role, non generic, Task plays). Creation of the Task and computation (of the value, if any) are tightly bound together for Task, which is why it's known to be an eager/hot primitive. Async does a bit better here in the sense that it's an immutable construct which composes lambdas to compute values with at a later point but again, no guarantees on purity of the lambdas.

I can't say I've ever felt the need for a guarantee of purity applied to all code - we are able to make great software without it - and quite often we can conclude it's actually not so necessary. When we do actually need some guarantees we can always fall back on human discipline and working through the code (which we must for most of our work anyway).

On top of that, even if you really wanted to, unbridled impurity is the result of working in a language and ecosystem (.NET) that does not have - or for that matter really wants - any mechanisms for signifying and enforcing purity, countless apis like DateTime.Now building on constructs like static fields would have to change and as this is so unlikely to happen it's better to conclude this ship has long past sailed.

Either way, thanks for your question and happy coding!

[grumpyrodriguez]

A very late thank you @NinoFloris Some interesting points there. I especially liked your comments on purity in .NET. I'm realising that type safety is the real win for me in most cases and I can live with impurity. Your comments fit my current frame of thinking.
Happy coding to yourself and thanks for taking the time to respond!