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



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/Control-Morphism-Meta-Gibbons.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 <stephen.tetley@gmail.com> wrote:
On 13 May 2010 20:25, Gordon J. Uszkay <uszkaygj@mcmaster.ca> 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/metamorphisms-scp.pdf

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