Skip to content

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.

2 participants