Apologies Nikos, apparently clicking on the sender in the mail archives replaces the address shown with "haskell-cafe@haskell.org", a behaviour I was unaware of. Olaf
Dear Nikos,
(not CC'ing the list yet because I don't know whether my remarks miss the design goals of DBFunctor)
As a data scientist I have some questions regarding the design of DBFunctor.
1. Why is RTable, or rather RDataType a closed type? Was this forced by compatibility to other databases? There might be RTabular Types whose elements are hard to represent as RDataType, or the conversion deletes some of the data's semantics. What is the essence that makes the operations in the Julius language work? For example, the inner join could have the more general type MonadPlus m => (a -> b -> Bool) -> m a -> m b -> m (a,b)
2. Is there a way of saying that a column may not contain NULL values?
3. What about the efficiency of the operations? I see no complexities stated in the documentation of Etl.Julius.
4. I like the feature of named operations (:=>). But can we bind a sub-operation to a Haskell variable without leaving Julius? After all, takeNamedResult can lead to exceptions because the user may reference a name that has not been defined. With haskell variables, the compiler prevents this. Why not make the Julius language a monad, so that one can use do-notation for building the result? E.g.
type JuliusExpr = JuliusLang RTable instance Monad JuliusLang where ...
Kind regards, Olaf