Are Columnable over constrained ?

[maxigit]

For example, functions like add have a Columnable constraint.
This makes sense but at the same time every single constructor of Expr has also a Columnable constraint, so even if the Columnable proof is hidden in GADT, Expr a implies Columnable a.
In a ideal world we don't need Columnable a => Expr a unless we remove it from the Expr constructors altogether. That way Expr could live outside of a DataFrame and possibly have a Functor and Applicative instance.
And when Columnable is required it can be added a constraint as it is already the case.

Just a thought.

[mchav]

Hmmm...in principle someone could define something like:

newtype Unshowable = Unshowable Integer
  deriving (Eq, Ord, Num)

You could then do:

D.derive "sum" (F.lit (Unshowable 2) + F.lit (Unshowable 1)) df
print df

Idk what this would be. So it seems at the very least to keep things dynamic we have to constrain the results of expressions to be Typeable and Showable. The other constraints are overkill (Eq, Ord, Read) - and I'm planning on removing them over time.

But short of making dataframes that look like this: https://hengchu.github.io/posts/2018-05-09-type-lists-and-type-classes.lhs.html

I think the dynamic approach requires you to constrain things a little bit. Maybe I'm missing some type level tricks one could do to prevent this.

[maxigit]

If I understand well, you can't write something like

because you don't know what is in the DataFrame therefore all columns needs to be Typeable and Showable.
But that doesn't mean a Column need to Showable and Typeable, only the column in DataFrame needs to.

Anyway, my point what you don't need
add :: (Columnable a, Num a ) -> Expr a -> Expra
You only need
add :: Num a -> Expr a -> Expr a, because each Col constructor holds it' on Columnable constaint.

Alternatively , you don't need the constraints in the GADT (unless I a missing something of course)