Open kind for various field references.

The simplest field reference could be Label, pointing to a field by its name, but we also support more complex scenarios like deep fields identifiers.

For a type-level field reference - an associated term-level representation.

This is similar to singletons Sing + SingI pair but has small differences:

• Dedicated to field references, thus term-level thing has FieldRefKind kind.
• The type of term-level value (FieldRefObject ty) determines the kind of the reference type.

The simplest field reference - just a name. Behaves similarly to Label.

Some kind of reference to a field.

The idea behind this type is that in trivial case (name :: Symbol) it can be instantiated with a mere label, but it is generic enough to allow complex field references as well.

Version of FieldRef restricted to symbolic labels.

FieldSymRef name ≡ FieldName name 'FieldRefTag

Convert a symbolic FieldRef to a label, useful for compatibility with other interfaces.

Convert a label to FieldRef, useful for compatibility with other interfaces.

Provides access to the direct name of the referred field.

This is used in stToFieldNamed.

Provides operations on fields for storage.

Datatype containing the full implementation of StoreHasField typeclass.

We use this grouping because in most cases the implementation will be chosen among the default ones, and initializing all methods at once is simpler and more consistent. (One can say that we are trying to emulate the DerivingVia extension.)

Provides operations on submaps of storage.

Datatype containing the full implementation of StoreHasSubmap typeclass.

We use this grouping because in most cases the implementation will be chosen among the default ones, and initializing all methods at once is simpler and more consistent. (One can say that we are trying to emulate the DerivingVia extension.)

Provides operations on stored entrypoints.

store is the storage containing both the entrypoint epName (note: it has to be in a BigMap to take advantage of lazy evaluation) and the epStore field this operates on.

Datatype containing the full implementation of StoreHasEntrypoint typeclass.

We use this grouping because in most cases the implementation will be chosen among the default ones, and initializing all methods at once is simpler and more consistent. (One can say that we are trying to emulate the DerivingVia extension.)

Type synonym for a Lambda that can be used as an entrypoint

Type synonym of a BigMap mapping MText (entrypoint names) to EntrypointLambda.

This is useful when defining instances of StoreHasEntrypoint as a storage field containing one or more entrypoints (lambdas) of the same type.

Indicates a submap with given key and value types.

Indicates a stored entrypoint with the given param and store types.

Concise way to write down constraints with expected content of a storage.

Use it like follows:

type StorageConstraint store = StorageContains store
  [ "fieldInt" := Int
  , "fieldNat" := Nat
  , "epsToNat" := Int ::-> Nat
  , "balances" := Address ~> Int
  ]

Note that this won't work with complex field references, they have to be included using e.g. StoreHasField manually.

Pick storage field.

Get storage field, preserving the storage itself on stack.

Pick storage field retaining a name label attached.

For complex refs this tries to attach the immediate name of the referred field.

Version of stToFieldNamed that preserves the storage on stack.

Update storage field.

Check value presence in storage.

Get value in storage.

Update a value in storage.

Atomically get and update a value in storage.

Delete a value in storage.

Add a value in storage.

Add a value in storage, but fail if it will overwrite some existing entry.

Extracts and executes the epName entrypoint lambda from storage, returing the updated full storage (store) and the produced Operations.

Pick stored entrypoint lambda.

Get stored entrypoint lambda, preserving the storage itself on the stack.

Stores the entrypoint lambda in the storage. Fails if already set.

Pick the sub-storage that the entrypoint operates on.

Get the sub-storage that the entrypoint operates on, preserving the storage itself on the stack.

Update the sub-storage that the entrypoint operates on.

Simplified version of sopGetFieldOpen where res is ftype.

Simplified version of sopSetFieldOpen where res is ftype.

Implementation of StoreHasField for case of datatype keeping a pack of fields.

Implementation of StoreHasEntrypoint for a datatype keeping a pack of fields, among which one contains the entrypoint and another is what such entrypoint operates on.

Implementation of StoreHasEntrypoint for a datatype that has a StoreHasField for an EntrypointsField that contains the entrypoint and a StoreHasField for the field such entrypoint operates on.

Implementation of StoreHasEntrypoint for a datatype that has a StoreHasSubmap that contains the entrypoint and a StoreHasField for the field such entrypoint operates on.

