Store mutable indirections in immutable data with this one weird trick!

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Sat Nov 13 21:26:46 UTC 2021


On Saturday, 13 November 2021 at 18:55:11 UTC, Dukc wrote:
> Not at all. He suggested having the compiler to catch the 
> mistakes, not the runtime.

He argued against using identity and relying fully on content, 
that is crazy expensive in common situations/algorithms.

This is not practical in a language where you expect to use 
library abstractions. As such, you end up not being able to use 
"pure" for anything that is non-trivial.

> I'm assuming you mean that the language would allow caching 
> values even with arguments with mutable indirection, if the 
> compiler can prove they are similar to an earlier call.

If we want the programmer to use "proper purity" for caching 
values in libraries then it should be a separate construct that 
is enforcing norms on the program that are stronger than the 
regular "weakly pure". It should have a different syntax and very 
clear normative standards so people understand the difference. 
Meaning dealing rigorously with termination, nontrivial 
destructors, exceptions, allocations etc etc. If not able to deal 
with it rigorously: ban those constructs. Compiler type system 
should err on the side of correctness.

If you want the compiler to cache values, then it should just be 
based on static analysis of weakly pure. Compiler optimisation 
should err on the side of correctness.

But saying that "weakly pure" syntax with immutable input is 
providing a different set of semantics that somehow evolve over 
time on some sort of slippery slope is likely to lead up to a 
mess.

Just stick to the keyword ```pure``` meaning "no globals", and 
leave it at that. Want more? Introduce a new well defined concept.



More information about the Digitalmars-d mailing list