Support for capability-style records

[schell]

I really don't know if this is possible, but I'm referring to capability records like:

data LogCap (m :: Type -> Type) 
  = LogCap 
  { logInfo :: String -> String -> m ()
  , logError :: String -> String -> m () 
  } deriving Generic

From the outside these records look like HKDs - every field contains the type variable, but you might consider function parameters being "hidden" from it (one of the disclaimers from ProductB).

The first problem to solve is the FunctorB instance, as GFunctorB doesn't cut it:

• No instance for (barbies-1.1.3.0:Data.Barbie.Internal.Functor.GFunctorB
                         *
                         *
                         f
                         g
                         (Rec
                            *
                            (String
                             -> String
                             -> barbies-1.1.3.0:Data.Generics.GenericN.Param * * 0 f ())
                            (String -> String -> f ()))
                         (Rec
                            *
                            (String
                             -> String
                             -> barbies-1.1.3.0:Data.Generics.GenericN.Param * * 0 g ())
                            (String -> String -> g ())))

Intuitively though, it seems that we should be able to traverse an arrow with (f a -> g a), drilling deeper by creating lambdas until we come to an m a.

The point of all this is that at the end of the day it would be nice to be able to write a generic lift function for any of these forms of HKDT.

Given:

newtype Apply (f :: Type -> Type) (g :: Type -> Type) a
  = Apply { runApply :: f a -> g a }


bapply
  :: ProductB b
  => b (Apply i o)
  -> b i
  -> b o
bapply =
  bzipWith runApply

You could easily do something like:

let 
  ioLogCap :: LogCap IO 
  ioLogCap = ioLoggingCapabilities 

  resourceTLogCap :: LogCap (ResourceT IO) 
  resourceTLogCap = bapply (buniq $ Apply lift) ioLogCap
in 
  runResourceT $ f resourceTLogCap

which could kill a pleasant amount of boilerplate when using capability records.

Thoughts? I might be crazy ¯_(ツ)_/¯

[jcpetruzza]

I think you are definitely right, and we should be able to handle this case. Conceptually, the main thing that we are missing is to allow the functor argument (e.g. m in LogCap m) to occur under another functor when deriving FunctorB (and similarly for the other classes). At the moment we allow a barbie type to occur under a functor (e.g. Maybe (LogCap m)), but not the functor argument itself. This shouldn't be hard to fix.

Because we have an instance Functor (-> r), this addition alone would let us handle simpler capability records such as:

data LogCap (m :: Type -> Type)
  { logInfo  :: String -> m ()
  , logError :: String -> m ()
  }
  deriving (Generic)

instance FunctorB LogCap

Of course, one would like to handle functions with an arbitrary number of parameters (not just one) or, more generally, an unlimited number of nested functors. This is in fact a bit tricky; but ultimately doable, I think (e.g., one could identify arbitrary chains of functor applications in the generic representation of the type, coerce the type into a version where all the functors were smashed into one using Compose, operate on that single functor, and then coerce it back to the original representation).

A quicker workaround, would be to do a manual unrolling defining k instances of the form "the functor argument occurs under {1,2,3,...k} functors".

[dalaing]

I did the manually unrolled instances for FunctorB, ApplicativeB and ConstraintsB for a work task - and then a coworker found a way to generalise this, at least for the function version of things!

It ended up requiring this patch to Barbies.Generics.Constraints:

type family GAllRec
  (n :: Nat)
  (c :: k -> Constraint)
  (l :: Type)
  (r :: Type) :: Constraint
  where
+   GAllRec n c (a -> d) (a -> e) = GAllRec n c d e -- support `barbies-methods`
     GAllRec n c (P n X _) (X a) = c a
     GAllRec _ _ _ _ = ()

I was able to use this to write Hedgehog state machine tests that work with a barbie for our REST API, write a barbie that adds in caching support, and then write a barbies that pairs those two barbies - as long as all of the result types have Eq and Show instances, I can state the property "the version with caching agrees with the version without caching at every point in time" and then have generators that cover the API. It's pretty awesome. Looking forward to using it for mocks etc...

I'm not sure if the above patch might break things, and the other instances are added in as orphans that might potentially have side effects in other use cases. My conservative plan was to create a newtype called BarbiesMethod or similar and write the instances for that, so that it could be used with DerivingVia. There is probably a sloppier plan where I just add all of these instances in and see if it break any of the tests, but this seems like something it would be sensible to opt users into, in case they have use cases that aren't covered by the tests.

I'm going to try to put a PR together in the next few weeks, but I figured I'd socialise the idea first in case people already had thoughts / preferences / requests around this.

[schell]

I haven't written any Haskell in about four years, but I appreciate that this is still on-going and getting worked out! Thanks @dalaing :) 👍