search

AmpersandTarski / Ampersand

Build database applications faster than anyone else, and keep your data pollution free as a bonus.
http://ampersandtarski.github.io/
GNU General Public License v3.0
40 stars 8 forks source link

Compile-time evaluation of enforcement rules #1426

Open stefjoosten opened 11 months ago

stefjoosten commented 11 months ago

Problem

In an Ampersand script with enforcement rule R, I can reason as if R is always true because the exec engine keeps it true at all times. However, the compiler may signal violations of R that are caused by the fact that the compiler does not evaluate enforcement rules. These violations take time to diagnose and defer my attention. Besides, they force me to run a prototype, to check which violations are 'for real' and which violations are caused by not evaluating enforcement rules.

Requirement

As an Ampersand developer, I want the compiler to evaluate all enforcement rules at compile time.

Complication

I acknowledge that this feature may result in infinite loops. For this reason, we need an option on the compiler that limits the number of iterations of the exec engine.

Suggestion

I suggest we make an option [--[no-]exec [INT]]. Examples: If I specify --exec 10, the exec engine will make 10 iterations. If I specify --exec or if the option is absent, the exec engine will iterate until there is nothing more to do, so this option may cause infinite loops. If I specify --no-exec (or --no-exec INT) the exec engine will not do anything, so the compiler will terminate with certainty.

hanjoosten commented 11 months ago

The suggested option is at the wrong place. The Ampersand compiler doesn't know anything about the exec engine. If the number of exec rounds is to be configured, this should be done at the prototype level, or even at runtime. So I think this should be something to configure there.

hanjoosten commented 11 months ago

IFF this requirement is indeed to be done at compile time, the exec engine must be built into the compiler. This will lead to much duplicate functionality, and is therefor an expensive solution. Worse, that solution would at best tell something about rules in combination to the initial population. It will not prevent rule violations from happening, and most certainly it would not prevent such issues to manifest themselves at runtime. That is why I oppose to solve this in the compiler.