How does 'profiles' compare to 'effects'?
mnicolella opened this issue · comments
Hi,
I'm curious how the idea of "profiles" intersects with ideas about specifying or restricting "side effects" that code can use
For example, I might be trying to develop code that can be executed in parallel. To that end, I mark up an entry point function with some kind of annotation that restricts that function from reading or writing from global systems or through pointers. Additionally, I only want to be able to call functions that have the same restrictions (or if their implementation is visible, that verify as safe in the same way).
This seems pretty similar to the idea of annotating code such that it is "arithmetic safe" or "memory safe", just with different requirements of the code.
Is the idea here for users to be able to create their own "profiles" where they can mix and match turning on/off particular language features? Or are we only trying to chase profiles that enforce specific kinds of safety that we think can get standardized?
The current profiles proposals do not include a C++ effect system, i.e., a way of annotating functions and scopes with the effects that prevent a function from being referentially transparent. If there was a comprehensive C++ effect system that could be used to mark effects, then it could be possible to have an "effect safe" profile guarantee on the source code (enforcing the rules regarding all the source code using effect annotations where necessary). I believe that functionality would provide a great benefit to the C++ language.
The Lifetime Safety profile (with the design specification ) is closest to the idea of an effect system, by tracking "reference" effects (references to data not owned) for the purpose of warnings when C++ references or C++ pointers refer to invalid memory locations. However, the Lifetime Safety profile is focused on providing the warnings (added to the C++ compiler implementation) and not tracking the effect as an annotation. A "reference" effect does impact whether code can be executed in parallel, so it is related to source code being reenterant (i.e., "thread safe").
I did create a C++ runtime effect system to explore the possible effects in C++ and how to categorize them at https://github.com/okeuday/effects/ , to communicate how a comprehensive effect system could be structured for C++ (partly based on "Function Effect Tags" in the ATS2/Postiats programming language ). A dependable effect system is enforced by the compiler, so that repository is only meant to consider the idea.