[Haskell-cafe] A lazy question

Mario Blazevic mblazevic at stilo.com
Sun Aug 13 14:09:14 EDT 2006

> >    sourceToSinkTransducer :: SourceTransducer x y -> SinkTransducer x y
> > 
> >  I can't find any way to implement the sourceToSinkTransducer function
> Indeed that cannot be done because it breaks referential transparency.

Ok, thanks for clarifying the reason.

> Food for thought:
> You need some sort of side effects (I'm not quite sure which), so
> it'd be interesting to try
>   newtype Source m x = Source (m (x, Source x))
>   newtype Sink   m x = Sink   (x -> m (Sink x))
> where m is an appropriate monad. Will the continuation monad work?

I'm not sure. I'm trying to find the minimal data types that will let me implement the
higher-level combinators. So far, the best I've found is the CPS and the following

data Source i r = Source {get :: Sink i r -> r}
data Monoid r => Sink i r = Sink {put :: i -> Source i r -> r, close :: r}

newtype Filter x y = Filter { transduce :: forall r. Monoid r => Source x r -> Sink y r -> r }
newtype Splitter i = Splitter { split :: forall r. Monoid r => Source i r -> Sink i r ->
Sink i r -> r }

The 'close' function and result type 'r' are there because the streams are usually finite.
The 'Source' type should really be declared as 

data Source i = Source {get :: forall r. Sink i r -> r}

because sources should not depend the result type, but that caused a lot of problems with
type checking: the two 'r's in Source and Sink declaration are not unified. I don't see a
way to express my intention.

Anyway, thanks again for the explanation of why it has to be this complicated.

More information about the Haskell-Cafe mailing list