You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because I keep getting confused on how this is implemented, here's some doc that's relevant at the moment of this writing.
We use the following struct in kimchi:
pubstructFeatureFlags<F>{/// ChaCha gatespubchacha:bool,/// Range check gatespubrange_check:bool,/// Foreign field addition gatepubforeign_field_add:bool,/// Foreign field multiplication gatepubforeign_field_mul:bool,/// XOR gatepubxor:bool,/// Lookup featurespublookup_features:LookupFeatures,/// Lookupspublookup_configuration:Option<LookupConfiguration<F>>,}
passing it to the setup is optional. If it is passed, kimchi will check each feature and:
a feature that's set means that a constraint will be created (it's enabled)
a feature that's not set means that a constraint will not be created (it's disabled)
fair enough? On the other hand, if we don't pass this FeatureFlags struct, it means that we want to decide things at runtime. And so constraints will be generated and wrapped by a special EnabledIf(FeatureFlag::TheFeature, _) (and an alpha element will be reserved for each of them)
Later at runtime, we can decide if we're enabling this or not.
I believe we don't use this feature to really do compile time vs runtime things, but rather in the generation of OCaml code and the toggling of things on the OCaml side. Perhaps though, this feature will make sense in Rust as well one day.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Because I keep getting confused on how this is implemented, here's some doc that's relevant at the moment of this writing.
We use the following struct in kimchi:
passing it to the setup is optional. If it is passed, kimchi will check each feature and:
fair enough? On the other hand, if we don't pass this
FeatureFlags
struct, it means that we want to decide things at runtime. And so constraints will be generated and wrapped by a specialEnabledIf(FeatureFlag::TheFeature, _)
(and analpha
element will be reserved for each of them)Later at runtime, we can decide if we're enabling this or not.
I believe we don't use this feature to really do compile time vs runtime things, but rather in the generation of OCaml code and the toggling of things on the OCaml side. Perhaps though, this feature will make sense in Rust as well one day.
Beta Was this translation helpful? Give feedback.
All reactions