Module Typegist

Type introspection.

Warning. Typegist is unstable, see design notes and todos.

The typegist library:

See description examples and a generic function template.

Open the module to use it, this only redefines the Type and Fun modules in your scope.

module Type : sig ... end

Type introspection.

module Fun : sig ... end

Function manipulation and generic functions.

Design notes

Similar to Balestrieri et al.'s low level view (§2.3.4). However, the representation is not extensible, a few case are dropped, some representations are unified, some specializations are added.


Meta placement

Difficult to find the right design. Basically we can have it everywhere like now, or only in the toplevel cases or in a single case at the toplevel. This may lead to different attachement interpretations though.

Tried to simply shift them in every toplevel case and let, for example, the gist of a field define the meta of the field but it is problematic with a field whose gist is a recursion step (at a meta to the rec step ?). Also our intepretation in the pretty printer example is different. The meta for the field redefines the whole field printing. While the pretty printer of the field's gist redefines the value. Is it important for other processors ?

In general it looks easier if we don't have to redefine the meta of existing gists to be able to specify metadata at a given point (e.g. the metadata of fields). The drawback is that processors need to document a bit more precisely which meta is relevant for them and we get more lookups (the field's meta and its gist).

Also tried to have meta in the parent case for cases which are variants (Type.Gist.Scalar, Type.Gist.Scalar. etc.) but in the end I shifted them back into the subvariants themselves despite the types looking heavier (Type.Gist.scalar, Type.Gist.sum, etc.). It makes the types meta-aware without needing to carry something on the side. The drawback is that generic meta lookup on a gist is likely slower.

The current scheme ends up making a lots of lookups. For this having only meta as a toplevel case is likely better. It also makes the AST more lightweight. Given the current generic function examples, except maybe for the pretty printer, that would be entirely sufficient. But once we get to for example, type-directed uis. things may look a bit different, especially at the field level.