Implementation of StoreHasField for a data type which has an instance of StoreHasField inside. For instance, it can be used for top-level storage.

Implementation of StoreHasSubmap for a data type which has an instance of StoreHasSubmap inside. For instance, it can be used for top-level storage.

Implementation of StoreHasEntrypoint for a data type which has an instance of StoreHasEntrypoint inside. For instance, it can be used for top-level storage.

Pretend that given StoreFieldOps implementation is made up for field with name desiredName, not its actual name. Logic of the implementation remains the same.

See also storeSubmapOpsReferTo.

Pretend that given StoreSubmapOps implementation is made up for submap with name desiredName, not its actual name. Logic of the implementation remains the same.

Use case: imagine that your code requires access to submap named X, but in your storage that submap is called Y. Then you implement the instance which makes X refer to Y:

instance StoreHasSubmap Store X Key Value where
  storeSubmapOps = storeSubmapOpsReferTo #Y storeSubmapOpsForY

Change field operations so that they work on a modified field.

For instance, to go from StoreFieldOps Storage "name" Integer to StoreFieldOps Storage "name" (value :! Integer) you can use mapStoreFieldOps (namedIso #value)

Change submap operations so that they work on a modified key.

Change submap operations so that they work on a modified value.

Pretend that given StoreEntrypointOps implementation is made up for entrypoint with name desiredName, not its actual name. Logic of the implementation remains the same.

See also storeSubmapOpsReferTo.

Chain two implementations of field operations.

Suits for a case when your store does not contain its fields directly rather has a nested structure.

Chain implementations of field and submap operations.

This requires Dupable substore for simplicity, in most cases it is possible to use a different chaining (nameInStore :-| mname :-| this) to avoid that constraint. If this constraint is still an issue, please create a ticket.

Chain implementations of two submap operations sets. Used to provide shortcut access to a nested submap.

This is very inefficient since on each access to substore it has to be serialized/deserialized. Use this implementation only if due to historical reasons migrating storage is difficult.

LIso (Maybe substore) substore argument describes how to get substore value if it was absent in map and how to detect when it can be safely removed.

Example of use: sequenceStoreSubmapOps #mySubmap nonDefIso storeSubmapOps storeSubmapOps

Turn submap operations into operations on a part of the submap value.

Normally, if you need this set of operations, it would be better to split your submap into several separate submaps, each operating with its own part of the value. This set of operations is pretty inefficient and exists only as a temporary measure, if due to historical reasons you have to leave storage format intact.

This implementation puts no distinction between value == Nothing and value == Just defValue cases. Getters, when notice a value equal to the default value, report its absence. Setters tend to remove the value from submap when possible.

LIso (Maybe value) value and LIso (Maybe subvalue) subvalue arguments describe how to get a value if it was absent in map and how to detect when it can be safely removed from map.

Example of use: zoomStoreSubmapOps #mySubmap nonDefIso nonDefIso storeSubmapOps storeFieldOpsADT

Utility to create EntrypointsFields from an entrypoint name (epName) and an EntrypointLambda implementation. Note that you need to merge multiple of these (with <>) if your field contains more than one entrypoint lambda.

Refer to a nested entry in storage.

Example: stToField (#a :-| #b) fetches field b in the type under field a.

If this syntax seems overly verbose, you can try using OverloadedRecordDot. See module documentation for comments on that.

Refer to no particular field, access itself.

An alias for SelfRef.

Examples:

>>> push 5 # stMem this -$ (mempty :: Map Integer MText)
False

>>> stGetField this # pair -$ (5 :: Integer)
(5,5)

Provides alternative variadic interface for deep entries access.

Example: stToField (stNested #a #b #c)

Alias for a field reference.

This allows creating _custom_ field references; you will have to define the respective StoreHasField and StoreHasSubmap instances manually. Since this type occupies a different "namespace" than string labels and :-|, no overlappable instances will be necessary.

Example:

-- Shortcut for a deeply nested field X
data FieldX

instance StoreHasField Storage (FieldAlias FieldX) Integer where
  ...

accessX = stToField (stAlias @FieldX)

Note that alias type argument allows instantiations of any kind.

Construct an alias at term level.

This requires passing the alias via type annotation.

Kind-restricted version of FieldAlias to work solely with string labels.

Version of stAlias adopted to labels.