On Tue, Feb 27, 2018 at 02:28:31PM +0100, MarLinn wrote:
There's a myth floating around that "Arrow is much less useful because it forces you to implement arr". In fact, Arrow without arr would be as useless as Applicative without fmap.
a nice coincidence that you call Applicative without fmap "useless". I just recently saw one of those. It *did* feel like there might be a better structure, but I couldn't pin it down. Maybe your technique works in that context as well? ...
The structure in question are XML-Picklers, i.e. tools to convert to and from XML. The original types are from HXT
https://hackage.haskell.org/package/hxt-9.3.1.16/docs/src/Text-XML-HXT-Arrow...
Obviously there's no way to implement fmap because you always need to provide functions for both directions .... So how would you change this structure to make it possible?
Observe the definition from the HXT source data PU a = PU { appPickle :: Pickler a , appUnPickle :: Unpickler a , theSchema :: Schema } type Pickler a = a -> St -> St newtype Unpickler a = UP { runUP :: St -> (UnpickleVal a, St) } type UnpickleVal a = Either UnpickleErr a Pickler is contravariant (Contravariant) and Unpickler is covariant (Functor) so if we slighly augment PU we get a Profunctor. data PU' a b = PU { appPickle :: Pickler a , appUnPickle :: Unpickler b , theSchema :: Schema } In fact Unpickler is a Monad (isomorphic to an EitherT of a State) so "PU' a" is an Applicative and PU is what I call a "product profunctor". https://hackage.haskell.org/package/product-profunctors This little augumentation in the definition of PU gets you a whole host of free functionality from the libaries for profunctors, applicatives and product profunctors. (By the way, this observation is completely different from the "compiling languages for different targets" technique that I mentioned in the previous post.) Tom