[TYPES] Writing syntactic models with "full information"

Andreas Nuyts andreasnuyts at gmail.com
Mon May 23 04:44:19 EDT 2022


Dear Stefan,

I would suggest the use of intrinsically typed syntax, defined as a 
quotient inductive-inductive type, see
Altenkirch and Kaposi, Type theory in type theory using quotient 
inductive types
https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/2914770.2837638__;!!IBzWLUs!XatwrU-aKYd1XRa3nT193vk7ojHAJl14q2e1KUeemNUZzMN-wZ8bdlsnF09YA9guLUAsf2WsS7PI_7Yw7Jalw0amUAmD1UDAdw$ 
(and further work by either author).
This way, omitting context and type is not cringe-worthy but formally 
justified in the sense that there is only a single (object-language) 
context and a single (object-language) type in which the 
(object-language) expression e is well-typed (in the metalanguage).
I wouldn't recommend it as a strictly better approach, but it has its 
advantages.

I don't know if formalization in a proof-assistant is a part of what 
you're doing.
Altenkirch & Kaposi have an Agda formalization where they build quotient 
types using postulates & rewrite rules.
Today, to my understanding, it should in principle be possible to 
instead do this in agda-cubical, although I don't think anyone has done 
it (and it sounds like a very major effort).
FWIW, I have a formalization of multisorted algebraic theories and their 
categories of models in agda-cubical (currently using quite some 
termination pragmas rather than sized types) at 
https://urldefense.com/v3/__https://github.com/anuyts/ctx-alg/__;!!IBzWLUs!XatwrU-aKYd1XRa3nT193vk7ojHAJl14q2e1KUeemNUZzMN-wZ8bdlsnF09YA9guLUAsf2WsS7PI_7Yw7Jalw0amUAmobT5gJw$ 

Best regards,
Andreas Nuyts

On 21.05.22 03:16, Stefan Monnier wrote:
> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
>
> I often write translations between PTS-style languages where the overall
> structure of the translation can be represented by saying that an input
> expression `e` is turned into an output `[e]` with a property like
>
>      Γ ⊢ e : τ
>      =>
>      [Γ] ⊢ [e] : [τ]
>
> Or some variant of it, very much like Boulier et al. did in "The next
> 700 syntactical models of type theory".
>
> But often my translation function [·] needs a bit more info than that
> provided by an expression.  E.g. it may need to know the expression's
> type or the typing context in which it was found.  So what I end up
> doing is to define my translation function as taking a typing derivation
> as input while still returning a mere expression.
>
> Formally it means the above elegant property becomes:
>
>      Γ ⊢ e : τ    (which implies that   ∃ℓ. Γ ⊢ τ : Typeℓ)
>      =>
>      [Γ] ⊢ [Γ ⊢ e : τ] : [Γ ⊢ τ : Typeℓ]
>
> which is much less elegant and less friendly for the reader (I did
> something like that for example in "Inductive types deconstructed: the
> calculus of united constructions" and this was mentioned as an oddity
> by one of the reviewers, for example).
>
> It also makes the presentation more verbose and harder to read, for
> which the only way out I have found is to use cringe-worthy abuses of
> notation where I might write [e] as a shorthand for [Γ ⊢ e : τ] where
> the Γ and τ are presumed "obvious from context".
>
> Has anyone here faced similar issues?  What's a better approach?
>
>
>          Stefan
>



More information about the Types-list mailing list