# Avoiding extra matching with extensible GADTs

**URL:** <https://discuss.ocaml.org/t/avoiding-extra-matching-with-extensible-gadts/15282>\
**Category:** Learning\
**Tags:** type-inference, gadt\
**Created:** [September 15, 2024, 2:00am UTC](https://discuss.ocaml.org/t/avoiding-extra-matching-with-extensible-gadts/15282 "2024-09-15T02:00:01Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![s.t.s](https://avatars.discourse-cdn.com/v4/letter/s/c77e96/32.png) [@s.t.s](https://discuss.ocaml.org/u/s.t.s)\
**Post date:** [September 17, 2024, 12:50am UTC](https://discuss.ocaml.org/t/avoiding-extra-matching-with-extensible-gadts/15282/10 "2024-09-17T00:50:36Z")

</div>

I [attempted to summarize](https://discuss.ocaml.org/t/does-using-object-types-in-gadts-get-you-any-more-power/14042/11) the approaches we have available with data representation problem. I think that probably in the end, we may need to use a code generation solution rather than try to find a solution in terms of language constructs. The code generation would allow us to construct a type of tags, over which we may match efficiently, possibly using phantom types. I guess, it’s not too bad.

I wonder, if any ppx or other libraries exist that would allow me to generate type definitions (and also code) that extend upon existing variant types (and pattern-matches)? Basically, something along the lines

```ocaml
  type _ tag =
    | Int : [> `Int] t
    | Float : [> `Float] t

  module Item_params = struct
    (* item params data ... *)
    type _ tag =
      [%extend: _ tag]
      | Sprite : [> `Sprite]
      | Sound : [> `Sound]
  end

```

There’s no need for any type equality relationships between the instances inside the Item\_params and outside, only creating a new instance of a type based upon template is sufficient.

---

_[View the full topic](https://discuss.ocaml.org/t/avoiding-extra-matching-with-extensible-gadts/15282)._