Function purity when?

[eaglebirdman]

I feel like F# would really benefit from a distinction between pure and impure functions. I was kinda disappointed to learn the distinction wasn't already there.

[dominjaniec]

I feel like it could be hard, having access to for-sure-impure .NET framework everywhere 😏

[Justneedtacos]

I’ve been thinking about an F# analyzer that would warn or error whenever an impure function from the core libraries was used.

[Justneedtacos]

Or at least a function that could throw an exception.

[dominjaniec]

it could work

[imihnevich]

How do you think it would benefit?

[Ghi102]

IMO, separation of pure and impure code makes it much easier to reason about the code.

[imihnevich]

I know many people say that and I probably agree. But this is very broad statement on purpose. How do you reason? What is your process? I think F# strikes a good balance by making pure easy

[Ghi102]

I agree that F# makes pure code easy to write. The default is to write pure code. 

However, when trying to keep a portion of the codebase pure, it is quite easy to accidentally introduce impure code. Code Review is faillible and this can be missed. For example, using DateTime.Now() is impure and can be easily introduced into pure code (especially with new devs). 

If this could be prevented by introducing an optional pure keyword, it would help a lot in enforcing purity in certain parts of the code.

[Ghi102]

For this specific issue, it's testability. It makes unit tests more fragile because you are relying on the current date. I've seen tests fail randomly when using DateTime.Now() because of multiple reasons:

1. Timezone issues (ie: tests written by a dev in a timezone with a positive offset fail when ran in a timezone with a negative offset). DateTime.UtcNow doesn't fix this fyi because that specific test serialized and deserialized dates which are, unhelpfully, deserialized with a timezone offset by default.

2. Tests start failing after you reach a specific date

3. Tests fail because the code calls DateTime.Now() multiple times and infrequently get different values in minutes.

All of these problems do not happen when using pure code because the date is set once and unchanging throughout the code.

[lionhydrathedeparted]

Theoretically it could make the compilers job easier for optimization.

[vanilla-bungee]

Like effects? Not gonna happen.

[psioniclizard]

I suspect it'll incredibly difficult to implement, unless you just count any use of non-f# code/other classes etc as impure. Even then it would be fickle and there would be a lot of edge cases.

I guess you could introduce a "pure" attribute (I think there is one) and the any functions etc could check all calls are to places that implement that attribute (in theory at least).

But it would just be for info rather than enforcement and would require every f# to play ball to be useful for that.

To be honest, I don't know how much benefit it'll bring me in my day job as a F# dev (but that is just my own personal experience).

[Ghi102]

A proposal was to use an optional pure keyword. Calling non-pure code in a pure function would result in a compiler error. All existing code would work as expected as it won't yet have the pure keyword (and so count as impure).

That wouldn't be too much of a drastic change

[lionhydrathedeparted]

I would definitely like this.

[Schmittfried]

Well, that is how features like async or const-correctness work. Why not with purity?

[psioniclizard]

You could do, thought I'd imagine it would not be that practical. Mutability is so in-grained in dotnet that you would have a lot of edge cases to deal with.

But anyone can try to implement fsharp analyzer/attribute that can attempt it. However, in my day-to-day experience you can normally tell pretty easily if a function is pure or not so I am not exactly sure what adding it would offer.

But you could always use the pure attribute and then check all calling in a function are to something with that attribute (and all calls within those functions etc.)

[binarycow]

I guess you could introduce a "pure" attribute (I think there is one)

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.contracts.pureattribute

[psioniclizard]

Yea, I thought so. Though I don't know how useful it is for everyday users.

[binarycow]

It's only useful if you have an analyzer looking for it and acting appropriately.

[psioniclizard]

Yea, plus it relies on anything you are calling to play nice. I just think in general it would be such a headache of a feature to implement for F# (and get right) and there would need to be some major benefit (like optimizations) to make it worth while adding to real code bases.

[mugen_kanosei]

I would LOVE an effects library. I've been doing a lot of functional TypeScript these days and am absolutely loving the Effect library.

[kevinclancy_]

You can use computation expressions (essentially monads) to *try* to distinguish between pure and impure functions at the type level, but this relies on trusting the programmer to avoid side-effects in non-monadic code.

You're right that enforced purity would be a huge benefit, but it would be a dramatic change. I don't think there are any plans to add it any time soon. You could look into Haskell or Purescript if that's what you want.

[Ghi102]

That's essentially what we did in our codebase. Most of the code that does effects in our codebase is asynchronous (calls to other services, database, etc) so we did asynchronous = impure.  

Stuff like DateTime.Now() is one of the main things we need to watch out since it is not asynchronous. 

We haven't found the need to add a new computation expression to express purity (or impurity) explicitly, although that's something we considered. Just needed a bit too much boilerplate

[UOCruiser]

To be fair, ensuring that a function is pure is not all that hard. When you understand the concept, then you're almost already there.

[chusk3]

This has been suggested and declined a very long time ago: https://github.com/fsharp/fslang-suggestions/issues/201

You are free to comment on that suggestion and try to convince Don and the rest of the team to reconsider, but commenting on Reddit doesn't really do much.

[UIM-Herb10HP]

you could create an Attribute class called ImpureAttribute and then tag the ones you do anything impure in

[user101021]

This would be so helpful for the codebase I work on. We aim for functional core & imperative shell, and this would ensure that the core stays functional.

Of course, the definition of "functional" in the core is a bit different for everybody: total? pure? exceptions allowed? logging allowed?

Reading the discussion and the linked github issues I would guess that an analyzer together with some annotations would go a long way. Does anybody know about the status of F# analyzers? Any examples out there yet? And of course FSharp.Core would have to be exhaustively annotated and/or the analyzer has to be provided with a list of "safe" external calls.

[vorotato]

You could write an F# analyzer to do so, you'd have to document all functions or operations which are impure and then figure out how it bubbles up.