A fully-assembled Covenant ASG.

Since: 1.0.0

Retrieves the top-level node of an ASG.

Since: 1.0.0

Given an Id and an ASG, produces the node corresponding to that Id.

Important note

This is only safe to use if the Id comes from a node in the argument ASG. Ids valid in one ASG are not likely to be valid in another. 'Mixing and matching' Ids from different ASGs will at best produce unexpected results, and at worst will crash. You have been warned.

Since: 1.0.0

A unique identifier for a node in a Covenant program.

Since: 1.0.0

A general reference in a Covenant program.

Since: 1.0.0

An argument passed to a function in a Covenant program.

Since: 1.0.0

Computation-term-specific node information.

Since: 1.0.0

Value-term-specific node information.

Since: 1.0.0

A single node in a Covenant ASG. Where appropriate, these carry their types.

Since: 1.0.0

Helper data type representing the type of any ASG node whatsoever.

Since: 1.0.0

Produces the type of any ASG node.

Since: 1.0.0

Any problem that might arise when building an ASG programmatically.

Since: 1.0.0

A tracker for scope-related information while building an ASG programmatically. Currently only tracks available arguments.

Important note

This is a fairly low-level type, designed specifically for ASG construction. While you can do arbitrary things with it, changing things in it outside of the functionality provided by this module is not recommended, unless you know exactly what you're doing.

Since: 1.2.0

A concrete monadic stack, providing the minimum amount of functionality needed to build an ASG using the combinators given in this module.

Since: 1.0.0

Possible errors resulting from applications of arguments to functions.

Since: 1.0.0

Ways in which the renamer can fail.

Since: 1.1.0

Ways in which the un-renamer can fail.

Since: 1.2.0

Indicates that we tried to instantiate a polymorphic data type using a type whose encoding is incompatible. The most common case of this is when we have a 'polymorphic' data type that uses some kind of Data encoding and we try to instantiate it with a type which has a SOP encoding.

Since: 1.2.0

An error that can arise during the construction of an ASG by programmatic means.

Since: 1.0.0

Wrapper around an Arg that we know represents an in-scope type variable. @since 1.2.0

Given a DeBruijn index (designating scope) and positional index (designating which variable in that scope we are interested in), retrieve an in-scope type variable.

This will error if we request a type variable in a scope that doesn't exist, or at a position that doesn't exist in that scope.

Since: 1.2.0

Given a scope and a positional argument index, construct that argument. Will fail if that argument doesn't exist in the specified scope, or if the specified scope doesn't exist.

Since: 1.0.0

Construct a node corresponding to the given Plutus primop.

Since: 1.0.0

As builtin1, but for two-argument primops.

Since: 1.0.0

As builtin1, but for three-argument primops.

Since: 1.0.0

As builtin1, but for six-argument primops.

Since: 1.1.0

Given a reference to a thunk, turn it back into a computation. Will fail if the reference isn't a thunk.

Since: 1.0.0

Given a desired type, and a computation which will construct a lambda body when executed (with the scope extended with the arguments the functions can expect), construct a lambda.

Important note

This combinator works slightly differently to the others in this module. This is required because, due to hash consing, an ASG is typically built 'bottom-up', whereas function arguments (and their scopes) are necessarily top-down. Thus, we need to 'delay' the construction of a lambda's body to ensure that proper scoped argument information can be given to it, hence why the argument being passed is an m Ref.

Since: 1.2.0

Construct the error node.

Since: 1.0.0

Construct a node corresponding to the given constant.

Since: 1.0.0

Given an Id referring to a computation, build a thunk wrapping it. Will fail if the Id does not refer to a computation node.

Since: 1.0.0

Introduce a data constructor.

The first argument is a type name (for example, "Maybe"). The second argument is a constructor of that type (for example, "Just" or "Nothing"). The third argument are the values to 'fill in' all the fields of the constructor requested.

Note

dataConstructor yields thunks, which must be forced, and then possibly have type arguments applied to them. The reason for this is subtle, but important. Consider the Nothing constructor of Maybe: as this has no fields, we cannot use the field type to determine what the type argument to Maybe should be in this case. As datatype terms are values, they do not bind type variables, and thus, we cannot have a return type that makes sense in this case.

We resolve this problem by returning a thunk. In the case of our example, Nothing would produce a . !Maybe a.

Since: 1.2.0

Performs both term and type application. More precisely, given:

• An Id referring to a computation; and
• A Vector of Refs for the desired term arguments to the computation, in order; and
• A Vector of (optional) type arguments to the computation, also in order.

we produce the result of that application.

This can fail for a range of reasons:

• Type mismatch between what the computation expects and what it's given
• Too many or too few arguments
• Not a computation type for Id argument
• Not value types for Refs
• Renaming failures (likely due to a malformed function or argument type)

Note

We use the Wedge data type to designate type arguments, as it can represent the three possibilities we need:

• 'Infer this argument', specified as Nowhere.
• 'Use this type variable in our scope', specified as Here.
• 'Use this concrete type', specified as There.

Since: 1.2.0

Given a Ref to an algebra (that is, something taking a base functor and producing some result), and a Ref to a value associated with that base functor, build a catamorphism to tear it down. This can fail for a range of reasons:

• First Ref is not a thunk taking one argument
• The argument to the thunk isn't a base functor, or isn't a suitable base functor for the second argument
• Second argument is not a value type

Note

cata cannot work with non-rigid algebras; that is, all algebras must be functions that bind no type variables of their own.

Since: 1.1.0

Perform a pattern match. The first argument is the value to be matched on, and the second argument is a Vector of 'handlers' for each possible 'arm' of the type of the value to be matched on.

All handlers must be thunks, and must all return the same (concrete) result. Polymorphic 'handlers' (that is, thunks whose computation binds type variables of its own) will fail to compile.

Since: 1.2.0

Constructs a datatype value at given constructor. This is different to dataConstructor, as it doesn't produce a thunk.

The third argument is a Vector of values to 'fill in' all the fields required by the stated constructor. The fourth argument is a Vector of 'type instantiations', which allow 'concretification' of any lingering polymorphic type variables which are not determined by the field values given as the third argument.

Example

Consider Left 3. In this case, the field only determines the first type argument to the Either data type, and if we used dataConstructor, we would be left with a thunk of type a . !Either Integer a. Using ctor, we can immediately specify what a should be, and unwrap the thunk.

Since: 1.2.0

As lam, but produces a thunk value instead of a computation.

Since: 1.2.0

Helper to avoid using fromList when defining data types.

Since: 1.2.0

A standard collection of types required for almost any realistic script. This includes non-'flat' builtin types (such as lists and pairs), as well as all types required by the ledger (including types like Maybe).

Since: 1.1.0

Executes an ASGBuilder to make a 'finished' ASG.

Since: 1.0.0

The environment used when 'building up' an ASG. This type is exposed only for testing, or debugging, and should not be used in general by those who just want to build an ASG.

Since: 1.2.0