changed a year ago  
Linked with GitHub

normalization

underlying concepts

A single "normalization step", resolves an alias to its underlying, potentially non-rigid value.

future possibilities

normalizes-to: 1 or more normalization steps until rigid

A NormalizesTo consists of two steps. It first applies a single normalization step and then emits a nested NormalizesTo goal for the resulting value. This nested NormalizesTo has to be inside of a commit_if_ok in case the returned alias is rigid.

  • NormalizesTo(NormalizesToRigid)
    • normalization step results in RigidAlias
    • commit_if_ok:
      • continue normalizing returned alias: NormalizesTo(RigidAlias) ~> Err(NoSolution)
    • return RigidAlias

AliasRelate has to also wrap NormalizesTo in a commit_if_ok in case the alias is already rigid.

normalizes-to: 0 or more normalization steps until rigid

A NormalizesTo uses 1 to inf step normalization inside of a commit_if_ok, returning the unnormalized alias in case one step normalization fails

  • NormalizesTo(NormalizesToRigid)
    • commit_if_ok[1]:
      • normalization step results in RigidAlias
      • continue normalizing returned alias: NormalizesTo(RigidAlias)
        • commit_if_ok:
          • is rigid ~> Err(NoSolution)
        • returns Ok(RigidAlias)
      • returns Ok(RigidAlias)
    • returns Ok(RigidAlias)

AliasRelate does not need to wrap NormalizesTo in a commit_if_ok.

  1. as we merge candidates inside of this commit_if_ok, in case one step normalization returns Err(NoSolution), it instead simply returns the rigid alias. ↩︎

Select a repo