Conversation

a telescope is a way of looking at function types. { A : Type } -> A -> Int can be flattened down into e.g. ([{ A : Type }, ( _ : A) ], Int). the list is basically a context, and each name in it can be used in the types of later entries, as well as in the body.
1
3
a neutral spine is a representation for values used in normalization-by-evaluation consisting of a variable at the head, followed by a (snoc) list of eliminations (e.g. values to apply the value the variable represents to). f a 0 can be flattened down into (f, Nil :> a :> 0)
1
2
telescopes are type-y things, spines are term-y things (tho note you can have kind-level telescopes and type-level spines), and they grow at opposite ends; but a telescope can describe the type of a neutral spine.
1
3
if f’s type is described as a telescope, then the types of its eliminations (arguments) will be the types in the telescope’s context, and the neutral term as a whole will have the final result type of the telescope.
2
4
You should also notice that telescopes, contexts (in a DTT), theory presentations, specifications, module signatures, records-as-Sigma-types and traits are also essentially all the same, especially in a dependently typed setting.
2
12
In general, we have uses for a generic idea of defining some valid X (which can be a type or a term or ...) using names in scopes as part of the definition of X. These naturally for a DAG (unless you go for mutual recursion too).
2
2
It is important to note that some of these (contexts, telescopes) have their morphisms (substitution) go in the opposite direction of some others (specifications). So pullbacks are 'natural' in contexts, while pushouts in specifications.
1
1
This is why you see pushouts all over the work of Goguen and Burstall, and everything that follows. Including the spectacular work of Doug Smith (and co-authors) from Kestrel on building specs via colimits. But in categorical logic, it's pullbacks everywhere.
1
1
Replying to and
Ohh this looks interesting! Do you know if there might be a good solution to manifest fields/singleton types from this perspective? This is something I've been wanting to add to my dependent type system: twitter.com/brendanzab/sta - unclear about the best approach though 😅
Quote Tweet
Trying to avoid having top level commands in my dependently typed language. It's frustrating that you can't give a type to a signature easily! You need manifest fields or singletons or identity type trickery to make certain definitions public, or else you limit expressiveness. 🤔
Show this thread
Replying to and
What you show in that thread ought to work in a dependently typed system. The point is that later types (and terms) are interpreted in the context where the previous instantiations are done. So A = U32 is known (and substituted in), so that len is fine [in your example].
1