Repository navigation
Parameterize ADT tag types - #424
Open
dathegreat wants to merge 1 commit into
Open
dathegreat wants to merge 1 commit into
dathegreat wants to merge 1 commit into
Conversation
dathegreat
marked this pull request as ready for review
November 2, 2026 17:07
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello maintainers! May I please get your thoughts on this feature before I spend time writing more haddock documentation for it? Are you interested in adding this functionality to Rel8?
Motivation
I ran into a scenario at my day job where I needed to encode an ADT in one of our tables. Because I generally prefer encoding database constraints at the type level if possible, I wanted to make the tag column a Postgres
enum, rather than atexttype. I also read #422 the other day, and thought this could be an interesting step in that direction as well (using something likeADTWith NoTag t, maybe?)AI Disclaimer
I used an LLM to assist with these changes. On a scale from vibe-code slop to 100% handwritten research paper, I would give this a 7/10.
Added
ADTWith tag ttype which generalizes theADTtype's hardcodedtexttag column, so the tag can be any type, such as a PostgreSQL
enum.ADTTagclass to define tag types. A tag type must be aNonNullDBTypewith
EqandDBEq, whose constructors are all nullary (zero parameters) andcorrespond one-to-one with the ADT's constructors. This tag <-> ADT bijection
is defined by
ADTTag's associatedTagConstructortype. Mismatches arereported as type errors.
...Withversions of the existing ADT types and functions, suchas
HADTWith,NameADTWith/nameADTWith,buildADTWithandconstructADTWith.Changed
ADT,HADT,ADTable,BuildableADT,ConstructableADT,NameADT, etc.are now synonyms for their
...Withversions applied toTag, such astype ADT = ADTWith Tag. Functions likebuildADTdelegate similarly totheir
...Withversions. Existing code using them is unaffected, apart fromthe following.
ADTis now a type synonym, instances on it such asinstance C (ADT t)requireFlexibleInstances. This is enabled by defaultin
GHC2021.