Telescope

A telescope is an extension of an NS, where every time we "go right" in the sum we have an additional value.

Blockchain intuition: think of g as representing some kind of past state, and f some kind of current state. Then depending on how many hard fork transitions we have had, we might either have, say

TZ currentByronState
TS pastByronState $ TZ currentShelleyState
TS pastByronState $ TS pastShelleyState $ TZ currentGoguenState

The Telescope API mostly follows sop-core conventions, supporting functor (hmap, hcmap), applicative (hap, hpure), foldable (hcollapse) and traversable (hsequence'). However, since Telescope is a bi-functor, it cannot reuse the sop-core classes. The naming scheme of the functions is adopted from sop-core though; for example:

bi h (c) zipWith
|  |  |    |
|  |  |    \ zipWith: the name from base
|  |  |
|  |  \ constrained: version of the function with a constraint parameter
|  |
|  \ higher order: 'Telescope' (like 'NS'/'NP') is a /higher order/ functor
|
\ bifunctor: 'Telescope' (unlike 'NS'/'NP') is a higher order /bifunctor/

In addition to the standard SOP operators, the new operators that make a Telescope a telescope are extend, retract and align; see their documentation for details.

Specialization of hsequence' with weaker constraints (Functor rather than Applicative)

Bifunctor analogue of hap

Bifunctor analogue of hmap

Bifunctor equivalent of hzipWith

Bifunctor equivalent of hczipWith

Extend the telescope

We will not attempt to extend the telescope past its final segment.

Blockchain intuition: suppose we have a telescope containing the ledger state. The "how to extend" argument would take, say, the final Byron state to the initial Shelley state; and "where to extend from" argument would indicate when we want to extend: when the current slot number has gone past the end of the Byron era.

Retract a telescope

Blockchain intuition: suppose we have a telescope containing the consensus state. When we rewind the consensus state, we might cross a hard fork transition point. So we first retract the telescope to the era containing the slot number that we want to rewind to, and only then call rewindChainDepState on that era. Of course, retraction may fail (we might not have past consensus state to rewind to anymore); this failure would require a choice for a particular monad m.

Align a telescope with another, then apply a function to the tips

Aligning is a combination of extension and retraction, extending or retracting the telescope as required to match up with the other telescope.

Blockchain intuition: suppose we have one telescope containing the already-ticked ledger state, and another telescope containing the consensus state. Since the ledger state has already been ticked, it might have been advanced to the next era. If this happens, we should then align the consensus state with the ledger state, moving it also to the next era, before we can do the consensus header validation check. Note that in this particular example, the ledger state will always be ahead of the consensus state, never behind; alignExtend can be used in this case.

Version of extend where the evidence is a simple Bool

Version of retract where the evidence is a simple Bool

Version of align that never retracts, only extends

PRE: The telescope we are aligning with cannot be behind us.

Version of alignExtend that extends with an NS instead

Telescope with both functors set to the same f

Telescope analogue of scanl on lists

This function is modelled on

scanl :: (b -> a -> b) -> b -> [a] -> [b]

but there are a few differences:

• Since every seed has a different type, we must be given a function for each transition.
• Unlike scanl, we preserve the length of the telescope (scanl prepends the initial seed)
• Instead of generating a telescope containing only the seeds, we instead pair the seeds with the elements.