[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
declarations:
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