I think the signatures for fanOut and fanIn themselves are probably:
fanOut :: Subset qs ps -> (forall q. Member q qs -> Choreo ps m (Located '[q] a)) -> Choreo ps m (Faceted qs a)
fanIn :: Subset qs ps -> Subset rs ps -> (forall q. Member q qs -> Choreo ps m (Located rs a)) -> Choreo ps m (Located rs [a])
But is that the right set of fundamental building blocks? And how does the existence of Faceted affect the rest of the API?
It's tempting to allow locally to work on multiple locations at once, and return Faceted instead of Located. But I think that's not strictly necessary. In any case it's necessary to expose a way to unwrapFaceted values inside locally.
flatten should work with Faceted. How exactly? It seems like we should define some class that Located and Faceted are both instances of.
taking into account #35, it seems like there are many possible "local" functions; which ones are fundamental?
I think the signatures for
fanOutandfanInthemselves are probably:But is that the right set of fundamental building blocks? And how does the existence of
Facetedaffect the rest of the API?locallyto work on multiple locations at once, and returnFacetedinstead ofLocated. But I think that's not strictly necessary. In any case it's necessary to expose a way tounwrapFacetedvalues insidelocally.flattenshould work withFaceted. How exactly? It seems like we should define some class thatLocatedandFacetedare both instances of.sendshould certainly work withFaceted.