Lambda the Ultimate

There is a presentation from 2010 by by Philipp Haller and Martin Odersky: "Capabilities for Uniqueness
and Borrowing"

The Pony language may have something similar. They have a paper: "Deny Capabilities for Safe, Fast Actors".

I appreciate you sharing the links. The Pony language concept of deny capabilities does seem related. For the record I have started submitting code to the repo that uses Roslyn to detected whether C# code is "Platonic", and I made some updates to the rules.

An interesting observation is that while pure methods are easily identified and classified, there are two types of non-referentially transparent methods (those with side-effects) that can still be considered Platonic. Those that update the "this" instance, and those that accept an argument of a type that is considered "immutable".

I'm not sure at this point what to call the two categories of effectful methods.

Recall that Command-query separation (CQS) was devised by Bertrand Meyer to segregate those methods that are idempotent and side-effect free from those that have side-effects.

There is also something called Command-Responsibility Separation (CRS) that I think was introduced by Vaughn Vernon in one of his books. That approach suggests that command methods should only modify the state of the target object and not have any side effects beyond it.

I think the 3rd category you mention: side-effects beyond the target object actually implies a 4th category of methods:

But if we take a step back and recall the Single Responsibility Principle (SRP) then the answer here would be: "Don't do that". If your language was able to enforce the SRP, what would that look like?

Thanks for the table, and the pointer to Meyer and Vernon's work.

So in the proposed terminology for Platonic C# we have two attributes:

[ImpureWrite] => updates (mutates) self
[ImpureEffect] => uses a type which can be mutated

As you suggest we could have a function that does neither (is Pure) and a function that does both.

Preventing a user from combining both in a single function is exactly what I was planning to do. I can see no ill-effect from it. If some-one wants to do both things, they have to make two separate method invocations. Which is probably a "good thing".