Re: Functions of type foo :: f a -> g a

Thank you for all these answers - I learned a lot (especially that the responses come in REALLY quickly, so the digest option is not a good choice). I think I need to rephrase the problem, taking into account what I have learned. class (Functor f, Functor g) => Foo f g where foo :: f a -> g a as per John Meacham's suggestion to isolate the transform. Really, f and g are 'containers' which I want to reshape (and there can be many different re-shapings of g for each f, and different f's can map to the same g, so no fundeps relation holds in general). I am trying to use classes as an interface description, with this transformation being part of that interface, and also to allow me to experiment with different constraints (e.g. Monad f, Applicative f, etc). Edward Kmett points out (thank you for that detailed reply!) that there is no canonical foo -- which is a good point, and is indeed the right model -- "natural transformation" was likely a red herring. What I am trying to do is take a container of data f, and partition it into a structure g as a 'chunking' of that data. The f container is a potentially infinite stream of data obtained from a generator, and I want to be able to control how much data is extracted, so an eager 'fmap' won't be sufficient (an eager process will be applied to the 'chunks' defined by g). I am going to purse the hylomorphism model, but am interested if anyone else has any similar situations, and if using classes to manage the interface is the right strategy. Thanks! Gordon J. Uszkay uszkaygj@mcmaster.ca

On 13 May 2010 20:25, Gordon J. Uszkay
The f container is a potentially infinite stream of data obtained from a generator, and I want to be able to control how much data is extracted, so an eager 'fmap' won't be sufficient (an eager process will be applied to the 'chunks' defined by g).
I am going to purse the hylomorphism model, but am interested if anyone else has any similar situations, and if using classes to manage the interface is the right strategy.
Hi Gordon
From your description this sounds closer to Jeremy Gibbons 'metamorphism' than a hylomorphism:
http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/metamorphis... See also the Spigot / pi paper. Best wishes Stephen

There is also a (naive) metamorphism combinator in my category-extras
library:
http://hackage.haskell.org/packages/archive/category-extras/0.53.4/doc/html/...
Though it is definitely worth pursuing the optimizations that Gibbons talks
about in his very good spigot paper.
Another option might be to rephrase your problem into something suitable to
the Generator/Reducer framework in
http://hackage.haskell.org/package/monoids-0.1.36
Since in many ways if f is a Generator and g is a Reducer, that is exactly
what my monoids api is all about. Though there I admit, I'd need to know
more about the problem domain.
-Edward Kmett
On Thu, May 13, 2010 at 3:32 PM, Stephen Tetley
On 13 May 2010 20:25, Gordon J. Uszkay
wrote: [SNIP] The f container is a potentially infinite stream of data obtained from a generator, and I want to be able to control how much data is extracted, so an eager 'fmap' won't be sufficient (an eager process will be applied to the 'chunks' defined by g).
I am going to purse the hylomorphism model, but am interested if anyone else has any similar situations, and if using classes to manage the interface is the right strategy.
Hi Gordon
From your description this sounds closer to Jeremy Gibbons 'metamorphism' than a hylomorphism:
http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/
http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/metamorphis...
See also the Spigot / pi paper.
Best wishes
Stephen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

The problem does follow a generator / reducer model. I think between metamorphisms, hylomorphisms and monoids, I should be able to structure my solution correctly. Thanks! Gordon J. Uszkay uszkaygj@mcmaster.ca On May 13, 2010, at 3:42 PM, Edward Kmett wrote:
There is also a (naive) metamorphism combinator in my category-extras library:
http://hackage.haskell.org/packages/archive/category-extras/0.53.4/doc/html/...
Though it is definitely worth pursuing the optimizations that Gibbons talks about in his very good spigot paper.
Another option might be to rephrase your problem into something suitable to the Generator/Reducer framework in
http://hackage.haskell.org/package/monoids-0.1.36
Since in many ways if f is a Generator and g is a Reducer, that is exactly what my monoids api is all about. Though there I admit, I'd need to know more about the problem domain.
-Edward Kmett
On Thu, May 13, 2010 at 3:32 PM, Stephen Tetley
wrote: On 13 May 2010 20:25, Gordon J. Uszkay wrote: [SNIP] The f container is a potentially infinite stream of data obtained from a generator, and I want to be able to control how much data is extracted, so an eager 'fmap' won't be sufficient (an eager process will be applied to the 'chunks' defined by g).
I am going to purse the hylomorphism model, but am interested if anyone else has any similar situations, and if using classes to manage the interface is the right strategy.
Hi Gordon
From your description this sounds closer to Jeremy Gibbons 'metamorphism' than a hylomorphism:
http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/ http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/metamorphis...
See also the Spigot / pi paper.
Best wishes
Stephen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Edward Kmett
-
Gordon J. Uszkay
-
Jacques Carette
-
Stephen Tetley