Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ListTable an instance of Prelude.Functor #84

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

Conversation

ocharles
Copy link
Contributor

@ocharles ocharles commented Jun 29, 2021

This is a draft/proof of concept. Some things to point out:

  • The ListContext thing isn't strictly necessary. We could move that into Interpretation, or we could just have multiple Table instances for ListTable that specialises the context. Or we could have dynamic dispatch in Table if we have Interpretation carry some kind of singleton.

  • The implementation is a hacky mess. This wouldn't be the final code - there's plenty of tidying to do. In particular, Opaleye needs upstream changes to support running a subselect as an expression.

  • The implementation of toColumns in Table Expr always calls unnest and re-aggregation. This isn't necessary. In practice, I would have a second constructor for ListTable which is the non-fmaped version which gives us a fast path.

In terms of some other things I tried:

  • I originally started with ListTable i o, where i is the "input" to the ListTable. The problem with this is with HList. If we have HList Expr foo, what should we produce? ListTable foo foo is an option, but that seems overly restrictive, as it doesn't let you build that field using fmap. Maybe it can be forall i. Table (Context foo) i => ListTable i foo or something, but I didn't try that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant