Safe Haskell | Safe-Inferred |
---|---|
Language | Haskell2010 |
Synopsis
- isPure ∷ (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → Bool
- isSaturated ∷ ∀ tyname name uni fun a. ToBuiltinMeaning uni fun ⇒ BuiltinsInfo uni fun → fun → AppContext tyname name uni fun a → Maybe Bool
- isWorkFree ∷ (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → Bool
- data EvalOrder tyname name uni fun a
- unEvalOrder ∷ EvalOrder tyname name uni fun a → [EvalTerm tyname name uni fun a]
- data EvalTerm tyname name uni fun a
- data Purity
- = MaybeImpure
- | Pure
- termEvaluationOrder ∷ ∀ tyname name uni fun a. (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → EvalOrder tyname name uni fun a
Documentation
isPure ∷ (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → Bool Source #
Will evaluating this term have side effects (looping or error)? This is slightly wider than the definition of a value, as it includes applications that are known to be pure, as well as things that can't be returned from the machine (as they'd be ill-scoped).
isSaturated ∷ ∀ tyname name uni fun a. ToBuiltinMeaning uni fun ⇒ BuiltinsInfo uni fun → fun → AppContext tyname name uni fun a → Maybe Bool Source #
Is the given application saturated? Returns Nothing
if we can't tell.
isWorkFree ∷ (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → Bool Source #
Is the given term 'work-free'?
Note: The definition of 'work-free' is a little unclear, but the idea is that evaluating this term should do very a trivial amount of work.
data EvalOrder tyname name uni fun a Source #
The order in which terms get evaluated, along with their purities. We use a DList here for efficient and lazy concatenation
Instances
PrettyBy config (Term tyname name uni fun a) ⇒ PrettyBy config (EvalOrder tyname name uni fun a) Source # | |
Monoid (EvalOrder tyname name uni fun a) Source # | |
Semigroup (EvalOrder tyname name uni fun a) Source # | |
Defined in PlutusIR.Purity (<>) ∷ EvalOrder tyname name uni fun a → EvalOrder tyname name uni fun a → EvalOrder tyname name uni fun a Source # sconcat ∷ NonEmpty (EvalOrder tyname name uni fun a) → EvalOrder tyname name uni fun a Source # stimes ∷ Integral b ⇒ b → EvalOrder tyname name uni fun a → EvalOrder tyname name uni fun a Source # |
unEvalOrder ∷ EvalOrder tyname name uni fun a → [EvalTerm tyname name uni fun a] Source #
data EvalTerm tyname name uni fun a Source #
Either the "next" term to be evaluated, along with its Purity
and WorkFreedom
,
or we don't know what comes next.
Is this pure? Either yes, or maybe not.
termEvaluationOrder ∷ ∀ tyname name uni fun a. (ToBuiltinMeaning uni fun, HasUnique name TermUnique) ⇒ BuiltinsInfo uni fun → VarsInfo tyname name uni a → Term tyname name uni fun a → EvalOrder tyname name uni fun a Source #
Given a term, return the order in which it and its sub-terms will be evaluated.
This aims to be a sound under-approximation: if we don't know, we just say Unknown
.
Typically there will be a sequence of terms that we do know, which will terminate
in Unknown
once we do something like call a function.
This makes some assumptions about the evaluator, in particular about the order in which we evaluate sub-terms, but these match the current evaluator and we are not planning on changing it.